dns tunneling: exfiltrating data through port 53

in the reverse shell post, the trick was that outbound traffic is always allowed. but what if egress filtering kills port 4444? what if the only way out is DNS? there's a rule almost nobody breaks: DNS has to work, or nothing works.

the idea: hide your data inside the question

a normal DNS query asks something like "what's the IP of daoudi.li". but the domain part of a query can be up to 253 characters, and each label (the parts between dots) up to 63. so who says a subdomain has to be a real word?

c3RhbmRieS1jb2RlLWhlcmU.daoudi.li

that first label is just base64-encoded data. an attacker who controls the nameserver for their domain receives that query, and the question itself is the message. the answer can carry data back too, hidden in TXT records.

so malware doesn't need a direct connection to anywhere. it just asks DNS about weirder and weirder subdomains, and the attacker's nameserver reads them as they arrive:

malware ──"resolve h3llo.daoudi.li"──▶ resolver ──▶ attacker's nameserver
attacker's nameserver reads "h3llo" ✓ and replies "no such host" (or real data in TXT)

the resolver does all the network legwork for free, and the malware never talks to the attacker directly. the public DNS infrastructure is doing the transporting.

tools and a safe demo

the famous tools here are iodine and dnscat2, which will build you a full IP tunnel or even an encrypted command channel over pure DNS. you don't need either one to see the principle. run this against a domain you own:

dig TXT somedata.daoudi.li

then check the query logs on your DNS provider. your string is right there in the query, having traveled through whatever resolvers were in the path. that's exfiltration at its simplest: the domain name was the file.

why it survives locked-down networks

• port 53 is open on basically every network, including corporate and hotel wifi that block everything else
• queries go through the legit recursive resolver, so from the firewall's perspective the client is just doing DNS
• no direct connection to a suspicious IP ever exists. egress filtering was the fix for reverse shells, and this goes around it, because you can't block DNS without breaking the internet

how to detect it anyway

the traffic is visible, just unusual. what to look for:

• very high query volume from one host. normal machines do a handful of DNS queries, not thousands
• long, high-entropy subdomains like x8f2jd9a under a single domain. real subdomains are www or blog, not random-looking blobs
• lots of queries to domains that mostly return NXDOMAIN. the malware doesn't care if the answer says "no such host", the question already delivered the data
• TXT record queries dominating. legitimate clients barely ever ask for TXT

that last point is also why T-Pot-style setups and DNS logs matter. there is no signature to match, only the shape of the traffic.

defending

• allow outbound DNS only to your known resolvers, not to any random server on port 53. this kills the case where the attacker runs their own nameserver
• block TXT queries to external domains for machines that have no business doing that
• monitor DNS logs. volume and entropy per client is a cheap and effective detection, and enterprise DNS servers can do it natively. a small script over the logs will do otherwise

the resume of the writing

• DNS queries can carry data inside the subdomain: the question is the message, and the answer (TXT records) carries data back
• it works everywhere because blocking DNS breaks everything, and no direct connection to the attacker ever happens
• detect it by shape: huge query volume, long random-looking subdomains, weird TXT usage
• defend by letting machines query only known resolvers, and actually reading your DNS logs