As a security professional, you are tasked with plugging holes in your network every day. You must keep your firewalls patched and your overall system updated, just to keep the bad guys from getting in and data from going out. But one sneaky avenue may be sitting right under your nose – the DNS or Domain Name System.
Using DNS as a transport method to access blocked content has been around for decades. The exploit started back in the days when there was no such thing as free Wi-Fi but there were plenty of smart tech folks who didn’t want to cough up cash when faced with a captive portal. These “ambitious” folks noticed that in many situations they could send an outgoing ping to a server and get a response even without an internet connection. The individuals realized that DNS was still working in the background and that requests to a DNS nameserver and responses from it passed right through the captive portal. If the user had an “authoritative” server for a namespace that they controlled, these individuals mused, then DNS traffic would go there and come back, independent of the captive portal. The next step was to create software that could chop up an outgoing message and embed the payload into the DNS requests. The same software could be used to “decode” the received traffic, and to “encode” the nameserver’s response. This process becomes the basis for the DNS tunnel. The function is similar to what a VPN tunnel does, except that the entire process was controlled by the “ambitious” individual. And, because the process of chopping up the message and limits on the size of a DNS transmission had to be considered, the process was very slow. But…it worked!
Now that free Wi-Fi is pretty much ubiquitous, you might think that this exploit would have gone the way of the VCR or the dot-matrix printer. Wrong. DNS tunneling has been adopted by a whole new class of attacker – those who now leverage it for infiltration/exfiltration purposes: evading the network firewall to get information into or out of the network.
In the past, when the concept was first conceived, a DNS tunnel wasn’t the easiest thing to setup, and took a fairly savvy individual to get one working. Today, toolkits and instructional videos on how to leverage a DNS tunnel are openly available online. This has made it easier for someone to access unwanted content, steal data or documents, or even plant malware into your organization.
Although DNS tunnels are now easy to setup, they are unfortunately, hard to detect. 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 DNS is not the only protocol that can be used to form a tunnel, its prevalence in normal network communications may make it easier to lose in the background noise. Adding to that is the fact that DNS queries and responses aren’t completely uniform, so it may not always be easy to spot the ones that don’t conform to “standards.” Nevertheless, the sheer potential for damage makes it worthwhile to take every precaution.
One of the elements that attackers rely upon when utilizing DNS tunneling is that no one will suspect it as an avenue for attack or exfiltration.
So, what can you do to detect potential DNS tunneling on your network? You can start by examining the DNS queries themselves. A good threat feed 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, you may be able to block outgoing requests at that point. Additionally, you can also 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, and this goes without saying, 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 world of hurt later.
