DNS (MITRE ATT&CK T1071.004) is a Command and Control technique. MITRE lists ESXi, Linux, macOS, network devices and Windows as platforms.
Adversaries use the Domain Name System to blend in with existing traffic. Commands to the remote system, and often the results, are embedded in DNS traffic between client and server.
How attackers use it
DNS does an administrative job, so it is common in every environment. MITRE adds that DNS traffic may be allowed even before network authentication is complete. DNS packets have many fields and headers where data can be hidden. This is often called DNS tunneling.
MITRE also describes DNS beaconing, where commands are sent to remote systems through DNS queries. A DNS beacon is created by tunneling DNS traffic, and the commands can sit in different record types, for example TXT or A records. MITRE notes that such beacons can be hard to spot because they talk to infected devices rarely, so the malicious queries hide among normal DNS traffic.
How to detect it
MITRE's detection strategy has five analytics:
- Windows: high-frequency or anomalous DNS queries from non-browser, non-system processes such as PowerShell, rundll32 or python.exe.
- Linux: daemons or scripts that send queries with long or frequent subdomains, pointing to tunneling tools such as iodine or dnscat2, or dig run from cron jobs or reverse shells.
- macOS: scripting environments such as AppleScript, osascript or curl, or non-native tools, making queries with encoded subdomains.
- Network devices: clients with high query volume, long subdomain lengths, encoded payload patterns, or queries to known malicious infrastructure.
- ESXi: unusual outbound DNS from ESXi hosts, often from shell scripts, custom daemons or malicious VIBs talking to external DNS outside the management plane.
Data to collect:
- DNS query logs from your resolvers, with client, query name, record type and response size.
- Endpoint DNS telemetry that names the process. On Windows, Sysmon Event ID 22 records DNS queries with the process image.
- Egress flow data, to find hosts that talk to external DNS servers directly.
Signals worth building rules around:
- Many unique subdomains under one parent domain.
- Unusually long query names.
- Heavy use of TXT or other less common record types by a single client.
- Low and steady query counts to a rare domain, which fit a quiet beacon.
- Servers that query DNS names they never queried before.
Because beacons are infrequent, look across days, not minutes.
How to reduce the risk
MITRE lists two mitigations:
- Filter network traffic. Consider filtering DNS requests to unknown, untrusted or known bad domains. Resolving DNS through on-premises or proxy servers may also disrupt adversary attempts to hide data in DNS packets.
- Network intrusion prevention. Use signature-based systems to identify traffic from specific adversary malware.
In plain steps: force all clients to use your resolvers and block outbound DNS to everywhere else, log every query centrally, and use a protective resolver that blocks newly seen or known malicious domains.
Check your own environment
# Linux or macOS: which resolvers does this host use?
cat /etc/resolv.conf
# Linux: any established connections to external port 53? (read only)
sudo ss -tunp | grep ':53 '
# Windows PowerShell: DNS servers configured per interface, and the local DNS cache (read only)
Get-DnsClientServerAddress
Get-DnsClientCache | Select-Object -First 30 Entry, Type
Then check:
- Can a workstation or server reach an outside DNS server directly, or only your resolvers?
- Do you keep DNS logs long enough to see a slow beacon?
- Do your logs show which process made each query, at least on endpoints?
Quick check
Why are DNS beacons hard to detect?
They communicate with infected devices infrequently, so the malicious queries are hidden among normal DNS traffic.
Which record types does MITRE mention for embedded commands?
TXT and A records, as examples.
