Detect DNS Server in Microsoft Sentinel
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.
MITRE ATT&CK
- Tactic
- Resource Development
- Technique
- T1583 Acquire Infrastructure
- Sub-technique
- T1583.002 DNS Server
- Canonical reference
- https://attack.mitre.org/techniques/T1583/002/
KQL Detection Query
// 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 descDetects adversary-controlled DNS server usage through three signals: (1) endpoints making DNS queries directly to non-authorized external IP addresses on port 53, bypassing corporate DNS infrastructure — a strong indicator of malware hardcoded to communicate with adversary DNS servers; (2) high-volume DNS query rates from individual processes in short windows, consistent with DNS tunneling C2 channels routing traffic through adversary-controlled resolvers; (3) Windows registry modifications to DNS server configuration settings that point to unauthorized external resolvers, enabling persistent C2 redirection. Requires populating AuthorizedDNSServers with your organization's internal resolver IPs for Signal 1 and Signal 3 to be actionable.
Data Sources
Required Tables
False Positives & Tuning
- 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
Other platforms for T1583.002
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Configure Windows DNS Client to Use Custom External Resolver
Expected signal: Sysmon Event ID 13 (Registry Value Set): TargetObject containing 'SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\NameServer' or 'StaticDnsAddress' with new value '198.51.100.1'. Sysmon Event ID 1 (Process Create): Image=netsh.exe with CommandLine='interface ip set dns name=Ethernet static 198.51.100.1 primary'. Security Event ID 4688 (if command line auditing enabled). MDE DeviceRegistryEvents with RegistryValueName='NameServer' and RegistryValueData='198.51.100.1'.
- Test 2DNS TXT Record Query via nslookup (HEXANE-Style C2 Simulation)
Expected signal: Sysmon Event ID 22 (DNS Query): Image=nslookup.exe and Image=powershell.exe with QueryName entries for the queried domains. Sysmon Event ID 3 (Network Connection): connections to 8.8.8.8 on port 53 from nslookup.exe and powershell.exe. Security Event ID 4688: Process Create for nslookup.exe. The second query (MNQXI2LPNZSGK3TFONZSA.example.com) will trigger high-entropy subdomain detection with FirstLabelLen=21.
- Test 3Set Up BIND9 Authoritative DNS Server on Linux
Expected signal: Linux audit log (auditd): execve syscalls for apt-get/yum, systemctl, named. Syslog (/var/log/syslog or /var/log/messages): BIND9 startup messages from named daemon including 'starting BIND' and 'listening on IPv4 interface'. Process creation events: named process spawned by systemd with parent systemd. Network listener: netstat/ss showing UDP/TCP port 53 bound on 0.0.0.0 by named process. File creation events for /etc/bind/named.conf.options.
- Test 4DNS Tunneling Pattern Simulation with Encoded Subdomains
Expected signal: 50 rapid DNS query events (Sysmon Event ID 22 on Windows equivalent, or DNS debug log entries on Linux). Query names follow pattern: 24-char alphanumeric label + '.c2.example.com' (total length ~40 chars). All queries occur within a 5-10 second window. Process creating queries: dig (or nslookup equivalent). Network events: 50 UDP packets to 127.0.0.1:53 in rapid succession. On Windows, if run via WSL: DeviceNetworkEvents showing high-frequency port 53 connections from the WSL process.
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.