Detecting Data Exfiltration Over DNS: Signals That Survive Encrypted Transport

DNS is the quietest channel out of a network. Egress filtering often permits it because resolution is essential, it is rarely inspected because it looks like infrastructure traffic, and it can carry data in the query name itself. The modern complication is that encrypted transports hide the query content from the resolver path, while the resolver still sees the pattern.

Why the channel is attractive

An attacker with code execution inside a network needs a route out. Firewalls typically allow the internal resolver to reach upstream servers on port 53, and the internal resolver answers queries from every host. Encoding data in the leftmost labels of a query name means the payload travels inside a legitimate protocol.
MITRE ATT&CK documents this as application layer protocol abuse under T1071, and data transfer over alternative channels under T1048. The techniques describe the pattern rather than the tooling, which is why the detection guidance is behavioural.

Signals that remain visible

Even where the query content is encrypted in transit, the resolver observes the shape of the traffic. Several measures distinguish tunnelling from ordinary resolution.

• Query name length distribution. A long, high-entropy leftmost label appears in encoding schemes and rarely in legitimate names. Comparing against a baseline for the domain catches a shift.
• Volume of unique subdomains per parent domain. A domain that receives thousands of distinct random labels from a single internal host does not match normal application behaviour.
• NXDOMAIN rate. A tunnelling client frequently queries names that do not exist, while a legitimate application resolves known names.
• Record type distribution. Abusive use favours TXT and NULL record queries and record types that ordinary clients do not request.
• Periodicity. A client that queries on a fixed interval with steady payload size is a strong indicator. Encrypted transports change what is visible on the wire, not what the internal resolver observes. If internal hosts use an encrypted resolver they contact directly, the organisation loses the visibility entirely, which is an argument for controlling which resolvers endpoints may use.

Building the detection

Start from data you already retain. Resolver logs, if collected, are enough for the first three signals, and flow records are enough for volume and periodicity.

• Establish a baseline per internal subnet, because server and workstation behaviour differ.
• Alert on sustained high-entropy label use toward any external parent domain, not only toward domains on a threat list.
• Watch for internal hosts using external resolvers directly, which is both a policy violation and a visibility loss.
• Retain resolver logs for a period that matches the organisation's incident response window, since exfiltration is usually found weeks after it starts.

Defensive implications

• Restrict outbound resolution to controlled resolvers so the observation point exists.
• Treat DNS query volume as a monitored resource, similar to authentication failures.
• Test detection with an authorised exercise, because a rule that has never fired should not be trusted.
• Understood as a containment measure, blocking a domain stops one channel. Encoding to a new domain restarts the problem, so the durable control is egress restriction from the compromised segment. A limit worth stating: these signals detect volume and shape, not intent. A misbehaving internal application can produce the same pattern, which is why the response is investigation rather than automated blocking.

References

• MITRE ATT&CK T1071, Application Layer Protocol. https://attack.mitre.org/techniques/T1071/
• MITRE ATT&CK T1048, Exfiltration Over Alternative Protocol. https://attack.mitre.org/techniques/T1048/
• RFC 4034, Resource Records for the DNS Security Extensions. https://www.rfc-editor.org/rfc/rfc4034