Skip to content
PwnDeck logoPwnDeck

Subdomain Enumeration: Going Wide Before You Go Deep

Why the first hour of a recon engagement should be subdomain enumeration, and how to do it without firing a thousand DNS queries at the target.

By Javier HernándezPentester @ Accenture | OSCP (in progress)3 min read

The first hour of any external recon engagement should be subdomain enumeration. Not port scans, not vuln scans — enumeration. The reason is simple: the IP you were given in the scope document covers maybe 20 % of the attack surface. The other 80 % is on adjacent IPs, CDN-fronted hostnames, and forgotten staging boxes that share nothing with the primary domain except a DNS record. If you skip wide enumeration and go straight to deep scanning of the main host, you will produce a thorough report on the least interesting part of the surface.

Passive first, always

The cardinal rule of subdomain enumeration is passive sources before active probing. Passive means you query third parties (certificate transparency logs, search engines, DNS aggregators) instead of hitting the target's DNS server directly. The target sees nothing, and you get a more complete answer because passive sources have years of historical records.

The single best passive source is Certificate Transparency. Every TLS cert issued by a publicly trusted CA since 2018 is logged, and the subject and SAN fields are fully searchable. A query for %.target.com against crt.sh or any other CT mirror returns every hostname the target has ever requested a cert for, including the staging environments they forgot, the test boxes from 2019, and the internal admin panels somebody accidentally exposed.

Advertisement

After CT, the next-best sources are passive DNS (SecurityTrails, VirusTotal), search engines (Google, Bing dorks for site:target.com), and the Wayback Machine. Each of them has hostnames the others miss. Run all of them. Take the union. De-duplicate.

When to use brute force

Active brute-force enumeration — generating candidate hostnames and querying DNS for each — is not obsolete, but its role has shrunk. CT gets you the legitimate hostnames; brute force gets you the wildcards and the hostnames that were created but never given a cert (often internal-only services accidentally exposed).

When you do brute-force, do it intelligently:

  • Use a wordlist tuned to the target's vocabulary (their product names, region codes, environment prefixes like dev-, staging-, qa-).
  • Resolve through your own resolver pool, not the target's authoritative server, so you don't fingerprint yourself.
  • Detect wildcard DNS first (random-string resolution that always returns the same IP) so you don't mistake every miss for a hit.
  • Cap the rate. There is no scenario where a 10,000 QPS brute-force gets you more than 100 QPS — the long tail of authoritative servers will rate-limit you regardless.

What to do with the list

A 400-hostname list is useless without prioritisation. The order of operations I use:

  1. Resolve every hostname to its current IP. Group by IP block. Hostnames sharing an IP often share an admin and a patch cadence.
  2. Identify which ones are alive on 80/443. Drop the dead ones.
  3. Probe each live host for its tech stack — server header, framework signature, login portal indicators. Hosts that look "different" from the rest of the estate (different stack, different login page) are usually the interesting ones.
  4. For the interesting ones, run the deeper scans.

Step 3 is where you find the 2014-vintage WordPress on blog.target.com that nobody has touched since the comms team set it up, or the Jenkins instance on ci-old.target.com with anonymous read access enabled.

A two-tool workflow

For day-to-day recon, the workflow I use boils down to two passes. First, our subdomain finder pulls from CT and passive DNS in one go and gives you the union de-duplicated. Second, for each interesting hostname, our wayback URL miner extracts every URL the Wayback Machine has ever seen on that host — directory paths, query parameters, file extensions — which is where the JS files referencing forgotten API endpoints tend to hide.

The result is a map. Not a vuln list, not an exploit chain — just a map. But you cannot exploit what you haven't found, and you will not find it by running nmap against the IP in the SOW. Spend the first hour going wide. The depth will earn its keep on hour two.

Share this article:LinkedInX

Related articles