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 ProDetect Subdomain Bruteforce Causing NXDOMAIN Storm in Elastic Security
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
Elastic Detection Query
sequence by source.ip with maxspan=15m
[dns where dns.response_code == "NXDOMAIN"] with runs=200EQL detection for subdomain bruteforce NXDOMAIN storms: 200 or more DNS responses with response code NXDOMAIN from the same source IP within a 15-minute window. Pair with the KQL/SPL unique-label-ratio check for full fidelity, since EQL sequences alone cannot compute the unique-name ratio.
Data Sources
Required Tables
False Positives & Tuning
- Attack-surface management scans against the organization's own domains
- Misconfigured internal clients retrying stale 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.
- 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).
- 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.
- 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