DNS exfiltration and how to detect it in your own logs

The lookup that picked the victims

In December 2020, SolarWinds told the SEC that fewer than 18,000 customers had installed a version of its Orion network monitoring software carrying a backdoor. The company later said the attackers actually went on to exploit fewer than 100 of them. The obvious question is how the attackers narrowed 18,000 down to under 100 without tripping anything. The answer is that they used the phone book. The SUNBURST backdoor's first act was not to open a connection. It was to ask a question: a DNS lookup for a hostname like 7sbvaemscs0mc925tb99.appsync-api.us-west-2.avsvmcloud.com. That gibberish string was not gibberish. It was the victim's internal Active Directory domain name, encoded and packed into the hostname, sent out one 14-character chunk at a time, according to Symantec's analysis. A second query encoded a bitmask of which endpoint security products were running: CrowdStrike, Carbon Black, FireEye, ESET, F-Secure, Microsoft Defender. The attackers sat on their authoritative nameserver and read the incoming queries like a list of applicants. Netresec, a Swedish network forensics firm, later reconstructed the encoding well enough to identify 23 organisations the attackers had promoted to stage two, simply by decoding captured DNS query names. No file was uploaded. No outbound TCP session was established to a suspicious IP. Every firewall in the path did exactly what it was configured to do.

Why DNS is the one door that is always open

The Domain Name System turns names into addresses. When your laptop wants example.com, it asks a recursive resolver, usually one your network hands you over DHCP. If the resolver does not already know the answer, it walks down the tree: ask a root server who handles .com, ask the .com servers who handles example.com, then ask that authoritative nameserver for the record. That last step is the whole trick. If I register evil.com and point its nameserver at a machine I control, then any device anywhere that can reach any recursive resolver can deliver a message to me. The device does not need to reach my server. It does not need outbound internet access at all. It only needs to be able to ask a question, and the resolver will carry it the rest of the way, hop by hop, on its behalf. This is why the usual egress controls miss it. Blocking outbound port 53 at the perimeter does nothing if the internal resolver is the one making the upstream query, which is exactly how a well-run network is supposed to work. Captive portals on hotel and airport Wi-Fi resolve DNS before you pay, which is why people have used DNS tunnels to get free internet for twenty years. MITRE catalogues the technique as T1071.004, Application Layer Protocol: DNS, and lists more than forty malware families and groups that use it, including Cobalt Strike, ShadowPad, Sliver, APT34, APT39, APT41 and FIN7.

How you fit data inside a question

DNS was standardised in 1987, and RFC 1035 set the limits that still govern every tunnel built since. Each label (the chunk between dots) can be at most 63 octets, because the length field is a single byte and two of its bits are reserved as flags for compression pointers. The whole name, length bytes included, is capped at 255 octets. Names are traditionally case-insensitive and restricted to letters, digits and hyphens, which is why tunnels reach for base32 or base16 rather than base64: they need an alphabet that survives a case-folding resolver. So the outbound channel is the query name, a few hundred bytes at a time, minus whatever the attacker's own domain suffix costs. The inbound channel is the answer. TXT records are the roomiest, which is why TXT and the obsolete NULL record type show up so often in tunnel tooling. dnscat2 defaults to TXT, CNAME and MX. iodine defaults to NULL. Palo Alto's Unit 42 has documented C2 traffic where the TXT response carried a base64-encoded executable payload, and cases where the command itself was smuggled in the four bytes of an A record's IP address, giving roughly 4.29 billion distinct instructions in a single normal-looking answer.

None of this is new. Oskar Pearson floated DNS covert channels on a mailing list in 1998. NSTX appeared around 2000. In July 2004, Dan Kaminsky released OzymanDNS, a Perl tool that ran SSH over DNS, and demonstrated streaming audio through the DNS cache hierarchy at Black Hat. iodine followed in 2006, dnscat in 2010. The techniques in the SolarWinds backdoor were sixteen years old when it shipped.

The misconception: exfiltration does not mean bulk transfer

The mental image most people carry is a database being siphoned out through DNS, gigabytes crawling through a pinhole. That happens, and when it does it is loud and relatively easy to catch. It is also the least interesting case. The dangerous case is low and slow. Asaf Nadler, Avi Aminov and Asaf Shabtai put a number on it in a 2017 paper that has become a reference point: an attacker who throttles hard enough to evade their detector is left with roughly 1 kilobyte per hour of payload. They then make the point that matters. One kilobyte per hour is "equivalent to five credit cards details, or ten user credentials per hour." That is not a rounding error. That is a business. Multigrain, the point-of-sale malware FireEye disclosed in April 2016, was built on exactly that arithmetic. It scraped memory from a single named process, validated candidate card numbers with the Luhn checksum, encrypted each track 2 record with a 1024-bit RSA public key, encoded the result with a custom base32 alphabet, and flushed its buffer to DNS every five minutes. It had no HTTP fallback at all. DNS was the only way out, and that was a deliberate design choice, because in a payment environment DNS is often the only thing that leaves. Iran-linked APT34 built a whole line of custom backdoors on the same idea. Cisco Talos's DNSpionage and Karkoff research traced campaigns against targets in Lebanon and the UAE through late 2018, with C2 alternating between DNS and HTTP and payloads obfuscated with base64 plus a single-byte XOR. Talos's own conclusion was blunt: DNS deserves to be monitored as closely as proxy or web logs. A second misconception worth killing: SUNBURST was widely described at the time as using a domain generation algorithm. It did not, in the usual sense. A DGA produces throwaway domains to make blocklisting futile; the names carry no information. SUNBURST's names were the information, deterministically encoded and reversible by anyone who worked out the custom base32 alphabet (ph2eifo3n5utg1j8d94qrvbmk0sal76c, with reversed byte order). Netresec and others have argued this is better described as a one-way tunnel than a DGA. The distinction matters operationally, because DGA detection looks for randomness and churn, and encoded-exfiltration detection looks for information content and volume per parent domain. Tune for the wrong one and you miss.

What it looks like in your logs

The good news is that the physics are on the defender's side. Every byte the attacker gets out has to appear, somewhere, as bytes on the wire. You cannot encode your way around that.

The signals that actually work, roughly in order of how much they earn their keep:

• Unique subdomains per registered domain, per client. This is the strongest single feature and the most underused. Normal clients ask about a small, repeating set of hostnames under any given domain. A tunnel asks about a new one every single time, because the hostname is the payload. Aggregate at the registered-domain level (the "second-level domain" plus TLD), not per query.
• Total bytes of query name sent to one domain over a window. This is the closest thing to a direct measurement of exfiltrated volume, and it is what the 2023 Information-based Heavy Hitters work by Ozery, Nadler and Shabtai formalises: estimate the information transmitted to each registered domain in constant memory, and alert past a threshold.
• Query name and label length. Tunnels push toward the 63-octet label ceiling because shorter labels waste capacity. Labels over 40 to 50 characters are unusual outside of tunnels, CDNs and a handful of security vendors.
• Character entropy. Base32 and base64 output is close to uniform over its alphabet, so it scores high on Shannon entropy where English-ish hostnames score low. A per-label entropy above roughly 4.0 bits per character is a common starting threshold.
• Record type mix. TXT and NULL queries are rare in ordinary traffic and common in tunnels. A client where TXT exceeds a tenth of its DNS volume is worth a look.
• NXDOMAIN ratio. Many tunnels never bother returning a valid record for upstream-only messages, so the resolver logs a flood of non-existent-domain responses under one parent.
• Timing regularity. Beacons are machines. Machines are punctual. Jitter analysis catches what content analysis misses.
• The process that asked. On Windows, Sysmon Event ID 22 records the DNS query and the process image that made it. PowerShell, rundll32 or an unsigned binary issuing hundreds of long queries is a far higher-quality signal than the query name alone. Where to find the data depends on your estate. Zeek's dns.log gives you query name, type and response code per transaction on any span port. Windows DNS Server has its analytical event log, and Sysmon covers endpoints. In AWS, Route 53 Resolver query logs record every lookup from your VPC, and GuardDuty consumes them automatically when instances use the AWS resolver. If you run a protective DNS service, the resolver logs are already centralised for you, which is half the battle. The prerequisite for all of it: force every client to use your resolvers, and block everything else. That means blocking outbound UDP and TCP 53 to anything but your own resolvers, and it increasingly means blocking known DNS-over-HTTPS endpoints too. NSA and CISA published joint guidance on selecting a protective DNS service on 4 March 2021, and its most quietly important point is not the blocking, it is that a central resolver gives you one place to log and hunt.

The base rate problem, which is where most programmes die

Here is what nobody tells you before you write your first detection rule: long, high-entropy, never-before-seen hostnames are extremely common, and almost all of them are benign. Dennis Tatang and colleagues at Ruhr University Bochum measured this directly. Analysing more than two billion newly observed hostnames from passive DNS over two months in 2019, they found that three second-level domains accounted for more than half of all new hostnames seen each day: Google's Accelerated Mobile Pages, Spotify, and a commercial DNS tunnel provider. Not a malware operator. A company selling tunnelling as a product. They also found that nearly all NULL-type queries and over a third of TXT queries on the open internet correlate with tunnelling activity of some kind. Unit 42's 2023 survey of tunnelling in the wild found the same picture from a different angle. Astrill VPN alone operated a corpus of 49 tunnelling domains. Services like HA Tunnel Plus, MinaProNet and Edoztunnel run on the open-source dnstt. And, awkwardly, security vendors themselves use DNS tunnelling to build cheap, universally routable telemetry channels for real-time reputation checks. Your antivirus is doing a passable impression of the thing you are hunting for.

Scale makes this worse, not better. Infoblox's 2025 DNS Threat Landscape Report counted 100.8 million newly observed domains over the year with 25.1 percent judged malicious or suspicious, and reported that 95 percent of threat-related domains appeared in only a single customer environment. Global reputation lists cannot save you from a domain nobody else has ever seen. The practical consequence is that a global threshold ("alert on any label over 50 characters") will drown you, and the fix is per-domain and per-client baselining plus an explicit allowlist of the tunnellers you have decided to tolerate. Build the allowlist deliberately and review it, because "we allowlisted the weird domain" is how this fails.

How much of the published accuracy should you believe

Detection papers report spectacular numbers. Nadler and colleagues claim 99 percent recall at under 0.01 percent false positives for tunnelling. The ibHH work reports catching exfiltration as slow as 0.7 bytes per second with a false positive rate below 0.004, evaluated across more than 250 billion real DNS queries. Treat those as ceilings, not forecasts. A recurring critique in the literature, made directly in a 2023 paper in the International Journal of Information Security, is that most published evaluations generate their attack traffic using off-the-shelf tunnelling tools in default configuration. Default iodine is a screaming siren. An attacker who shortens labels, pads with dictionary words, rotates across dozens of registered domains, randomises timing and caps throughput at a few hundred bytes an hour is a different adversary from the one the model was scored against. Reported detection rates against default tooling are, in the authors' framing, overly optimistic. That is not an argument against detection. It is an argument for measuring volume per domain rather than weirdness per query, because volume is the one thing the attacker cannot hide and still get paid.

What breaks next

Everything above assumes you can read the query name. That assumption is eroding. DNS-over-HTTPS and DNS-over-TLS encrypt the client-to-resolver hop. For a browser or an application shipping its own resolver configuration, the query never appears on your network in a form you can parse, and it may not reach your resolver at all. Researchers are already publishing detectors that work on encrypted DoH flows using packet sizes and timing rather than content, which is a harder and far less certain game. CISA has published implementation guidance for encrypted DNS that tries to square privacy with enterprise visibility, essentially by insisting the encryption terminate on a resolver you own. Which leaves an open question worth sitting with. The security argument for centralised, logged, inspectable DNS is strong, and it is the same architectural argument that privacy advocates spent a decade fighting, for good reasons, on behalf of people whose ISPs and governments were reading their lookups. Both sides are right. The resolution most organisations will land on, run your own encrypted resolver and log at that point, works fine for a managed corporate laptop and works not at all for the phone in an employee's pocket. The attackers already know which of those two your data is sitting on.

Sources

1. SolarWinds Corporation, Form 8-K filed with the U.S. Securities and Exchange Commission, 14 December 2020 (2020)
2. Symantec / Broadcom, SolarWinds: How a Rare DGA Helped Attacker Communications Fly Under the Radar (2021)
3. Netresec, Targeting Process for the SolarWinds Backdoor (2021)
4. The Record, SolarWinds says fewer than 100 customers were impacted by supply chain attack (2021)
5. MITRE, ATT&CK Technique T1071.004: Application Layer Protocol: DNS (accessed 2026)
6. P. Mockapetris / IETF, RFC 1035: Domain Names, Implementation and Specification (1987)
7. Unit 42, Palo Alto Networks, DNS Tunneling: How DNS Can Be (Ab)used by Malicious Actors (2019)
8. Unit 42, Palo Alto Networks, Understanding DNS Tunneling Traffic in the Wild (2023)
9. Rob Fuller, OzymanDNS: Tunneling SSH over DNS, on Dan Kaminsky's 2004 tool (2009)
10. Asaf Nadler, Avi Aminov and Asaf Shabtai, Detection of Malicious and Low Throughput Data Exfiltration Over the DNS Protocol, arXiv:1709.08395 (2017)
11. Yarin Ozery, Asaf Nadler and Asaf Shabtai, Information-Based Heavy Hitters for Real-Time DNS Data Exfiltration Detection and Prevention, arXiv:2307.02614 (2023)
12. Dennis Tatang, Florian Quinkert, Nico Dolecki and Thorsten Holz, A Study of Newly Observed Hostnames and DNS Tunneling in the Wild, arXiv:1902.08454 (2019)
13. Baran Işık, Bilal İhsan Tuncer, Novruz Amirov and Şerif Bahtiyar, DNS Tunneling: Threat Landscape and Improved Detection Solutions, arXiv:2507.10267, Istanbul Technical University (2025)
14. SecurityWeek, "Multigrain" PoS Malware Exfiltrates Card Data Over DNS, reporting FireEye research (2016)
15. Cisco Talos, DNSpionage Brings Out the Karkoff (2019)
16. NSA and CISA, Joint Guidance on Strengthening Cyber Defense Through Protective DNS (2021)
17. CISA, Encrypted DNS Implementation Guidance, Version 1.0 (2024)
18. Infoblox, 2025 DNS Threat Landscape Report (2025)
19. Springer, International Journal of Information Security, DNS exfiltration detection in the presence of adversarial attacks and modified exfiltrator behaviour (2023)
20. Amazon Web Services, Route 53 Resolver query logging (accessed 2026)