Response playbooks, investigation guides, and Atomic Red Team tests are Pro-only. Upgrade to unlock the full detection package for THREAT-Recon-SubdomainBruteforceNXDOMAINStorm.

Upgrade to Pro
THREAT-Recon-SubdomainBruteforceNXDOMAINStorm Splunk · SPL

Detect Subdomain Bruteforce Causing NXDOMAIN Storm in Splunk

Before selecting a phishing pretext, staging infrastructure, or an external-facing service to target, adversaries frequently brute-force an organization's DNS namespace with a wordlist of common subdomain labels (vpn, mail, sso, dev, staging, api, remote, citrix, owa, etc.) to enumerate hosts that are not otherwise advertised. Tools such as dnsx, massdns, puredns, gobuster (dns mode), dnsrecon, and fierce resolve tens of thousands of candidate labels per minute against the target's authoritative or recursive DNS servers. Because most guessed labels do not correspond to a real record, this activity produces a highly distinctive footprint at the DNS server: a single source issuing an extremely high volume of queries against the organization's domain(s) within a short window, the overwhelming majority of which return NXDOMAIN, with very little repetition between query names (each guess is unique, unlike a caching resolver replaying the same handful of hostnames). This is distinct from the broader DNS/passive-DNS reconnaissance techniques already covered on the parent T1596.001 page (which include zone-transfer attempts and tool-execution detection) in that it isolates the specific volumetric NXDOMAIN-ratio signature that a bruteforce sweep leaves on the DNS server itself, catching enumeration even when the querying tool cannot be observed on an endpoint (e.g., run from an external host, a compromised third-party network, or a VPS with no EDR visibility) and regardless of which specific tool was used to generate the wordlist traffic. Scattered Spider and other access brokers routinely run this style of sweep against a target's public domain ahead of helpdesk-vishing and SSO-phishing campaigns to build a list of live internal-sounding hostnames to reference for pretext and targeting.

MITRE ATT&CK

Tactic
Reconnaissance

SPL Detection Query

Splunk (SPL)
spl
index=dns sourcetype=stream:dns
| eval QueryType=upper(coalesce(query_type, qtype_name, ""))
| eval QueryName=coalesce(query, query_name, name, "")
| eval SourceIP=coalesce(src_ip, src, client_ip)
| eval ResponseCode=upper(coalesce(rcode_name, reply_code, ""))
| where QueryType IN ("A", "AAAA", "CNAME", "MX", "TXT", "SRV", "NS")
| bin _time span=15m
| stats count AS TotalQueries,
    dc(QueryName) AS UniqueSubdomains,
    count(eval(ResponseCode="NXDOMAIN")) AS NxDomainCount,
    values(QueryType) AS QueryTypes
  BY _time, SourceIP
| eval NxDomainRatio=round(NxDomainCount/TotalQueries, 2)
| eval UniqueLabelRatio=round(UniqueSubdomains/TotalQueries, 2)
| where TotalQueries >= 200 AND NxDomainRatio >= 0.85 AND UniqueLabelRatio >= 0.90
| eval ThreatType="SubdomainBruteforce_NXDOMAINStorm"
| eval Severity=if(TotalQueries >= 2000, "HIGH", "MEDIUM")
| table _time, SourceIP, TotalQueries, UniqueSubdomains, NxDomainRatio, UniqueLabelRatio, QueryTypes, Severity
| sort - TotalQueries
medium severity medium confidence

SPL detection against Splunk Stream's stream:dns sourcetype (or an equivalent DNS query log) applying the same NXDOMAIN-storm fingerprint as the KQL query: 200+ queries from one source IP within a 15-minute bucket, an NXDOMAIN ratio of 85%+, and a unique-query-name ratio of 90%+. Field coalescing handles both Splunk Stream and Zeek/Bro-style field naming.

Data Sources

Splunk Stream (stream:dns)Zeek/Bro DNS log (dns.log)

Required Sourcetypes

stream:dns

False Positives & Tuning

  • Scheduled attack-surface management scans against the organization's own domains
  • Authorized red team/pentest subdomain enumeration
  • Misconfigured internal clients retrying stale or typo'd hostnames at volume

Other platforms for THREAT-Recon-SubdomainBruteforceNXDOMAINStorm


Testing Methodology

Validate this detection against 3 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.

  1. Test 1Subdomain Bruteforce Simulation via dnsx

    Expected signal: DNS server query logs record several hundred queries within a short window from the test source IP, with the large majority returning NXDOMAIN and each query name unique (near-1:1 unique-name-to-query ratio).

  2. Test 2High-Speed Bruteforce Simulation via massdns

    Expected signal: DNS server logs show a sharp spike in query volume from the test source IP within seconds to minutes, with the overwhelming majority of responses being NXDOMAIN.

  3. Test 3Low-and-Slow Throttled Enumeration Simulation

    Expected signal: DNS server logs record roughly 80 queries spread over about 40 minutes from the test source IP, nearly all returning NXDOMAIN, each with a unique query name.

Unlock playbooks & atomic tests with Pro

Get the full detection package for THREAT-Recon-SubdomainBruteforceNXDOMAINStorm — response playbook and atomic red team tests, plus investigation guidance and hunting queries.

df00tech Pro — £29/user/month

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections