Post cover image

July 6, 2026

Your Subdomain Enum Is Only Finding Half the Attack Surface

Most hunters stop at 60% coverage without realizing it.

By Abhishek meena

3 min read

I used to think I had good recon habits. Subfinder, pipe it to httpx, sort unique, move on to fuzzing. Fast, clean, satisfying. Then I compared my subdomain list against a target's own internal Slack leak from an unrelated disclosure, and the gap floored me — I was missing close to half of what actually existed on their infrastructure.

That gap wasn't bad luck. It was structural. Once you see why, you can't unsee it in every recon workflow you run.

you're running a lookup, not a hunt

Most subdomain enumeration is a database query in disguise. Subfinder, Amass passive, crt.sh — they all pull from the same handful of upstream sources: certificate transparency logs, passive DNS datasets, search engine indexes. Useful, but finite. It only surfaces what's already been publicly observed and indexed somewhere.

Here's the part hunters don't internalize: a subdomain has to be seen by a third party before a passive tool can find it. A staging box spun up last week, an internal API host with no public link, a vhost that only responds to a specific Host header with zero DNS record — none of that exists in any passive dataset yet. Querying the same indexes everyone else queries will never get you past that ceiling.

Four recurring gaps I see in other hunters' recon notes

None
  1. Passive-only, once. One or two tools, merge output, call it done. No permutation pass, no active resolution against a custom wordlist.
  2. Ignoring aggregated bounty-scope datasets. Tools like Chaos exist specifically because programs' own recon gets reused across the community — skipping this means redoing work others have already published.
  3. No JS or source-code mining. Subdomains referenced in a bundled JS file, a CSP header, or a cert's SAN list never touch a public database. They're sitting in files the target itself served you.
  4. No vhost brute-forcing. Some of my best finds have zero public DNS record — they only exist as a Host header value on a shared IP. Passive tools structurally cannot find these.

Each gap alone costs 10–15% coverage. Stack them and "60%" stops sounding pessimistic.

Public databases worth querying before you scan anything

Before you run a single active tool, pull from sources that already did the work:

  • Chaos — ProjectDiscovery's aggregated recon dataset built from live certificate streams, DNS PTR lookups, and scans, scoped specifically to public bug bounty and VDP programs. Free API key, CLI client (chaos-client), returns resolved subdomains with A/AAAA records and HTTP metadata in one call — a genuine shortcut if your target runs a public program.
  • crt.sh / Censys certificate search — certificate transparency, the classic.
  • SecurityTrails / VirusTotal passive DNS — historical DNS resolutions, often surfaces old subdomains that still resolve.
  • Shodan / Censys host search — find services and vhosts bound to the target's IP ranges, not just its known hostnames.
  • DNSDumpster — quick visual map of DNS records and hosting providers, good for orienting on a new target fast.
  • GitHub / GitLab code search — internal hostnames leak in CI configs, .env files, and Postman collections more often than people admit.

None of these replace active recon — they shortcut the parts of it that someone else has already paid the time cost for.

My actual methodology

None
  1. Aggregated + passive baseline — pull from Chaos first if the target has a public program, then layer other sources:
chaos -d target.com -o chaos.txtsubfinder -d target.com -all -recursive -o passive.txtcurl -s "https://crt.sh/?q=%.target.com&output=json" | jq -r '.[].name_value' | sed 's/\*\.//g' >> passive.txt

2. Resolve and dedupe live hosts:

cat chaos.txt passive.txt | sort -u | dnsx -a -cname -resp -silent -o resolved.txt

3. Permutation pass against everything found so far — the step most hunters skip:

cat resolved.txt | dnsgen - | puredns resolve --resolvers resolvers.txt --write permuted.txt

4. JS and source mining:

httpx -l resolved.txt -silent | getJS --complete | grep -oE '([a-zA-Z0-9-]+\.)+target\.com'

5. VHost brute-forcing on shared IPs:

ffuf -w wordlist.txt -H "Host: FUZZ.target.com" -u https://<shared-ip>/ -mc 200,301,302,403

6. Diff against your last run. Not a one-time scan — a standing baseline you re-check on a cadence, because new subdomains are the highest-signal event in any recon pipeline.

Steps 1, 3, 4, and 5 are where I've personally found admin panels, staging environments still wired to production databases, and internal APIs with no auth layer at all — none of it in a single tool's default output.

/Note

No single tool does all of this. That's the actual insight: hunters keep looking for "the best subdomain tool" when the real unlock is running several mediocre techniques together instead of one great one. Aggregated data, passive breadth, active depth, permutation creativity, and source-code mining each expose a different blind spot in the others.

If your recon process fits in one command, it's not recon. It's a starting point you've mistaken for a finish line.