SOP-32: DNS Exfiltration and Tunnelling Response

Rudra Verma, Senior Security Architect & Researcher · 2026-08-15

DNS tunnelling encodes data inside DNS query labels or TXT records to bypass network security controls. Tools like iodine, dnscat2, and DNSExfiltrator split payload bytes into Base32 or hex-encoded subdomains, sending hundreds of queries per minute to an attacker-controlled resolver.

This SOP covers two detection paths: query-volume and record-type analysis using DnsEvents in Microsoft Sentinel, and subdomain entropy scoring via KQL to separate legitimate CDN traffic from exfiltration tooling.

☰ Table of Contents

01 Background 02 Identification 03 Containment 04 Eradication 05 Escalation

🛠

01 — BACKGROUND

TECHNIQUE OVERVIEW

DNS Exfiltration & Tunnelling

T1048.003 / T1071.004

DNS tunnelling exploits the fact that DNS UDP port 53 is permitted outbound in virtually every corporate network. Attackers register a domain and run a malicious resolver; the implant on the victim encodes data as subdomain labels and the resolver decodes them. TXT and NULL record types carry more payload per packet than A queries, making them the preferred channels for interactive C2.

Field	Value
MITRE Technique	T1048.003 — Exfiltration Over Alternative Protocol: DNS
Sub-technique	T1071.004 — Application Layer Protocol: DNS
Log Sources	DnsEvents (Sentinel DNS connector), ASimNetworkSession, DeviceNetworkEvents
Key Indicators	TXT/NULL queries, subdomain label >60 chars, >100 queries/min to single domain, NXDOMAIN rate >30%
Common Tools	iodine, dnscat2, DNSExfiltrator, dns2tcp, Cobalt Strike DNS beacon
Detection Priority	HIGH — DNS bypasses most proxy and DLP controls

DNS tunnelling traffic looks identical to legitimate CDN traffic in volume alone. Always combine volume checks with record-type and label-entropy analysis before declaring a true positive.

🔍

02 — IDENTIFICATION

2 INDICATORS

▶ Investigation Workflow

High-Volume DNS Query Spike

T1048.003

WHY CHECK

DNS tunnelling tools issue hundreds of queries per minute to encode outbound data — a rate 10-50x above normal host baselines and immediately distinguishable from legitimate browsing patterns.

📍 Portal Navigation — Microsoft Sentinel

portal.azure.com› Microsoft Sentinel› Logs

1Open Sentinel workspace → click Logs in the left blade.
2Verify DnsEvents table is populated — if empty, check Data Connectors → DNS connector status.
3Paste the KQL below; set time range to Last 1 hour.
4Review QueryCount per ClientIP per domain — values above 100 per 5-min bucket are suspicious.
5Cross-reference flagged ClientIP with asset inventory to identify the host and its owner.

Field / Value	Meaning	Action
QueryCount > 100	Abnormal DNS query rate per 5-min window — baseline is typically 2-10 for normal browsing	ESCALATE
QueryType = TXT	TXT records carry arbitrary data — rarely issued by legitimate client software	INVESTIGATE
QueryType = NULL	NULL DNS records have no legitimate use in client-to-server communication	ESCALATE
ResultCode = 3 >30%	High NXDOMAIN rate indicates namespace probing — classic tunnel enumeration pattern	INVESTIGATE

DETECTS: Clients sending abnormally high DNS query volumes per 5-minute window — the primary volumetric signature of DNS tunnelling tools like iodine and dnscat2.

KQL — Microsoft Sentinel (DnsEvents)

DnsEvents | where TimeGenerated > ago(1h) | where QueryType in ("TXT", "NULL", "MX") or strlen(Name) > 60 | summarize QueryCount = count(), UniqueDomains = dcount(Name), SuspiciousTypes = countif(QueryType in ("TXT","NULL")), NXDOMAINs = countif(ResultCode == 3) by ClientIP, bin(TimeGenerated, 5m) | where QueryCount > 50 or SuspiciousTypes > 5 | extend NXRatio = round(toreal(NXDOMAINs) / QueryCount, 2) | order by QueryCount desc

DETECTS: Same DNS exfiltration volumetric pattern in Splunk — high query rate with TXT/NULL record types or failed lookups.

SPL — Splunk

index=* sourcetype=dns (query_type="TXT" OR query_type="NULL" OR len(query)>60) | bucket _time span=5m | stats count as query_count, dc(query) as unique_domains, count(eval(query_type IN ("TXT","NULL"))) as suspicious_types, count(eval(rcode="3")) as nxdomains by src_ip _time | eval nx_ratio=round(nxdomains/query_count, 2) | where query_count > 50 OR suspicious_types > 5 | sort -query_count

DnsEvents only populates if the DNS Connector is configured in Sentinel. If the table is empty, check Data Connectors → DNS and verify the OMS agent is installed on DNS servers.

High-Entropy Subdomain Label Analysis

T1071.004

WHY CHECK

DNS tunnelling tools encode binary data as Base32 or hex strings in subdomain labels — producing random-looking names with high entropy that contrast sharply with human-readable CDN or brand subdomains.

📍 Portal Navigation — Defender XDR Advanced Hunting

security.microsoft.com› Hunting› Advanced Hunting

1Navigate to security.microsoft.com → Hunting → Advanced Hunting.
2Paste the KQL below using the DeviceNetworkEvents table.
3Review RemoteUrl values — labels longer than 40 characters consisting of hex or Base32 chars are high-confidence tunnelling.
4Note the InitiatingProcessFileName — this identifies the process (implant) making the DNS queries.
5Pivot on DeviceName in Device Inventory to confirm host ownership and check for lateral movement indicators.

DETECTS: DNS queries with subdomain labels exceeding 40 characters — the encoding overhead of iodine (Base32) and dnscat2 (hex) makes long labels an unavoidable structural fingerprint.

KQL — Defender XDR Advanced Hunting

DeviceNetworkEvents | where Timestamp > ago(1h) | where RemotePort == 53 | extend subdomain = tostring(split(RemoteUrl, ".")[0]) | where strlen(subdomain) > 40 or subdomain matches regex @'^[a-z2-7]{20,} | summarize QueryCount = count(), SampleSubdomains = make_set(subdomain, 5), RemoteDomains = dcount(RemoteUrl) by DeviceName, InitiatingProcessFileName, bin(Timestamp, 10m) | where QueryCount > 20 | order by QueryCount desc

DETECTS: Long subdomain labels in Splunk stream-based DNS log — identifies Base32/hex-encoded tunnel traffic by label length threshold.

SPL — Splunk

index=* sourcetype=stream:dns | eval subdomain=mvindex(split(query,"."),0) | where len(subdomain) > 40 OR match(subdomain,"^[a-z2-7]{20,}$") | stats count as tunnel_queries, values(subdomain) as sample_labels, dc(query) as unique_domains by src_ip host | where tunnel_queries > 20 | sort -tunnel_queries

Run NXDOMAIN ratio analysis in parallel: a tunnel client probing the namespace will generate bursts of NXDOMAIN before establishing the channel. NXDOMAIN rate >30% from the same source raises confidence to HIGH even without volume threshold breach.

🚫

03 — CONTAINMENT

IMMEDIATE ACTION

Verdict & Escalation Decision

DECISION GATE

▶ Triage Verdict — Select One

CONFIRMED Volume >100/min AND TXT/NULL records OR label >60 chars → Block domain at DNS resolver, isolate host, escalate to L2 immediately

PARTIAL Suspicious record types OR long labels without volume breach → Enable enhanced DNS logging, continue entropy analysis, hold for 30 min

FALSE POSITIVE Normal volume, standard record types, no encoding pattern → Document CDN or software source, whitelist domain, close ticket

Do NOT block the domain before capturing DnsEvents query results for export. Forensic evidence is lost once the attacker rotates their C2 domain post-block.

Block Tunnel Domain & Isolate Host

CONTAINMENT

📍 Portal Navigation — Defender for Endpoint Indicators

security.microsoft.com› Settings› Endpoints› Indicators → Domains/URLs

1Go to Settings → Endpoints → Indicators → Domains/URLs → click Add indicator.
2Enter the tunnel domain (e.g. evil.com) and wildcard (*.evil.com). Set action to Block and remediate.
3Set severity to High, category to C2, and save.
4Isolate the affected host: Device Inventory → [hostname] → Isolate device.
5Notify L2 and open a P1 ticket — include DnsEvents export, host name, process name, and first-seen timestamp.

🗑

04 — ERADICATION

CLEANUP

Remove Implant & Restore DNS Config

ERADICATION

1Run a full Defender antivirus scan on the isolated host via Device Inventory → Run antivirus scan.
2Review InitiatingProcessFileName from the KQL results — locate and quarantine the binary responsible for DNS tunnelling queries.
3Check scheduled tasks (schtasks /query) and registry run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run) for persistence.
4Flush DNS cache on the host: ipconfig /flushdns — removes cached tunnel domain resolutions.
5Add the tunnel domain to Defender SmartScreen blocklist and Defender for Cloud Apps custom indicators.
6Confirm DnsEvents are flowing normally from the host within 5 minutes of re-enabling network access.

Eradication Complete When

No DnsEvents from affected host to tunnel domain in past 30 minutes
Defender AV scan completed — no active threats detected
Responsible process removed or quarantined
Persistence mechanisms cleared (scheduled tasks, registry run keys)
DNS block indicator active in Defender for Endpoint Indicators

📢

05 — ESCALATION

ESCALATION PATHS

ES1

Escalation Matrix

ESCALATION

Condition	Severity	Action	Notify
Confirmed tunnel, data volume unknown	SEV2	Isolate host, block domain, open IR ticket	SOC Lead → IR Team
Confirmed tunnel, exfil volume >1 GB	SEV1	Full IR, preserve PCAP evidence, legal notification	SOC Lead → CISO → Legal
C2 beaconing via DNS confirmed	SEV1	Network isolation, threat hunt lateral movement	SOC Lead → CISO
Suspicious patterns, no confirmation	SEV3	Enhanced monitoring, 4-hour re-check	SOC Lead (async)
False positive identified	INFO	Whitelist domain, close ticket, tune detection rule	None

If DNS tunnelling is confirmed on a domain controller, domain admin workstation, or CI/CD server — escalate directly to SEV1 regardless of observed data volume. Privileged machine compromise has unlimited blast radius.

Stay Threat-Ready

Follow CyberHawk Threat Intel for daily SOC analyst playbooks, detection engineering guides, and threat intelligence.

📺 YouTube 🎤 TikTok 🐦 X / Twitter 📡 Telegram

All SOPs Blog Web App (Free)

They can't exploit you if you are the Exploit.