Detect DNS/Passive DNS in Google Chronicle
Adversaries may search DNS data for information about victims that can be used during targeting. DNS information may include registered name servers, records outlining addressing for subdomains, mail servers, and other hosts. Adversaries may directly query nameservers for a target organization, search centralized repositories of logged DNS query responses (passive DNS services such as CIRCL Passive DNS or SecurityTrails), or seek DNS misconfigurations and zone transfer vulnerabilities that reveal internal network structure. This reconnaissance phase generates no footprint in the victim's environment unless the adversary actively queries the organization's own authoritative DNS servers — making detection primarily possible through DNS server audit logs, high-volume query pattern analysis, and endpoint-based detection of DNS enumeration tools. Information gathered supports subsequent techniques including infrastructure acquisition, phishing campaigns, and external service exploitation.
MITRE ATT&CK
- Tactic
- Reconnaissance
- Technique
- T1596 Search Open Technical Databases
- Sub-technique
- T1596.001 DNS/Passive DNS
- Canonical reference
- https://attack.mitre.org/techniques/T1596/001/
YARA-L Detection Query
rule t1596_001_dns_passive_dns {
meta:
author = "df00tech"
description = "Detects DNS/Passive DNS (T1596.001)"
mitre_attack_tactic = "TA0043"
mitre_attack_technique = "T1596.001"
confidence = "medium"
severity = "medium"
events:
$e.metadata.event_type = "PROCESS_LAUNCH"
$e.target.process.command_line != ""
condition:
$e
}Google Chronicle YARA-L 2.0 detection rule for DNS/Passive DNS (T1596.001). Uses Unified Data Model (UDM) event field mappings to detect the same behavioral patterns as the KQL rule, with Chronicle's temporal matching and entity correlation capabilities.
Data Sources
Required Tables
False Positives & Tuning
- Authorized DNS zone transfers between primary and secondary nameservers (AXFR is a legitimate replication mechanism — query from known secondary NS IPs should be allowlisted)
- Internal DNS monitoring and auditing tools (e.g., Infoblox DDI health checks, SolarWinds IPAM, Microsoft DNS Manager) that perform bulk DNS queries for zone inventory
- Security posture assessments and penetration tests scheduled by the organization — these will generate exactly the patterns this rule detects
- Subdomain enumeration by legitimate SEO crawlers, web application security scanners (Qualys, Tenable), or cloud provider health probes querying public DNS records
Other platforms for T1596.001
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 1DNS Zone Transfer Attempt via dig (AXFR)
Expected signal: Linux auditd: execve syscall for /usr/bin/dig with args 'AXFR zonetransfer.me @nsztm1.digi.ninja'. Network: TCP connection on port 53 to nsztm1.digi.ninja (zone transfers use TCP). Sysmon for Linux Event ID 3: network connection from dig process to port 53. If running on Windows, Sysmon Event ID 1 captures the process creation and Event ID 3 captures the TCP/53 connection.
- Test 2Subdomain Enumeration via dnsrecon
Expected signal: Sysmon for Linux / auditd: process creation for dnsrecon with target domain argument. Network: multiple UDP/TCP port 53 packets to DNS resolvers, including NS, SOA, MX, A, AAAA, TXT query types for example.com and its subdomains. stream:dns logs will show high-volume queries for subdomains of example.com from the test host IP within a short time window.
- Test 3DNS Zone Transfer via nslookup (Windows)
Expected signal: Sysmon Event ID 1: Process Create with Image='C:\Windows\System32\nslookup.exe', CommandLine containing '-type=AXFR'. Sysmon Event ID 3: TCP network connection on port 53 to nsztm1.digi.ninja. Sysmon Event ID 22: DNS query event for zonetransfer.me. Security Event ID 4688 (if command line auditing is enabled) with the full command line.
- Test 4Passive DNS Reconnaissance via subfinder
Expected signal: Sysmon for Linux / auditd: process creation for subfinder binary with '-d example.com' argument. Network: HTTPS connections to passive DNS API endpoints (SecurityTrails, VirusTotal, Censys APIs on port 443) — these will NOT appear as DNS queries against the target's nameservers, which is why passive DNS recon is so difficult to detect from the victim side. File creation event for /tmp/subdomains.txt containing enumerated subdomains.
References (11)
- https://attack.mitre.org/techniques/T1596/001/
- https://www.circl.lu/services/passive-dns/
- https://dnsdumpster.com/
- https://learn.microsoft.com/en-us/azure/sentinel/connect-dns
- https://learn.microsoft.com/en-us/azure/sentinel/dns-normalization-schema
- https://github.com/darkoperator/dnsrecon
- https://github.com/projectdiscovery/subfinder
- https://github.com/owasp-amass/amass
- https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/disable-dns-zone-transfer
- https://www.sans.org/blog/dns-zone-transfers-a-common-but-preventable-misconfiguration/
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1596.001/T1596.001.md
Unlock Pro Content
Get the full detection package for T1596.001 including response playbook, investigation guide, and atomic red team tests.