DNS Server
Adversaries may set up their own Domain Name System (DNS) servers that can be used during targeting. During post-compromise activity, adversaries may utilize DNS traffic for various tasks, including for Command and Control. Instead of hijacking existing DNS servers, adversaries may opt to configure and run their own DNS servers in support of operations. By running their own DNS servers, adversaries can have more control over how they administer server-side DNS C2 traffic. With control over a DNS server, adversaries can configure DNS applications to provide conditional responses to malware and, generally, have more flexibility in the structure of the DNS-based C2 channel. Real-world examples include Sea Turtle building adversary-in-the-middle DNS servers to capture credentials, Axiom acquiring dynamic DNS services for targeting operations, and HEXANE setting up custom DNS servers to send commands to compromised hosts via TXT records.
// Multi-signal detection for adversary-controlled DNS server usage
// CUSTOMIZE: Replace with your organization's authoritative internal DNS server IPs
let AuthorizedDNSServers = dynamic(["10.0.0.1", "10.0.0.2"]);
// Known legitimate public DNS resolvers — extend as needed for your environment
let KnownPublicDNS = dynamic(["8.8.8.8", "8.8.4.4", "1.1.1.1", "1.0.0.1", "9.9.9.9", "149.112.112.112", "208.67.222.222", "208.67.220.220", "64.6.64.6", "64.6.65.6", "185.228.168.9", "185.228.169.9"]);
// Signal 1: Endpoints making DNS queries to non-authorized external resolvers
// This indicates malware hardcoded to use adversary-controlled DNS infrastructure
let UnauthorizedResolvers =
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemotePort == 53
| where not(RemoteIP has_any (AuthorizedDNSServers))
| where not(RemoteIP has_any (KnownPublicDNS))
| where not(
RemoteIP startswith "10."
or RemoteIP startswith "192.168."
or RemoteIP startswith "127."
or (RemoteIP startswith "172." and toint(split(RemoteIP, ".")[1]) between (16..31))
)
| extend DetectionType = "Unauthorized_External_DNS_Resolver"
| project Timestamp, DeviceName, AccountName, LocalIP, RemoteIP, RemotePort,
InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionType;
// Signal 2: High-volume DNS query rate from a single process — DNS tunneling indicator
let HighVolumeDNS =
DeviceNetworkEvents
| where Timestamp > ago(1h)
| where RemotePort == 53
| summarize QueryCount = count(), UniqueServers = dcount(RemoteIP)
by DeviceName, InitiatingProcessFileName, bin(Timestamp, 5m)
| where QueryCount > 200
| extend DetectionType = "High_Volume_DNS_Tunneling_Indicator"
| project Timestamp, DeviceName, InitiatingProcessFileName, QueryCount, UniqueServers, DetectionType;
// Signal 3: Registry changes pointing DNS resolver at unauthorized external server
let DNSConfigChange =
DeviceRegistryEvents
| where Timestamp > ago(24h)
| where RegistryKey has "Tcpip\\Parameters"
| where RegistryValueName in ("NameServer", "DhcpNameServer", "StaticDnsAddress")
| where not(RegistryValueData has_any (AuthorizedDNSServers))
| where not(
RegistryValueData startswith "10."
or RegistryValueData startswith "192.168."
or RegistryValueData == ""
or RegistryValueData has_any (KnownPublicDNS)
)
| extend DetectionType = "DNS_Server_Configuration_Modified"
| project Timestamp, DeviceName, AccountName, RegistryKey, RegistryValueName,
RegistryValueData, InitiatingProcessFileName, DetectionType;
union UnauthorizedResolvers, HighVolumeDNS, DNSConfigChange
| sort by Timestamp desc Data Sources
Required Tables
False Positives
- VPN split-tunneling configurations where DNS queries are sent to remote-office DNS servers not yet in the authorized list — validate by correlating with VPN connection events
- Developer workstations running local DNS resolvers (dnsmasq, CoreDNS) for container or Kubernetes development — exclude by adding 127.0.0.53 and common container bridge IPs
- Endpoints connecting to guest Wi-Fi or non-corporate hotspots where DHCP assigns a third-party DNS server — correlate with network adapter SSID or location data
- Security tools and vulnerability scanners performing DNS resolution against external resolvers for testing or enumeration purposes — allowlist by initiating process name and account
- Cloud-managed endpoints (MDM, Intune) that may temporarily receive DNS from cloud provider DHCP — add cloud provider DNS IPs (168.63.129.16 for Azure) to the authorized list
References (8)
- https://attack.mitre.org/techniques/T1583/002/
- https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/
- https://blog.talosintelligence.com/sea-turtle/
- https://www.zscaler.com/blogs/security-research/lyceum-net-dns-backdoor
- https://www.sans.org/reading-room/whitepapers/dns/detecting-dns-tunneling-34152
- https://github.com/yarrick/iodine
- https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
- https://www.netresec.com/?page=Blog&month=2023-02&post=Detecting-DNS-Tunneling-with-Zeek
Unlock Pro Content
Get the full detection package for T1583.002 including response playbook, investigation guide, and atomic red team tests.