Detect DNS Tunneling for Covert Data Exfiltration in Elastic Security

DNS tunneling encodes stolen data inside the query names (and occasionally TXT/NULL record responses) of DNS lookups, exploiting the fact that DNS is almost universally permitted outbound even in tightly filtered network environments. OilRig/APT34 has repeatedly built DNS-based communication into its custom malware families, using DNS resolution as both a C2 and exfiltration channel to survive proxy and firewall egress controls. FIN7 has used DNS tunneling against point-of-sale and retail environments where HTTP(S) egress was more tightly monitored than DNS. APT41 has deployed publicly available DNS tunneling frameworks such as dnscat2 during intrusions where direct HTTP(S) exfiltration was blocked. Commodity tooling in this space — iodine, dnscat2, DNSExfiltrator, and PacketWhisper — all share the same observable signature: large volumes of DNS queries for subdomains of an attacker-controlled domain, where the subdomain label itself is a base32/base64/hex-encoded chunk of stolen data, together with an abnormal skew toward TXT/NULL/CNAME query types and elevated NXDOMAIN rates (since many tunneling implementations use non-existent subdomains purely as a data-carrying vehicle). This detection deliberately focuses on DNS query-log analytics rather than endpoint process telemetry, since it catches tunneling traffic that a purely process-based detection would miss (e.g., DNS tunneling from a compromised network appliance, or malware that resolves names via direct socket calls rather than a monitored DNS client process) and is a good complement to the process-execution-based detections already covered on the parent T1048.003 page.