Blog Post

DNS Exfiltration: The Light at the End of the DNS Tunnel

DNS data exfiltration is a way to exchange data between two computers without any direct connection. The data is exchanged through DNS protocol on intermediate DNS servers. During the exfiltration phase, the client makes a DNS resolution request to an external DNS server address. Instead of responding with an A record in response, the attacker’s name server will respond back with a CNAME, MX or TXT record, which allows a large amount of unstructured data to be sent between attacker and victim.

The Awake Security Platform autonomously detects such DNS exfiltration. In fact, while recently reviewing one such discovery in a customer environment, I came across a textbook case of DNS tunneling:

Figure 1: DNS Tunneling in customer environment

This was the only kind of traffic that matched this behavior in the environment, and looks incredibly similar to the DNS tunneling sample that was part of the Tolly Test we participated in this Summer:

Figure 2: DNS Tunneling via dnscat2 tool

At this point we have the knowledge about the behavior (DNS tunneling) and the domain:

Figure 3: Destination domain for DNS tunneling traffic

Open source intelligence led me to a whitepaper on Canary honeypots, where I found a few helpful snippets:

Figure 4: Diagram of how Canary Honeypots work

Perhaps my favorite piece of information in the document is the following paragraph, which is right in the Introduction section:

Answer solved. We’ve got a Canary honeypot regularly communicating back out to its infrastructure using TTPs cultivated and oft-used by attackers.

Why does it matter?

While the above detection is not actually malicious, it is a fantastic example of how true behavioral detection can help to find complex adversaries without the need for signatures. The underlying detection has been used to find all sorts of interesting behavior that would otherwise go completely unnoticed. And because of the power of in-product information, Awake takes the guesswork out of response.

David Pearson
David Pearson

Principal Threat Researcher