Don’t Get ‘Shawshanked’ by DNS Tunneling 

Since the onset of the pandemic, cyberattackers have increasingly looked to leverage DNS channels to steal data, launch DDoS attacks and deploy malware—and the cost of these attacks is rising. According to IDC’s 2020 Global DNS Threat Report, the average cost of such an attack is now approaching $1 million, and impacts can range from the direct expense of application or service downtime to factors more difficult to quantify, like reputational damage to a company’s brand. 

These attacks are also much more widespread than many realize. A study from EfficientIP found nearly nine in ten organizations (87%) suffered one or more DNS attacks in 2020, with victims being hit an average of 7.6 times during the year. 

One of the most common of these types of threats organizations face is DNS tunneling, in which attackers encode the data of other programs or protocols in DNS queries and responses. This allows cybercriminals to insert malware or pass stolen information into DNS queries, which move freely in and out of a network, thereby creating a covert communication channel that bypasses an organization’s firewalls. It essentially becomes an open channel for data exfiltration, access to your internal network and malware command and control.

Where DNS Tunneling Came From—And Where it’s Going

Using DNS as a transport method to access blocked content has been around for decades. Before free Wi-Fi was ubiquitous, some smart and savvy techies who didn’t want to pay when faced with a captive portal noticed that in many situations, they could send an outgoing ping to a server and get a response even without an internet connection. Whether they were connected to the internet or not, DNS was still working in the background. If a user had an “authoritative” server for a namespace that they controlled, DNS traffic would go there and come back independent of the captive portal. 

From there, they created software that could chop up an outgoing message to embed the payload into the DNS requests, decode the received traffic and encode the nameserver’s response. Limits on the size of a transmission had to be considered and the process of chopping up the message was very slow, but it worked, and the process became the basis for the tunnel. 

When it was first conceived, a DNS tunnel was difficult to set up, but toolkits and instructional videos widely available online today have leveled the playing field. The tactic has been adopted broadly enough that even novice hackers now use it to access content, steal data and documents, and plant malware into an organization’s networks. 

DNS tunneling allows attackers to evade the network firewall to get information into or out of a network by encoding the data of other programs or protocols into DNS queries and responses. These responses also often included data payloads that can be added to an attacked DNS server and which can be used to control a remote server and applications. Nation-state actors regularly use DNS tunneling to exfiltrate sensitive information from infected hosts, but it is widely considered one of the most “accessible” threat vectors, allowing even unsophisticated hackers to burrow into an otherwise secure domain. 

Easy to Deploy; Hard to Stop

This is not a threat that should be overlooked; even though they are now easy to set up, DNS tunnels are still difficult to detect. Unfortunately, techniques to uncover and identify DNS tunneling attempts require analysis of both traffic and live domains associated with bad actors, making identifying them difficult and time-consuming.

As stated in the MITRE ATT&CK framework: 

“The DNS protocol serves an administrative function in computer networking and thus may be very common in environments. DNS traffic may also be allowed even before network authentication is completed. DNS packets contain many fields and headers in which data can be concealed. Often known as DNS tunneling, adversaries may abuse DNS to communicate with systems under their control within a victim network while also mimicking normal, expected traffic.”

While it is not the only protocol that can be used to form a tunnel, its prevalence in normal network communications makes it easier to overlook. Additionally, since DNS queries and responses aren’t completely uniform, it may not always be easy to spot the ones that are anomalous or that may not conform to standards. Despite these challenges, the potential for damage makes it necessary for organizations to take every precaution.

How to Spot Activity on Your Network

So, what can you do to detect potential DNS tunneling on your network? Start by examining DNS queries themselves. Since DNS is not typically used for data transfer, many companies do not monitor this type of traffic for malicious activity as they would with other traffic types.

A good threat intelligence feed should include information gleaned from a variety of sources that can be used to keep your SIEM or other perimeter security devices up to date. This can help you block DNS queries going to any sites that are known to be bad, malicious or that are known DNS tunnel endpoints. If you have your own recursive service or subscribe to one that offers filtering at the DNS layer (i.e., a DNS firewall), you may be able to block outgoing requests at that point. It is also important to keep a close eye on the domains themselves, as well as the frequency and source of specific requests over time.

Running secure recursive resolvers inside the network and fronting them with DNS firewalls could work if and when a bad address is known. It may be appropriate to set your firewall to block all outbound port 53 traffic from any machine inside the firewall (other than the company-sanctioned recursive servers), as authoritative servers will bind to that port.

The key is to identify anomalous traffic operating under the cover of DNS. To do that, you need to closely monitor things like the length of subdomain names in queries, as these could be encoded data. Other things to look for are DNS requests with high entropy or a high level of disorganization. Most of these requests follow a fairly organized pattern. Because DNS traffic is passed in the clear by default, it is possible to spot traffic that doesn’t look similar to others. Be sure to examine the overall network traffic, looking for uncommon data flows or new DNS queries from processes or clients that don’t usually communicate on the network.

Finally, always follow up on network-wide malware infections, particularly if a strain is known to construct DNS tunnels. Don’t assume that only one device was affected. By proactively remediating clients that might have been exposed, you can save yourself a lot of trouble down the line.

Avatar photo

Michael Kaczmarek

Michael Kaczmarek is the VP of Product Management for Neustar’s Security Solutions business unit. He is responsible for evangelizing the vision, strategies, and tactics for the successful launch and expansion of products into new and existing markets. Prior to joining Neustar, Michael was with Verisign for more than 18 years where he served in various capacities including VP of product management and marketing for Verisign Security Services. He previously served as a systems engineering manager for Lockheed Martin in charge of their Solid Rocket Motor Disposition in Russia Program. Michael holds a Bachelor of Science in aerospace engineering from the University of Maryland and a Master of Engineering in environmental engineering from Johns Hopkins University.

michael-kaczmarek has 4 posts and counting.See all posts by michael-kaczmarek