Ransomware “Does Not Succeed” with DNS
Ransomware Series Part 3

Written by: George Grzyb, Principal Engineer
Connect with George on LinkedIn

In the Ransomware Series Part 1 overview, we discussed how ransomware campaigns work and how they can be stopped. In Ransomware Series Part 2, we looked at implementing a secure access security edge (SASE) architecture to provide technologies that prevent ransomware. Now, we focus on a vital Internet technology that is an entry point for ransomware and malware propagation: Domain Name System (DNS).

With the proliferation of the Internet and associated cloud-based services, we rely on DNS for the crucial IP-to-name mapping it provides. Considering content delivery networks (CDNs) and virtual name-based hosted services, you can see why DNS is required. The Internet is now highly resilient, and an application can reside across multiple geographies accessed by different sets of regional IP addresses. Conversely, a single IP address can be exposed by a business to provide secure web hosting with an application delivery controller (ADC) routing many different websites to different sets of resources.


How Can DNS Be Exploited? What Are Possible Solutions?

There are several ways that bad actors can exploit DNS. Let’s review the most common methods and their solutions.


Cache Poisoning & Man-in-the-Middle (MITM) Attacks

Under specific scenarios, when a bad actor can either take control of a portion of the DNS resolution path or inject responses to the requester, the DNS response payload can be modified to return an IP address controlled by the bad actor or compromised system. In such a scenario, the attacker may steer the user to a resource that mimics the original website for harvesting user credentials. Alternatively, the attacker may send traffic back to the user with the page request to take over their machine using an active zero-day exploit.

What Can We Do?

DNSSEC is a solution that assures data integrity using a “chain of trust” to reject any DNS responses which are not appropriately cryptographically signed for verification. Mandated by the US government nearly a decade ago to protect federal resources, many corporate systems either do not sign their authoritative zones for Internet users or perform DNSSEC validation on the resolver. Adopting DNSSEC is imperative to provide trust that the DNS response received was not tampered with and is genuinely from the owner of the authoritative domain. The general concept is that only the owner of a particular DNS zone can sign it, preventing malicious actors from forging DNS entries to force a user to access a malicious site controlled by themselves. Only by enforcing the validation of signed DNSSEC zones can you ensure that any DNS response received is cryptographically validated to be genuine and not tampered with by a bad actor.

A common pushback for implementing this level of DNS security was around signing key management. However, many current solutions can automate this rolling over of security keys and resigning of zones without any admin involvement. In terms of DNS response validation, DNS systems support initially requesting a DNSSEC response but will fall back to consuming a non-signed response if a third party has not signed their authoritative zones.

Look-Alike Domains

These are domain names registered by bad actors to impersonate the URLs of legitimate sites. The goal is slightly changing the domain’s name to avoid immediate detection through homograph and homoglyph techniques. The backend website is generally developed to mimic the legitimate site’s content to harvest personal information or facilitate the transfer of malware (for example, “google.com” and “göögle.com” or “walmart.com” and “vvalrnart.com” look similar but utilize different characters). Of course, different fonts and punctuation can enhance the usage of these techniques. This subtle difference may not be noticed if one is not overly cautious.

What Can We Do?

Many DNS solutions utilize artificial intelligence (AI) to identify the usage of look-alike domains by bad actors that firewall-based URL categorization and filtering would not typically capture. Instead of allowing the resolution of such a spoofed domain, access is blocked. Some solutions allow for stopping newly registered domain names or even a series of DNS requests using random subdomain names as commonly used in the command-and-control (C&C) type of activity. If you did not entrust such analytical blocking to be automated, you would constantly update allowlists, blocklists, and even response policy zone (RPZ) feeds in a never-ending cycle.

Data Exfiltration

Sensitive business data in the wrong hands can result in audit or compliance sanctions, reputational loss, or even legal action. Unsanctioned external communication of sensitive data may include chat or text, documents uploaded to a public site, or even insecure storage where any Internet user can download or access a copy. However, one can also leverage DNS and a rogue DNS server for exfiltrating data. Simply by using dynamically generated domain names or even SRV/TXT records, information stored as a hash or encrypted string can be securely transmitted and reassembled by the target DNS server.

Data exfiltration can also include unsanctioned communication between an advanced persistent threat (APT), resident ransomware, or a compromised system with a bad external actor to solicit the next steps. C&C communication can certainly exploit DNS in the same manner as data exfiltration.

What Can We Do?

Web proxies, secure web gateways (SWG), and generic data loss prevention (DLP) solutions seek to prevent data exfiltration. However, these solutions do not address DNS as an exploitable avenue of communication. Once again, many DNS solutions utilize AI to identify where a subdomain name of an externally authoritative zone is cycled through random characters or if there is an abnormal usage of SRV or TXT records in a short period. If you use a third-party solution for recursive DNS resolution, blocking traffic on the firewall to any unsanctioned DNS servers is imperative. Only those DNS servers provided by the third-party solution should be allowed to handle the client DNS queries. In this manner, you force the inspection of all DNS requests to ensure there is no facilitation of data exfiltration.

These DNS servers provided by third-party solutions should provide a service of analytically reviewing client DNS queries instead of blindly forwarding them to root name servers and, eventually, those DNS servers controlled by bad actors. If your current solution is to merely use Internet service provider (ISP) name servers or Google’s and Internet name servers for the DNS resolution of last resort, then you are vulnerable. Controlled inspection of all external DNS traffic is essential to thwarting any bad actor data exfiltration attempts.


How Is DNS Managed?

Many solutions bundle IP address management (IPAM) with their DNS solution and provide a web-based GUI which is easy to use. This is better than using spreadsheets and manually adding DNS entries to BIND or even Microsoft DNS. While the benefits of IPAM have already been extolled and recognized by many DNS admins, what has evolved is the infrastructure used to host the solution. The transition is now like that seen with wireless access points (WAP). Some DNS solutions have been developed to provide a cloud-based solution for managing DNS with changes pushed to either local data centers or cloud-based instances of distributed DNS servers. Managing DNS can be more straightforward than ever, with the added benefit of allowing admins easy access to perform changes while working remotely.


Nexum Ensures Ransomware “Does Not Succeed”

Cybersecurity bad actors have found ways to exploit this network service since everyone uses DNS for initial application connection or accessing Internet resources. Introducing DNS security controls can prevent ransomware from gaining a foothold. Appropriately implemented, you can mark ransomware campaigns as “Did Not Succeed” on your security reports when DNS stops an attack in the infancy of any network data connection.

DNS is security’s first line of defense before you even receive or send that first HTTP packet. Nexum is ready to discuss your DNS needs and expectations while providing secure and manageable solutions.

Jump to –


Check Out More Resources

Nexum Resources

Enterprise Logging Best Practices

Each quarter, the managed security team at Nexum shares insights from our first*defense SNOCC. In this post, we decided to share some general logging best practices that are likely to benefit every organization.

Read More »