Subdomain Enumeration Tools 2026 — 7 Best Methods to Find Every Hidden Subdomain
Mr Elite ··
15 min read
⚠️ Authorised Scope Only: Only enumerate subdomains of targets within an explicit bug bounty programme scope or your own domains. Passive enumeration using public data sources is legal against any target. Active DNS brute force should only be performed within confirmed programme scope. Never scan subdomains outside your authorised scope.
Subdomain enumeration tools 2026 — the recon skill that separates bug bounty hunters who find something from those who spend hours on a main domain that has been hammered by a thousand other hunters before them. Every major bug bounty programme’s best findings live on subdomains — staging environments, internal APIs, admin panels, legacy applications, and developer tools that are technically in scope but invisible to anyone who only looks at the main site. Today I am showing you the complete 7-method pipeline that professionals use to find every single subdomain before touching a single vulnerability.
🎯 What You’ll Master in This Guide
Understand passive vs active subdomain enumeration and when to use each
Run Subfinder, Amass, and Assetfinder with optimal configurations
Extract subdomains from certificate transparency logs via crt.sh
Use Google dorks to find indexed subdomains no tool will find
Build an automated deduplication and live-host probing pipeline
⏱️ 48 min read · 3 hands-on exercises
📊 What is your subdomain enumeration workflow?
✅ Every hunter finds more with a multi-source pipeline than any single tool. This guide gives you the complete methodology plus the shell commands to automate the entire workflow in one pass.
📋 What You’ll Master — Subdomain Enumeration Tools 2026
Subdomain enumeration is step one in the bug bounty recon methodology. Before you test a single parameter or run a single scanner, you need to know the full scope of what you are working with. The Day 6 Bug Bounty course article introduced the concept — this guide goes deeper with the complete 7-source pipeline and the automation commands that make it repeatable on any target in under 10 minutes.
Why Subdomains Are the Highest-Value Bug Bounty Attack Surface
The main application at www.company.com has been tested by hundreds of hunters before you. It has received regular security audits. Its developers are aware of the most common vulnerabilities. The attack surface is well-worn. The subdomains are different. Staging environments run the same codebase without the latest security patches. Admin panels run internal tools built by developers who assumed nobody would find them. API endpoints were built for mobile apps and were never hardened. Legacy subdomains run outdated software that predates the company’s security programme entirely.
Statistics from HackerOne and Bugcrowd consistently show that the majority of Critical and High findings in large programmes come from assets that were not the primary application. Subdomain enumeration is the skill that accesses those assets — and the hunters who build comprehensive subdomain pipelines consistently earn more per hour than those who test only what the programme’s brief explicitly lists.
securityelites.com
Subdomain Risk Classification — Why Subdomains Pay More
admin.target.com
Admin panel — often weaker auth, higher access, less tested
HIGH RISK
staging.target.com
Staging env — same code, older patches, real data sometimes present
HIGH RISK
api.target.com
API endpoints — less WAF coverage, often exposes more data
CDN/static assets — usually low value unless misconfigured S3
LOW RISK
📸 Subdomain risk classification — admin, staging, and legacy subdomains consistently yield the highest-severity bug bounty findings. CDN and static asset subdomains are usually low value unless they indicate an S3 bucket takeover opportunity.
Passive Subdomain Enumeration — Subfinder, Amass and Assetfinder
SUBFINDER, AMASS AND ASSETFINDER — INSTALL AND CORE COMMANDS
# Install all three tools
sudo apt install subfinder amass -y
go install github.com/tomnomnom/assetfinder@latest
Step 4: Open Google and search:
site:tesla.com -www.tesla.com
(finds indexed subdomains Google knows about)
Step 5: Also try:
site:tesla.com inurl:admin
site:tesla.com inurl:login
site:tesla.com inurl:api
Step 6: Compare: which method found more subdomains?
Which method found different subdomains?
Step 7: Go to chaos.projectdiscovery.io/chaos-bugbounty-list
Find your target company — download their pre-collected
subdomain dataset if available.
Step 8: Count the difference in results between:
crt.sh alone vs crt.sh + Google + Chaos combined
✅ What you just learned: Even without installing a single tool, crt.sh + Google dorks + Chaos gives you a substantial subdomain list in minutes. Each source finds different subdomains — crt.sh reveals certificate-covered subdomains, Google finds indexed pages, Chaos provides pre-collected programme data. The combination is always more complete than any single source. This browser-only workflow is also useful when you are on a device without your tools installed.
📸 Screenshot your combined results showing source comparison and share in #subdomain-recon on Discord.
Certificate Transparency — crt.sh and SSL-Based Discovery
For your top 5 selections, explain:
— What makes this subdomain higher priority than others?
— What specific vulnerability type would you test first on it?
— What technology fingerprint would change your priority ranking?
✅ Tier 1 (test first): pay, admin, login, internal, legacy — high privilege functions and forgotten infrastructure. Tier 2: staging, dev, beta, api, vpn — test environments and API surfaces. Tier 3: support, status — user-facing but potentially with elevated access. Tier 4-5: blog, help, static, cdn, images, fonts, careers, privacy — usually low value unless S3 bucket or subdomain takeover. The key insight: you are not prioritising by how interesting the name sounds — you are prioritising by the business function the subdomain likely serves and how that maps to authentication, data access, and unpatched infrastructure.
📸 Write your prioritised list with reasoning and share in #subdomain-recon on Discord.
The Complete Subdomain Pipeline — Collect, Deduplicate, Probe and Prioritise
Step 1: Go to tryhackme.com and search for “Passive Reconnaissance”
(free room, no subscription required)
Step 2: Complete the room tasks that cover:
— sublist3r subdomain enumeration
— crt.sh certificate transparency lookup
— Shodan for subdomain discovery
Step 3: For each method in the room, run the same query on
a different target from a public bug bounty programme
using the browser-based AttackBox
Step 4: Document for each method:
— How many unique subdomains found?
— Which subdomains look interesting (admin, api, staging)?
— Which method would you run first on a new target?
Step 5: Install and run httpx on discovered subdomains:
echo “list_of_subdomains” | httpx -silent -status-code
— Which subdomains return 200 OK?
— Which return 403 (forbidden) — still worth noting
— Which return 404 (not found) — check for takeover
✅ What you just learned: The TryHackMe Passive Recon room gives you hands-on experience with the core passive tools in a guided environment. The additional httpx probing step is what converts a raw subdomain list into an actionable target list. A 403 response on admin.target.com is still interesting — it means the panel exists, just access-controlled. A 404 on a subdomain pointing to an S3 bucket CNAME is a takeover candidate. Response codes tell you what to do next with each subdomain.
📸 Screenshot your httpx output showing live hosts with status codes and share in #subdomain-recon on Discord.
Subdomain Takeover Detection — The Most Overlooked Step
After you have a deduplicated list of resolved subdomains, one of the highest-value checks you can run in under two minutes is subdomain takeover detection. A takeover occurs when a subdomain’s DNS record points to a service (S3 bucket, GitHub Pages, Heroku, Azure, Netlify, etc.) that has been deleted or deregistered — anyone who registers the same service under that name can serve content under the company’s subdomain.
The tool subzy automates this check across your entire discovered subdomain list. It fingerprints the response from each subdomain against known takeover signatures — “NoSuchBucket” for S3, “There isn’t a GitHub Pages site here” for GitHub Pages, “No such app” for Heroku — and flags any subdomains where the CNAME points to an unclaimed third-party service. This check consistently finds High-severity findings in large bug bounty programmes because infrastructure cleanup is rarely a priority for engineering teams.
SUBDOMAIN TAKEOVER DETECTION — SUBZY AND MANUAL VERIFICATION
# Install subzy
go install github.com/PentestPad/subzy@latest
# Run against your full subdomain list
subzy run –targets all_subdomains.txt –output takeovers.txt
curl -s https://staging.target.com | grep -i “NoSuchBucket\|There isn’t\|No such app”
<Code>NoSuchBucket</Code> → Takeover confirmed
# IMPORTANT: Do NOT register the bucket — report with CNAME evidence only
When you find a takeover candidate, document the CNAME record, the response body showing the “unclaimed” error message, and a brief impact statement explaining what an attacker could host under that subdomain. The report does not require you to register the service — the CNAME pointing to a non-existent resource is sufficient proof of the vulnerability. Registering it without authorisation crosses into territory that could violate programme rules even on legitimate bug bounty programmes.
🧠 QUICK CHECK — Subdomain Enumeration
You find that staging.target.com returns a CNAME record pointing to an S3 bucket, but the bucket returns a “NoSuchBucket” error. What vulnerability does this indicate and what is your next step?
assetfinder –subs-only TARGETLightweight fast passive tool — good secondary source
curl -s “https://crt.sh/?q=%.TARGET&output=json” | jq -r ‘.[].name_value’Certificate transparency subdomain extraction via crt.sh API
cat *.txt | sort -u > all.txtCombine and deduplicate all tool outputs
cat all.txt | dnsx -silent -a -o resolved.txtResolve subdomains to IPs — filter dead ones
cat resolved.txt | httpx -silent -status-code -title -tech-detectProbe live HTTP/HTTPS — get status codes, page titles, tech stack
❓ Frequently Asked Questions
What is subdomain enumeration and why does it matter for bug bounty?
Subdomain enumeration discovers all subdomains associated with a target domain. It matters because most programmes include all subdomains in scope, and subdomains frequently run older, less-tested applications — staging environments, admin panels, and legacy services. The most valuable bug bounty findings consistently come from subdomains rather than the main application.
What is the difference between passive and active subdomain enumeration?
Passive collects data from external sources — search engines, certificate transparency logs, DNS databases — without sending traffic to the target. Active sends DNS queries directly to the target including wordlist brute force. Passive is always safe for in-scope targets. Active should only be used within confirmed programme scope.
Which subdomain enumeration tool is best in 2026?
No single tool is best — each queries different sources. The professional approach uses multiple tools. Subfinder is the best starting tool. Amass provides deeper coverage. crt.sh fills certificate transparency gaps. Running all three and deduplicating consistently produces significantly more subdomains than any single tool alone.
How do certificate transparency logs help find subdomains?
Every TLS certificate issued by a public CA is recorded in CT logs. When a company creates a certificate covering subdomains, those names appear in the CT log — retrievable by anyone via crt.sh. This makes CT logs one of the most reliable passive subdomain sources, revealing subdomains not indexed by search engines or listed in any DNS database.
What should I do with subdomains once I find them?
The pipeline is: deduplicate → probe with httpx (live hosts) → screenshot with gowitness → prioritise by technology and response type → test for subdomain takeover → manually test the most interesting subdomains. Focus on admin, login, staging, api, and legacy subdomains first.
How many subdomains should I expect to find on a large company?
Startups: 10–50. Mid-sized SaaS: 100–500. Large enterprises: 1,000–10,000+. Some major programmes exceed 50,000 unique subdomains. The number matters less than quality — one forgotten admin panel with no auth beats 1,000 CDN asset subdomains.
← Related
Bug Bounty Day 6: Subdomain Enumeration Basics
Related →
Bug Bounty Recon Methodology
📚 Further Reading
Bug Bounty Day 6: Subdomain Enumeration— The foundational course article covering Subfinder basics and the mindset behind passive recon that this guide builds upon.
Amass Tutorial Kali Linux— Deep dive into Amass configuration, API key setup, and advanced enumeration techniques for comprehensive subdomain coverage.
Bug Bounty Recon Methodology— The complete recon methodology covering subdomain enumeration, JavaScript analysis, parameter discovery, and attack surface mapping for bug bounty programmes.
Subfinder GitHub Repository— Official Subfinder documentation covering API key configuration, all supported data sources, and output format options for pipeline integration.
crt.sh Certificate Transparency Search— The free certificate transparency log search engine — directly queryable for subdomain discovery with JSON API output for command-line integration.
ME
Mr Elite
Owner, SecurityElites.com
The best bug I ever found came from a subdomain I almost skipped. After running my full pipeline on a large SaaS company, I had 847 subdomains. I was working through them in order of priority and I got to oldportal.target.com — the name suggested legacy, probably dead. httpx showed it returning 200 with title “Legacy Customer Portal v1.2 — Please contact IT”. I almost skipped it. Instead I ran Nikto out of habit. It found directory listing enabled on /backups/. Inside: database export files from 2019 with 200,000 customer records. The company had completely forgotten the subdomain existed. Critical severity, responsible disclosure accepted, $7,500. That $7,500 came from one line in a 847-line subdomain list that I almost skipped. Run the full pipeline. Prioritise. But never skip.
Leave a Reply