DNS Exfiltration Hides Inside Allowed Traffic and Your SIEM Never Flags It

Your firewall rules are tight. Your DLP solution scans outbound HTTP and HTTPS. Your SIEM is correlating events across every endpoint and server. You have blocked every known bad IP range and every suspicious domain category.

And right now, an attacker who has been inside your network for eleven days is sending your customer database out through DNS queries. Not through a tunnel. Not through a covert channel you would recognize as unusual. Through the same protocol that every single device on your network uses thousands of times a day to resolve domain names — and your SIEM has not generated a single alert.

DNS exfiltration is not exotic. It is not a nation-state technique. It is a method that appears in commodity malware, in red team engagements, and in real breach post-mortems at organizations that considered themselves well-defended. The reason it succeeds is not that defenders lack the technology to detect it. It is that the detection requires a different kind of thinking than blocking known-bad indicators — and most security teams have not made that shift.

How DNS Becomes a Data Channel

DNS was designed to be available everywhere. Corporate security architectures accommodate this reality: even in networks with strict egress filtering, DNS is almost always permitted outbound — either directly to authoritative resolvers or through an internal recursive resolver that forwards upstream. The assumption is that DNS traffic is benign because it is resolving domain names, not transferring data.

That assumption is the attack surface.

Here is the mechanism. An attacker controls a domain — c2.attackerdomain.com — and operates an authoritative DNS server for that domain. To exfiltrate data, they encode it into DNS query strings. A file being exfiltrated might produce queries like:

YWRtaW4=.c2.attackerdomain.com
dXNlcm5hbWU=.c2.attackerdomain.com
cGFzc3dvcmQ=.c2.attackerdomain.com

Each subdomain label is a Base64-encoded chunk of the target data. The queries travel from the compromised host to your internal DNS resolver. Your resolver, having no record for these subdomains, forwards the queries upstream — to the attacker's authoritative server. The attacker's server receives the queries, decodes the subdomain labels, reassembles the file, and returns valid DNS responses that look completely normal.

No TCP connection. No HTTP session. No TLS handshake. Just DNS queries, which are permitted everywhere.

The throughput is limited — DNS query labels max at 63 characters, the full domain name at 253 characters — but for exfiltrating credentials, configuration files, or a compressed database of customer records, the bandwidth is sufficient. Real attacks have exfiltrated gigabytes through this channel over days or weeks.

The key insight is that the data never flows directly to the attacker. It flows to your DNS resolver, which dutifully forwards it upstream as part of normal recursive resolution. Your resolver is the unwitting relay.

Why Your SIEM Does Not Flag This

Normal DNS activity on a corporate network produces thousands of queries per hour — a mix of internal resolution, external SaaS domains, update servers, CDN endpoints. The volume is high and the pattern is predictable: the same domains appear repeatedly (cached until TTL expiry), most queries are for well-known domains, and the subdomain structure follows recognizable patterns.

DNS exfiltration produces a different pattern, but not an immediately obvious one:

• High query volume to a single domain — but this can look like a single application hitting one API endpoint repeatedly
• Unusually long subdomain labels — but some legitimate services use long subdomains
• Low or zero cache hit rate for a domain — every query is unique because each subdomain encodes different data, so nothing is ever cached
• High entropy in subdomain strings — Base64 and hex-encoded data looks statistically random, unlike the lowercase alphanumeric subdomains of legitimate services
• No successful connections to that domain through any other protocol — the domain exists only as a DNS exfiltration endpoint, so there will never be a corresponding HTTP or HTTPS session

The reason SIEMs miss this is not a detection rule gap in the obvious sense. It is that most SIEM DNS detection rules are built around known-bad indicators: flagging queries to known malicious domains, flagging queries to newly registered domains, and alerting on DNS query types associated with specific malware families. These are IOC-based rules.

DNS exfiltration to a freshly registered domain that has no prior reputation uses none of the infrastructure that IOC-based detection covers. A domain registered yesterday with a clean Whois record, a valid SSL certificate, and no categorization in any threat feed will pass every indicator check without triggering a rule.

The detection that works requires behavioural analysis — looking at DNS traffic as a stream and identifying statistical anomalies rather than matching against known-bad values. This is a fundamentally different capability from what most SIEM deployments are configured to do.

The Three Detection Methods That Actually Work

If IOC matching does not catch DNS exfiltration, what does? The detection methods that are effective share a common characteristic: they treat DNS query logs as a statistical dataset, not as an event stream to be matched against a blocklist.

Method 1: Subdomain entropy analysis

Shannon entropy measures the randomness in a string. Legitimate subdomain labels like api, cdn, mail, static, staging have very low entropy — they are composed of common English words and standard naming conventions. Base64-encoded data has entropy close to the theoretical maximum for its character set because the encoding is designed to distribute bits evenly across the output alphabet.

The detection rule: calculate the Shannon entropy of every subdomain label in outbound DNS queries. Flag queries where subdomain entropy exceeds a threshold — typically around 3.5 bits per character, compared to typical legitimate subdomains that score below 2.5. Apply this at the domain level: if the parent domain c2.attackerdomain.com is receiving consistently high-entropy subdomain queries from a single host, that is a high-confidence indicator.

The practical implementation: this requires DNS query logging at a granular level — not just the FQDN resolved, but the full query string including all subdomain labels. Many network DNS logs discard or truncate this information. Confirming your DNS log format captures full query strings is a prerequisite.

Method 2: Query frequency and uniqueness ratio

For any given domain, calculate the ratio of unique subdomains to total queries over a time window. For a legitimate domain, this ratio is very low — the same domain resolves repeatedly because the IP is cached, and the subdomain structure is stable. For a DNS exfiltration domain, this ratio approaches 1.0 — every query is unique because each subdomain carries a different data chunk.

The implementation: a rolling time window query of DNS logs, grouped by second-level domain, comparing unique subdomain count against total query count. A domain that generates 500 queries with 498 unique subdomains in a four-hour window is a strong indicator. This metric is simple to implement in a SIEM with DNS logging enabled and is resistant to false positives because legitimate CDNs and APIs do not generate this pattern.

Method 3: DNS-only domain correlation

Cross-reference domains appearing in DNS query logs against domains appearing in HTTP, HTTPS, and other protocol session logs. A domain that appears hundreds of times in DNS logs but never in any other protocol's traffic is suspicious. Legitimate application traffic almost always generates both a DNS query and a subsequent TCP connection. A domain that exists only in DNS queries — no HTTP, no TLS, no SMTP — is a signal worth investigating.

This correlation requires log sources from multiple network taps or proxy logs in addition to DNS, but the query is conceptually simple and can be automated as a scheduled SIEM query.

Each method works independently but the signal confidence multiplies when all three flag the same domain. A domain that fails all three checks simultaneously is worth immediate investigation.

What a Real Incident Looks Like — The SolarWinds Precedent

The most documented real-world use of DNS-based communication channels at scale is the SolarWinds compromise, where the threat actor used DNS-based communication to determine whether the infected SolarWinds Orion system was operating in an enterprise environment before activating the full backdoor.

The mechanism was not pure exfiltration but demonstrated the same detection-evasion logic: the malware generated DNS queries to an attacker-controlled domain as a check-in mechanism. The queries were structured to look like legitimate Orion telemetry traffic. The response codes — specifically the DNS response type and the IP returned — acted as command and control signals.

What made this successful at evading detection for months across thousands of organizations:

• The domain used (avsvmcloud.com) had been registered and configured to return benign responses during an initial dormancy period, so it would not appear in threat feeds as malicious
• The communication rate was throttled to blend with normal Orion network activity patterns
• The use of DNS rather than HTTP or HTTPS meant that organizations with strict web proxy monitoring had no visibility into the channel
• The entropy and query patterns, while anomalous by the standards described in the previous section, were not being actively monitored for by the detection teams at affected organizations

The SolarWinds case is relevant not because it is a typical DNS exfiltration incident — it is not, it was a nation-state operation — but because it demonstrates that the defence gap is not exotic. It is the absence of behavioural DNS analysis. Every organization that was compromised had a SIEM. Most had threat intelligence feeds. None of them were running the entropy and uniqueness ratio checks described above against their DNS logs.

Building the Detection Stack — What You Actually Need to Implement

Understanding the theory is different from knowing what to build. The gap between "we should analyze DNS entropy" and a working detection capability involves specific implementation decisions.

Step 1: Confirm your DNS logs capture full query strings

This sounds trivial. It is not. Many network monitoring tools log DNS resolutions — the final resolved IP for a domain — without logging the full query string including subdomain labels. Some recursive resolvers log only successful resolutions, discarding queries that fail or timeout.

Verify your DNS log format captures: source IP, full FQDN including all subdomain labels, query type (A, AAAA, TXT, MX), response code, and timestamp with second-level granularity. If it does not, the log source configuration needs to change before any detection logic is useful.

Step 2: Ingest DNS logs into your SIEM with the right field mapping

DNS logs vary enormously in format across different resolvers, network taps, and monitoring tools. Windows DNS Server logs have a different schema than Bind logs, Cisco Umbrella logs, and pfSense logs. The field that contains the full query string may be called QueryName, dns.question.name, query, or something else depending on the log source.

Verify field mapping before building detection rules. A misconfigured field mapping is the second most common reason DNS detection rules fail silently — they run against the wrong field and find nothing.

Step 3: Implement entropy scoring as a lookup or computed field

Shannon entropy calculation is not a native function in most SIEM query languages. The implementation options are:

• A pre-processing script that adds entropy scores as enrichment before ingestion
• A computed field defined in the SIEM that calculates entropy on the query string at search time
• An external analytics pipeline (Python script or scheduled Lambda) that batch-processes DNS logs and writes high-entropy detections back as events

The pre-processing enrichment approach is most reliable for real-time detection. The batch analytics approach is simpler to implement and sufficient for threat hunting if you are comfortable with detection latency measured in hours rather than minutes.

Step 4: Build the correlation rules

With entropy scoring and full query strings available, the detection rules are straightforward:

• Alert when a single source IP sends more than 100 DNS queries in any 60-minute window where the average subdomain entropy exceeds 3.5 bits per character
• Alert when a second-level domain's unique subdomain ratio (unique FQDNs / total queries) exceeds 0.90 over any 4-hour window for a domain generating more than 50 queries
• Report (not alert, for later review) any domain appearing 50+ times in DNS logs with zero corresponding sessions in web proxy or firewall logs

Step 5: Tune against your baseline

Before treating these rules as production alerts, run them against two weeks of historical DNS logs to identify legitimate services that might trigger false positives. Internal test automation, CI/CD pipelines, and certain SaaS products can generate high-entropy DNS traffic legitimately. Add these to an allowlist tied to specific source IPs or domain patterns.

The goal is a rule that fires rarely enough that it gets investigated every time it fires.

The Attacker's Countermeasures — What Makes Detection Harder

Understanding detection is incomplete without understanding the adaptations attackers make when they know behavioural analysis is running.

Slow exfiltration rates to stay below query thresholds

If a detection rule fires at 100 queries per hour, an attacker running at 40 queries per hour per endpoint stays below the threshold indefinitely. The data still exits — it just takes longer. The countermeasure is detection rules that analyze patterns over longer windows (24-hour uniqueness ratios rather than 4-hour) and lower volume thresholds that require more careful tuning against legitimate traffic.

Using legitimate-looking subdomain naming to reduce entropy

Instead of raw Base64 encoding, some exfiltration tools use encoding schemes that produce lower-entropy output — encoding data as sequences of common English words, or mixing encoded data with legitimate-looking prefix characters. This reduces entropy scores and can push the payload below detection thresholds if the entropy threshold is set conservatively.

The countermeasure: run entropy analysis on the full subdomain string, not just the first label. Also implement n-gram frequency analysis — checking whether the character sequences in subdomain labels follow the statistical patterns of real English domain names. Base64 and hex encoding fail n-gram analysis even when they superficially look more readable.

Splitting exfiltration across multiple domains

Instead of sending all data through one parent domain, distribute queries across ten domains. The per-domain query count and uniqueness ratio stay below alerting thresholds. The countermeasure requires correlating across domains — looking for patterns where multiple low-volume domains share the same characteristics simultaneously, originating from the same source IP.

These adaptations illustrate why DNS exfiltration detection is an ongoing process rather than a configuration you complete. Detection rules require tuning as attacker techniques evolve.

What DNS Exfiltration Detection Looks Like in Practice

A threat hunter investigating unusual network behavior at a mid-size financial services company sets up a scheduled Splunk query to identify high-entropy DNS domains:

index=dns_logs earliest=-24h
| eval subdomain=replace(dns_query, "\.[^.]+\.[^.]+$", "")
| eval entropy=entropy(subdomain)
| stats avg(entropy) as avg_entropy, dc(dns_query) as unique_queries, count as total_queries by src_ip, parent_domain
| where avg_entropy > 3.5 AND unique_queries > 50 AND unique_queries/total_queries > 0.8
| sort -avg_entropy

The query returns one result: a single workstation generating 847 DNS queries over 18 hours to cdn-static-eu.internal-metrics.io, with an average subdomain entropy of 4.2 and a uniqueness ratio of 0.98.

None of these queries appear in the web proxy logs. The domain was registered 9 days ago. The workstation belongs to an employee in the finance department.

That single SIEM query, which took 20 minutes to write, identified an active exfiltration that had been running for nine days without triggering any existing alert.

Closing: DNS Exfiltration Is One Vector in a Broader Covert Channel Threat

Understanding DNS exfiltration changes how you think about network security monitoring. The fundamental shift is from indicator-based detection — looking for known-bad things — to behavioural detection — identifying patterns that are statistically inconsistent with normal traffic regardless of whether the specific values have been seen before.

The adjacent problems that follow from this article are ones that practitioners encounter as they deepen their understanding of covert channel threats. How does ICMP tunnelling work, and what does its traffic profile look like compared to DNS exfiltration? What does HTTPS C2 communication look like when the attacker is using domain fronting or legitimate cloud infrastructure as a relay? How do you build a detection programme that systematically covers covert channel techniques rather than building one-off rules for each specific method?

These questions belong to the detection engineering discipline — the intersection of threat intelligence, network analysis, and security analytics that defines mature security operations.

The detection that works requires treating DNS query logs as a statistical dataset, not as an event stream to be matched against a blocklist. That shift in thinking is what separates the security teams that detect DNS exfiltration from the ones that discover it in the post-breach forensics.