Overview

DNS reconnaissance (T1590.002) is the practice of harvesting DNS records — A, MX, TXT, SPF, CNAME, NS, and SOA — to map a target organisation's infrastructure before launching an attack. Adversaries use this information to identify mail servers, cloud providers, subdomains, and third-party SaaS relationships without ever touching the victim's network directly.

Because most DNS enumeration happens using public infrastructure and passive data sources, it leaves little trace inside a victim's environment — making it one of the hardest reconnaissance phases to detect. Every security team needs visibility into this technique because the intelligence gathered directly enables phishing, credential attacks against exposed services, and infrastructure compromise.

Attacker Perspective

Before launching any active attack, adversaries systematically harvest DNS records to build a complete picture of the target's external attack surface.

• Zone Transfer Abuse: Attacker queries a misconfigured authoritative DNS server using dig AXFR @ns1.target.com target.com or nslookup -type=any -query=AXFR target.com ns1.target.com, potentially retrieving every DNS record in a single request.
• Automated Subdomain Enumeration: Tools like amass enum -d target.com, subfinder -d target.com, or dnsx -l wordlist.txt -d target.com brute-force thousands of subdomain permutations against public resolvers to discover hidden assets.
• Passive DNS and Open Database Mining: Adversaries query services like VirusTotal, SecurityTrails, Shodan, or DNSDumpster via their web UIs or APIs — curl "https://api.securitytrails.com/v1/domain/target.com/subdomains" — leaving no footprint on the victim's infrastructure whatsoever.
• MX and TXT Record Harvesting: Running dig MX target.com and dig TXT target.com reveals email providers (Office 365, Google Workspace), SPF configurations, DMARC posture, and third-party SaaS integrations that can be targeted for credential stuffing or phishing.

This technique is attractive because it is entirely low-risk — most DNS enumeration is indistinguishable from normal internet traffic, requires no special access, and can be conducted entirely from disposable infrastructure or through third-party data brokers.

Detection Strategy

Required Telemetry

• Windows DNS Server Debug Logging (Event ID 6004): Enable DNS Server operational logging via the Windows DNS Manager console or Group Policy. Navigate to DNS Server properties → Debug Logging tab, or enable the analytic/operational channels under Applications and Services Logs\Microsoft\Windows\DNS-Server. Event ID 6004 fires when a zone transfer request is received for a non-existent or non-authoritative zone. Event ID 6001 fires on successful zone transfers. Ensure logs are forwarded to your SIEM via Windows Event Forwarding (WEF) or a log agent.
• Windows DNS Server Audit Log (Event ID 770, 771): Enable DNS audit logging via PowerShell: Set-DnsServerDiagnostics -All $true or via GPO under Computer Configuration → Administrative Templates → Network → DNS Client. Event ID 770 captures zone transfer requests received; Event ID 771 captures zone transfer completions.
• Network-Level DNS Traffic Capture: Deploy network sensors (Zeek/Bro, Suricata, or a dedicated NDR platform) capable of parsing DNS wire traffic on UDP/TCP port 53. Zeek generates dns.log with fields including qtype_name, query, answers, id.orig_h, and id.resp_h. AXFR requests will appear as qtype_name = AXFR or qtype = 252.
• Linux/UNIX DNS Server Logs (BIND/named): Enable query logging in BIND by adding logging { channel query_log { file "/var/log/named/query.log"; severity dynamic; }; category queries { query_log; }; }; to named.conf. Restart named and forward logs via syslog or a log shipper. Zone transfer attempts appear as client: query: AXFR in the log stream.
• PowerShell Script Block Logging (Event ID 4104): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Captures PowerShell-based DNS enumeration scripts invoking Resolve-DnsName, nslookup, or DNS API calls.
• Process Creation Logging (Event ID 4688 or Sysmon Event ID 1): Enable Process Creation auditing via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. Enable command-line logging: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Sysmon Event ID 1 provides richer detail including hashes and parent process GUID.
• DNS Resolver Query Logs (Internal Recursive Resolvers): If using Windows DNS as a recursive resolver, enable debug logging to capture all outbound queries. If using a commercial DNS security platform (Cisco Umbrella, Infoblox, BlueCat), enable query logging and forward via syslog or API. These logs will reveal internal hosts performing bulk DNS enumeration.

Key Indicators

• Zone Transfer Requests (AXFR/IXFR): In Zeek dns.log, look for qtype_name = "AXFR" or qtype_name = "IXFR". In Windows DNS Event ID 6004, the event message contains the source IP and the zone name requested. Any AXFR query originating from an IP not listed in your authorised secondary DNS server list is suspicious.
• High-Volume DNS Query Rate from a Single Source: In network DNS logs, look for a single id.orig_h (source IP) generating more than 500 unique query values within a 60-second window, particularly with varied subdomain prefixes against the same apex domain — a pattern consistent with subdomain brute-forcing.
• Bulk MX/TXT/NS Record Harvesting: In Zeek dns.log, look for sequences of qtype_name values cycling through "MX", "TXT", "NS", "SOA", "CNAME" for the same domain from the same source IP within a short window — consistent with automated enumeration tools rather than normal application behaviour.
• DNS Enumeration Tool Execution (Process Creation): In Sysmon Event ID 1 or Windows Event ID 4688, look for Image containing nslookup.exe, dig.exe, or Resolve-DnsName with CommandLine containing flags like -type=AXFR, -q=AXFR, ls -d (nslookup zone list), or high-frequency invocations in a loop.
• PowerShell DNS Enumeration (Script Block Log): In Windows Event ID 4104, look for ScriptBlockText containing Resolve-DnsName combined with loops, array iteration, or pipe chains — particularly patterns like $subdomains | ForEach-Object { Resolve-DnsName "$_.$domain" }.
• AXFR Success on a Misconfigured Server: Windows DNS Event ID 6001 (zone transfer completed) paired with a source IP that is not an authorised secondary DNS server is a confirmed misconfiguration being actively exploited. In BIND logs, look for transfer of 'zone.name/IN' from IP: Transfer completed for unauthorised IPs.
• Unusual DNS Query Sizes in Network Traffic: Successful AXFR responses are very large (kilobytes to megabytes) compared to normal DNS responses. In Zeek dns.log, filter for proto = "tcp" (AXFR uses TCP) combined with large response sizes — a useful signal even if query type is obscured.

Detection Logic

Rule 1: Any DNS zone transfer request received by an internal DNS server from an unauthorised source
IF event_id = 6004 OR (dns_log.qtype_name = "AXFR" OR dns_log.qtype_name = "IXFR") AND source_ip NOT IN [authorised_secondary_dns_servers] THEN alert(severity=HIGH)

This catches the most dangerous scenario — a direct AXFR request against your authoritative DNS server. Expected volume is very low; any firing is high-fidelity and should be investigated. This directly maps to the community Sigma rule for Event ID 6004.

Rule 2: High-frequency unique subdomain queries from a single internal host within a short time window
IF count(DISTINCT dns_query) > 200 WHERE source_ip = same_host AND time_window = 60_seconds AND dns_query MATCHES regex("^[a-z0-9\-]+\.[a-z0-9\-]+\.[a-z]{2,}$") AND dns_qtype NOT IN ["PTR", "AAAA"] THEN alert(severity=MEDIUM)

This catches internal hosts running subdomain enumeration tools (amass, subfinder, dnsx) against external targets. Tune the threshold based on your environment's baseline; expected volume is low in most enterprise environments but may need adjustment in development or security testing environments.

Rule 3: DNS enumeration tool execution with zone transfer flags on an endpoint
IF process_name IN ["nslookup.exe", "dig.exe", "host.exe"] AND command_line MATCHES ("AXFR" OR "axfr" OR "ls -d" OR "-type=any") AND parent_process NOT IN ["approved_admin_tools.exe"] THEN alert(severity=HIGH)

This catches hands-on-keyboard or scripted AXFR enumeration from a compromised endpoint. Very low expected false positive volume; security team members running authorised scans should be excluded by approved parent process or user account.

Rule 4: Bulk DNS record type cycling (MX, TXT, NS, SOA) from a single source within 5 minutes
IF count(DISTINCT dns_qtype_name) >= 4 WHERE dns_qtype_name IN ["MX", "TXT", "NS", "SOA", "CNAME"] AND source_ip = same_host AND time_window = 300_seconds AND dns_query_apex_domain = same_domain THEN alert(severity=LOW)

This catches automated DNS footprinting tools cycling through record types for intelligence gathering. Expected to produce more noise than rules above; useful as a supporting signal rather than a standalone high-priority alert. Correlate with other indicators to increase confidence.

Tuning Guidance

• Authorised Secondary DNS Servers: Zone transfer alerts (Rules 1 and 3) will fire on your own secondary DNS servers performing legitimate zone replication. Build and maintain a static allowlist of secondary server IPs and exclude them via source_ip IN [secondary_dns_allowlist]. Review this list quarterly.
• Security Team Authorised Scanning: Your own red team, vulnerability management team, or DNS hygiene tools (e.g., Infoblox, Nessus) may perform DNS enumeration on a scheduled basis. Exclude known scanner IPs or service accounts: source_ip NOT IN [approved_scanner_ips] or user NOT IN [security_service_accounts]. Require these teams to notify the SOC before scanning.
• High-Query Development and Test Environments: CI/CD pipelines, automated integration tests, and microservice architectures may generate high DNS query volumes that trigger Rule 2. Exclude known DevOps subnet ranges or specific source IPs: source_ip NOT IN [cicd_pipeline_subnets] and tune the threshold upward for those sources.
• Mail Security and Spam Filtering Infrastructure: Mail gateways, spam filters, and email security appliances legitimately query MX, SPF (TXT), and DMARC (TXT) records at high volume for every inbound message. Exclude mail gateway IPs from Rule 4: source_ip NOT IN [mail_gateway_ips].
• DNS over HTTPS (DoH) Blind Spots: If endpoints use DoH (Chrome, Firefox defaults), your network DNS logs will not capture their queries. This is a detection gap, not a false positive — note it in your detection coverage documentation and consider enforcing internal DNS resolvers via GPO or proxy policy to maintain visibility.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Pull the raw event directly from the source log — retrieve Windows DNS Event ID 6004 from the DNS server's event log, or the raw Zeek dns.log entry — and confirm the source_ip, zone_name, and timestamp match what the SIEM alert reported. Cross-reference the event count to ensure this is not a SIEM parsing artifact.
2. Identify the source host and account: Resolve the source IP to a hostname using your CMDB or DHCP logs, and determine whether it is a workstation, server, or external IP. If internal, query Active Directory or your identity provider to identify the logged-on user at the time of the event and flag immediately if the account is privileged (Domain Admin, DNS Admin, service account).
3. Pull the full process and command-line chain: On the source host, query Sysmon Event ID 1 or Windows Event ID 4688 for process creation events within a ±5 minute window around the alert time. Look for nslookup.exe, dig.exe, powershell.exe, or scripting engines with DNS-related command-line arguments, and trace the parent process chain back to identify how the tool was invoked.
4. Check for network connections and files written to disk: Query Sysmon Event ID 3 (network connections) from the source host for DNS-related outbound connections on port 53 (UDP and TCP) and identify all destination IPs. Also check Sysmon Event ID 11 (file creation) for output files (e.g., .txt, .csv, .json) that may contain exfiltrated DNS data written by enumeration tools.
5. Assess scope — internal or external origin: If the source IP is external, query your firewall and DNS server logs to determine how the request reached your authoritative DNS server and whether a zone transfer succeeded (look for Event ID 6001 or BIND "Transfer completed" log entries). If the source is internal, determine whether the host itself has been compromised or whether a user deliberately ran enumeration tools.
6. Search for lateral movement from the source host: Query Windows Security Event ID 4624 (logon events) and Event ID 4648 (explicit credential use) originating from the source host within the 24 hours following the alert. Also check Sysmon Event ID 3 for connections to other internal hosts on ports 445 (SMB), 3389 (RDP), or 5985/5986 (WinRM) that could indicate the host was used as a pivot point after reconnaissance.
7. Escalation decision: Escalate to a confirmed incident if any of the following are true: the zone transfer succeeded (Event ID 6001 or BIND transfer completed from an unauthorised IP); the source host shows signs of compromise (unexpected parent processes, dropped files, lateral movement); or the querying user account is privileged and the activity was not authorised. Treat as a benign finding only if the source IP is a known authorised scanner, the user's manager confirms an authorised activity, and there is no evidence of data exfiltration or follow-on compromise.

Response Playbook

Containment

• If zone transfer succeeded from an external or unauthorised IP: Immediately reconfigure the DNS server to restrict zone transfers — on Windows DNS, open DNS Manager → Zone Properties → Zone Transfers tab → select "Only to the following servers" and specify authorised secondary IPs only. On BIND, add allow-transfer { trusted_secondaries; }; to the zone block in named.conf and reload: rndc reload. This closes the misconfiguration immediately.
• If the source is a compromised internal host: Isolate the host at the network layer using your EDR platform's network isolation feature (CrowdStrike "Network Containment", Defender for Endpoint "Isolate Device") or by placing its switch port into a quarantine VLAN. Leave the system powered on to preserve volatile memory and forensic artefacts.
• If a user account initiated the activity without authorisation: Disable the account in Active Directory immediately: Disable-ADAccount -Identity username. Invalidate active sessions by running Revoke-AzureADUserAllRefreshToken (for M365/Entra) or forcing a Kerberos ticket invalidation by resetting the account password and enabling the "User must change password at next logon" flag.
• Block identified external enumeration sources: Submit the source IPs to your perimeter firewall and DNS security platform (Umbrella, Infoblox) for immediate blocking. If external IPs queried your authoritative DNS via the internet, confirm your DNS server is not unnecessarily exposed — authoritative DNS for internal zones should not be publicly accessible.

Eradication

• Remediate the DNS misconfiguration permanently: Audit all DNS zones on all authoritative servers to confirm zone transfer restrictions are applied consistently. Use Get-DnsServerZone | Select-Object ZoneName, SecureSecondaries, SecondaryServers on Windows to enumerate current zone transfer settings across all zones and confirm none are set to SecureSecondaries = NoSecurity.
• Remove any enumeration tools dropped on the compromised host: Search for and delete identified tool binaries (amass, subfinder, dnsx, or custom scripts) found via Sysmon Event ID 11 or EDR file creation telemetry. Use your EDR to run a hash-based search across your fleet to identify the same tools on other endpoints.
• Reset credentials for the involved account and any accounts it accessed: Reset the password for the user or service account that ran the enumeration. If the account accessed other systems (identified in lateral movement investigation), reset credentials on those systems as well. If API keys or DNS provider credentials were exposed in enumeration output or on the compromised host, rotate them immediately with your DNS registrar or provider.
• Check for persistence mechanisms on the compromised host: Query Sysmon Event ID 13 (registry value set) for modifications to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and scheduled task creation (Event ID 4698). Remove any entries not present in your baseline configuration.
• Validate no additional backdoors exist on lateral movement targets: For any hosts the compromised system connected to, run an EDR-based sweep for unsigned executables, new local accounts (Event ID 4720), and unusual scheduled tasks or services created in the timeframe of the incident.

Recovery

• Restore or reimage the compromised host: If confidence in the host's integrity is low (unknown dwell time, evidence of multiple tools, or signs of persistence), reimage from a known-good baseline rather than attempting to clean in place. Only reconnect the host to the production network after EDR confirms a clean state and all persistence mechanisms have been removed.
• Re-enable the user account with enhanced monitoring: Before re-enabling the account, confirm with the user's manager that the activity was unauthorised and brief the user on acceptable use policy. Re-enable via Enable-ADAccount -Identity username and configure a conditional access policy or enhanced logging profile for the account for a minimum of 72 hours post-recovery.
• Monitor the affected host and user for 72 hours: Create a temporary high-sensitivity watchlist in your SIEM containing the host name, user account, and any identified attacker IPs or domains. Alert on any DNS queries, process creation, or network connections from these entities that were not present before the incident.
• Conduct a post-incident DNS security review: Run a full audit of all public-facing DNS records to identify any sensitive information exposed (internal hostnames, management interfaces, deprecated services). Consider implementing DNS Security Extensions (DNSSEC) if not already deployed, and review whether any third-party SaaS relationships revealed in MX/TXT records are still current and secured.
• Document and update detections: Write a full incident timeline capturing the initial alert, investigation findings, containment actions, and resolution. Update your SIEM detection rules with any new IOCs (source IPs, tool names, command patterns) discovered during the investigation, and lower the alert threshold if this technique was previously under-monitored in your environment.