DNS Tunneling Still Works in 2024. Most Networks Don't Look for It.

Cybersecurity

DNS leaves your network on port 53 by default and most security tools don't inspect it. Attackers have known this since 2004. Here's what modern DNS tunneling looks like, how to detect it, and how to make it stop working.

By Arjun Raghavan, Security & Systems Lead, BIPI · January 13, 2024 · 7 min read

I ran a tabletop with a fintech security team in November 2023. We modeled a scenario where the attacker had compromised one workstation and needed to exfiltrate a 4GB database dump. The SOC lead walked through their detection coverage confidently until I asked what would catch DNS-based exfiltration. Silence. Then someone said "we'd see the spike on the firewall". I asked which firewall log field would show DNS payload size. More silence.

DNS tunneling is a 20-year-old technique. iodine has been on GitHub since 2006. dnscat2 has been actively maintained since 2014. Every red team training course covers it. And yet most enterprise networks have no detection for it because the traffic looks like normal DNS, leaves through normal resolvers, and never trips an IDS signature.

How the Tools Actually Work

iodine establishes an IP-over-DNS tunnel. The client encodes IP traffic into the labels of subdomains of an attacker-controlled domain, then queries those subdomains. The authoritative DNS server (which the attacker runs) decodes the labels back into IP packets, processes them, and encodes responses in TXT or CNAME records. Throughput is poor (a few KB/s typically) but it's enough for shell access and slow exfil.

dnscat2 is more flexible. It doesn't try to be a full IP tunnel, it just provides an encrypted command-and-control channel. The encoded data goes in TXT, MX, or CNAME records depending on configuration. Sessions, encryption, and command shells are all built in. Throughput is still poor but reliability is higher.

Cobalt Strike's DNS beacon and Mythic's DNS profiles are the commercial-grade equivalents. They batch queries, randomize timing, and blend with legitimate DNS patterns. They are noticeably harder to detect than iodine.

Detection Signals That Actually Work

Single signals create false positives. Combinations create detections. The signals worth correlating:

• Subdomain entropy, random-looking labels (no real words) score high on Shannon entropy
• Query length, legitimate DNS rarely exceeds 50 characters; tunneling often uses 150+
• TXT and NULL record rates, most clients never request TXT; high TXT volume per client is anomalous
• Unique subdomain count per parent domain per hour, tunneling generates hundreds of unique subdomains
• NXDOMAIN ratio, some tunnels generate elevated NXDOMAIN rates as part of their protocol
• Query rate per client to a single domain, sustained 10+ qps to one parent domain is suspicious

The detection most teams miss: outbound DNS to resolvers other than the corporate resolver. iodine, dnscat2, and Cobalt Strike DNS beacon all need to reach the attacker's authoritative server, but many implementations let you route through public resolvers first (8.8.8.8, 1.1.1.1). If your endpoints aren't supposed to talk DNS directly to public resolvers, alert when they do.

Defense by Architecture

Detection is a backstop. Make the technique stop working in the first place. The architecture pattern:

1. All client DNS queries go to corporate resolvers (Active Directory DNS, BIND, or managed services like Infoblox)
2. Firewall blocks all outbound UDP/TCP 53 from endpoints except the corporate resolvers
3. Corporate resolvers do recursive resolution OR forward to a filtered upstream (Cisco Umbrella, Cloudflare Gateway, Quad9)
4. DNS query logs from the corporate resolvers flow into the SIEM with full query, response, and client fields
5. Newly-registered-domain (NRD) blocking on the resolver, most C2 domains are under 30 days old

DNS firewalls (RPZ zones, or commercial DNS security gateways) add another layer. They block lookups to known-bad domains using threat intel feeds. Spamhaus DBL, ThreatSTOP, and Cisco's Umbrella ThreatGrid all publish RPZ-compatible feeds. The hit rate on lookups blocked at the resolver is consistently 0.5-2% of total queries in environments we've measured, which means measurable risk reduction without breaking anything legitimate.

Measuring Coverage

Once detection and architecture are in place, validate with red team or Atomic Red Team. T1071.004 (Application Layer Protocol: DNS) has atomics that run iodine and dnscat2 in test mode. Run them monthly. If your detections don't fire, the rule needs tuning. If your firewall doesn't block the traffic, the architecture has a hole. Both findings are gifts.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.