DNS always gets through, so attackers hid data in it

The scenario is fictional (RFC 5737 and 10.0.0.0/8 addresses). Detection only.

You can close almost all outbound traffic, but not DNS: if names don't resolve, the business stops. Attackers know it and hide stolen data inside query names. Few organizations watch for it.

What you'll learn

• Why DNS tunneling slips through
• Four detection signals
• Aggregation commands tested on synthetic data
• Telling it apart from CDNs and security products

The story at a glance

After wiping local logs (part 6), web03 (10.0.0.50) kept talking, but only through DNS: a flood of queries to *.exfil.203-0-113-9.example, mostly TXT.

Normal vs. tunneling

normal   cdn.example.com                                A
attack   a3f9c2e1b7d4....exfil.203-0-113-9.example      TXT

Four signals

awk '{print $2}' dns.log | sort -u \
 | awk '{n=split($1,a,"."); print a[n-2]"."a[n-1]"."a[n]}' \
 | sort | uniq -c | sort -rn | head
awk '$3=="TXT"{t++} END{printf "TXT ratio %d%%\n", t*100/NR}' dns.log

On a synthetic log (200 random queries under exfil, 300 normal) the top line was 200 exfil.203-0-113-9.example; every normal domain had 1. Length >= 30 with Shannon entropy >= 3.0 flagged all 200 random labels and none of the normal ones. Tune the thresholds on your own baseline.

Where to watch: the DNS server (Windows DNS Analytical, event 260; client event 3008) or Zeek dns.log (book details, not run here).

False positives

CDNs, security products and cloud services query many dynamic subdomains. Allow-list known parents and keep unknown parent x high entropy x TXT skew.

Defense

Force clients to the internal resolver, block external DNS and DoH/DoT, and ship DNS logs somewhere the host can't erase.

Next: ten thousand failed logins don't matter. One success does.

Adapted from chapters 3, 17 and 18 of my Japanese book on server defense.