T1071.004

DNS

What it is

DNS is one of the few protocols that's essentially always permitted to leave a network, unrestricted, on every host, because every device needs to resolve domain names to function. That universality is exactly why attackers abuse it: an outbound DNS query is far less likely to be blocked or scrutinized than most other traffic.

Data gets encoded into DNS queries and responses themselves. A command, a chunk of stolen data, or a beacon "check-in" is packed into a subdomain (a-very-long-encoded-string.attacker-domain.com), and the response carries data back the same way. No dedicated malware needs to establish its own protocol; it just talks DNS.

How adversaries use it

This shows up in two forms. As an ongoing command-and-control channel, a compromised host periodically queries the attacker's domain, encoding a check-in or awaiting instructions in the query and response. As an exfiltration channel, stolen data is broken into chunks small enough to fit in DNS query labels and sent out one query at a time.

It's particularly attractive in environments with strict egress filtering on other protocols, since DNS resolution is rarely blocked even when almost everything else is.

Detect it in Elastic

Data source: network sensor DNS records, repeated TXT lookups under one parent name answered NXDOMAIN, plus host-side DNS query events naming the process (Sysmon Event ID 22)

Key fields

dns.question.name (the queried domain, where tunneling traffic shows unusually long, high-entropy subdomains), dns.question.type (TXT and NULL record types are disproportionately used for tunneling, since they can carry more data than a standard A record), and query volume/frequency to a single domain from a single source host.

Example event

{
  "dns": {
    "question": {
      "name": "a8f3e91c2b7d4f0e.attacker-c2.net",
      "type": "TXT"
    }
  },
  "host": {
    "name": "APP01"
  },
  "event": {
    "action": "dns_query",
    "category": "network"
  },
  "source": {
    "ip": "10.1.10.13"
  }
}

Prebuilt Elastic rule: DNS Tunneling

Hunt guidance

Normal DNS traffic is short domain names with recognizable, pronounceable structure. Tunneling traffic looks different: long, high-entropy (effectively random-looking) subdomains, an unusually high volume of queries to one specific parent domain, and a skew toward TXT/NULL record types rather than the standard A/AAAA lookups that make up the vast majority of legitimate traffic.

Hunting manually: aggregate DNS query counts by parent domain per host over a short window and look for outliers. One domain receiving dramatically more queries than any other from a single source is the core signal, independent of what the specific subdomains contain.

Ruling out legitimate activity

Some legitimate services generate high-volume or unusual-looking DNS traffic by design. CDNs, telemetry/analytics services, and certain security products that use DNS for reputation lookups can all produce query patterns that superficially resemble tunneling.

The distinguishing signal is consistency with a known, documented service versus an unrecognized domain: a high query volume to a well-known CDN or analytics provider your organization already uses is expected; the same pattern to a domain nobody recognizes, registered recently, or with no legitimate business purpose is what warrants escalation. Maintain an allowlist of your organization's known high-volume DNS consumers so genuinely novel destinations stand out.

References

Practice it

1 scenario in this catalog covers T1071.004. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →