DNS tunnelling

DNS resolution is a request-and-response that most networks permit outbound, even when direct web and other traffic is filtered, because name resolution has to work. Tunnelling abuses that. The attacker controls the authoritative name server for a domain; a compromised host encodes data into the labels of a query for that domain (for example, as subdomains), the query is resolved by the organisation’s own resolvers out to the attacker’s server, and the answer carries data back. Chaining many such lookups creates a slow but reliable bidirectional channel that can carry command and control traffic or exfiltrate data. It is not fast, but it does not need to be: it needs to be allowed.

The gap it exploits is an egress policy that stops at the obvious protocols. Teams block outbound web to unknown destinations but let internal hosts query external name servers freely, or route DNS through a resolver that never inspects the volume or shape of what it is resolving. From the offensive side, this is the fallback when a target has done the visible work well: proxies, web filtering and blocked ports, but forgot that DNS is a channel. The tell is behavioural (a host generating a high rate of unusual lookups to a single domain, or queries with long, high-entropy labels), which is exactly the signal an estate focused on blocking rather than watching will miss.

We test whether a covert channel actually gets out, DNS included, and we record the path: which resolvers a compromised host can reach, whether volume and query shape are inspected, and whether the channel could be established end to end. The finding is written against the egress and detection gap that allowed it. It sits alongside other stealth techniques such as DNS over HTTPS as a route to blend command traffic into permitted flows. This is part of how we test whether covert channels get out.