How to Find Subdomains of Any Domain
Every major breach investigation starts the same way: someone finds an asset the organization forgot about. A staging server running an unpatched framework. A developer portal with default credentials. A decommissioned API that still accepts requests. Subdomain discovery is the practice of mapping these hidden surfaces before an attacker does, and understanding how to find subdomains is one of the most fundamental skills in modern security testing.
This guide walks through the techniques, tools, and automation strategies that professional penetration testers use to enumerate subdomains. Whether you are securing your own infrastructure or conducting authorized testing, the methodology here scales from a quick reconnaissance pass to a thorough, multi-source enumeration campaign.
TL;DR
- Subdomains are where defenses are weakest -- forgotten staging servers, shadow IT, and orphaned services are prime attack targets.
- Combine passive sources (CT logs, DNS databases, web archives) with active techniques (DNS brute-force, permutation scanning) for maximum coverage.
- No single tool finds everything -- chain Subfinder, Amass, Alterx, Dnsx, and Nuclei into an automated pipeline for best results.
- Subdomain takeover is a real and common risk when CNAME records point to deprovisioned services.
- One-time enumeration is not enough -- build a continuous monitoring program with scheduled scans and DNS change detection.
Why Subdomain Enumeration Matters for Security
Your primary domain is almost certainly hardened. It sits behind a WAF, runs current software, and gets regular security reviews. But what about staging.example.com? Or jenkins-old.example.com? Or api-v1.internal.example.com that someone set up three years ago and never took down?
Subdomains represent the edges of your attack surface, and they are where defenses tend to be weakest. Here is why they matter:
Forgotten services. Organizations spin up subdomains for projects, demos, and experiments. When the project ends, the DNS record often stays. These orphaned services accumulate vulnerabilities because nobody is patching them or even aware they exist.
Shadow IT. Departments deploy SaaS tools, marketing landing pages, and third-party integrations that create DNS records outside the security team's visibility. Each one is a potential entry point.
Staging and development environments. Dev and staging servers frequently run with weaker authentication, verbose error messages, debug endpoints, and older code versions. If they are publicly resolvable, they are targets.
Subdomain takeover. When a subdomain's CNAME points to a service that has been deprovisioned (a deleted Heroku app, a removed S3 bucket, a canceled Azure instance), an attacker can claim that service and serve arbitrary content on your domain. This is not theoretical: subdomain takeovers are reported on major organizations every week.
Passive Subdomain Discovery Techniques
Passive enumeration collects subdomains without sending any traffic to the target. This is non-intrusive and often yields hundreds of results from public data sources.
Certificate Transparency (CT) Logs
When a Certificate Authority issues a TLS certificate, it logs the certificate (including all Subject Alternative Names) in a public CT log. Since most organizations use separate certificates for each subdomain, CT logs are one of the richest passive sources.
crt.sh is the go-to web interface for querying CT logs. You can also query it programmatically:
# Query crt.sh for subdomains
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
| jq -r '.[].name_value' \
| sort -u
CT logs are particularly useful because they catch subdomains that might not appear in any other source, such as internal services with publicly-issued certificates or subdomains created briefly during testing.
Best Practice
Always query multiple CT log sources. crt.sh is the most popular, but Subfinder and Amass also pull from Facebook CT, Google CT, and Entrust, which may index certificates that crt.sh has not yet processed.
DNS Record Analysis
Zone transfers (AXFR) are rarely allowed on production nameservers, but it costs nothing to try. When they work, you get the complete zone file:
# Attempt zone transfer
dig axfr example.com @ns1.example.com
Beyond zone transfers, TXT records often reveal third-party services. SPF records list mail servers, DKIM selectors hint at email providers, and verification TXT records (like google-site-verification) confirm services in use.
Web Archives and Search Engines
The Wayback Machine, Common Crawl, and AlienVault OTX index URLs across the web. Subdomains that appeared in any crawled page or URL are preserved in these archives, even if the subdomain itself no longer resolves:
# Query web archives with gau
echo "example.com" | gau --subs \
| unfurl -u domains \
| sort -u
Search engine dorking is another passive technique. Queries like site:*.example.com -site:www.example.com can surface subdomains that Google has indexed.
Aggregator Tools
Tools like Subfinder and Amass query dozens of sources simultaneously: certificate logs, DNS databases (SecurityTrails, Censys, Shodan), paste sites, web archives, and threat intelligence feeds. A single Subfinder run typically queries 40+ sources in parallel:
# Subfinder - fast passive enumeration from 40+ sources
subfinder -d example.com -all -o subs.txt
# Amass - deeper enumeration with more sources
amass enum -passive -d example.com -o subs.txt
Active Subdomain Enumeration Techniques
Active methods generate traffic against the target's DNS infrastructure. They find subdomains that are not indexed in any public source but do exist in the organization's DNS.
DNS Brute-Force
This is straightforward: take a wordlist of common subdomain prefixes (www, mail, vpn, staging, api, etc.) and resolve each against the target domain. Modern tools like Puredns and Massdns resolve millions of candidates per minute using a list of trusted public DNS resolvers:
# DNS brute-force with puredns
puredns bruteforce wordlist.txt example.com \
--resolvers resolvers.txt \
-o resolved.txt
The quality of your wordlist matters more than its size. A curated list of 10,000 entries based on real-world subdomain patterns often outperforms a generic list of 1 million random strings.
Common Mistake
Using massive generic wordlists without wildcard DNS detection. Some domains have wildcard A records that resolve every subdomain to the same IP, flooding your results with false positives. Tools like Puredns handle wildcard detection automatically.
Permutation and Alteration
Once you have an initial set of discovered subdomains, you can generate permutations to find related ones. If staging.example.com exists, then staging2.example.com, staging-new.example.com, and staging-eu.example.com are worth checking. Alterx automates this pattern generation:
# Generate permutations from known subdomains
echo "staging.example.com" | alterx -o permutations.txt
# Then resolve them
puredns resolve permutations.txt \
--resolvers resolvers.txt
DNS Resolution Validation
After collecting candidates from passive and active sources, validate that they actually resolve. Dnsx does this efficiently while also collecting record types:
# Validate and get record types
dnsx -l all-subs.txt -a -aaaa -cname -resp -o validated.txt
This step is critical because passive sources often contain stale entries for subdomains that no longer exist.
Chaining Tools for Comprehensive Subdomain Discovery
No single tool finds everything. The real power comes from chaining multiple tools together so that each stage feeds the next. A professional enumeration pipeline typically looks like this:
- Passive collection with Subfinder, Amass, and crt.sh to gather a broad initial list
- Permutation generation with Alterx to expand the list based on observed patterns
- DNS validation with Dnsx to filter down to subdomains that actually resolve
- Port scanning with Naabu to identify open services on live hosts
- Vulnerability scanning with Nuclei to test discovered services for known issues
Running this manually for every engagement is tedious and error-prone. This is exactly the kind of workflow that benefits from automation.
Best Practice
Always deduplicate and validate results between stages. Passive sources often return overlapping data, and stale entries waste time in downstream scanning. Deduplication can reduce your candidate list by 30-50%.
Metric Tower's subdomain discovery pipeline chains Subfinder, Amass, CrtSh, Alterx, Dnsx, Naabu, and Nuclei automatically. You provide the target domain, and the platform handles deduplication between sources, permutation generation, DNS resolution, port scanning, and vulnerability testing in a single orchestrated scan. Each stage passes its results downstream, so Nuclei scans only the hosts and ports that earlier stages confirmed are live.
Understanding Subdomain Takeover Risks
Subdomain takeover occurs when a subdomain points (via CNAME) to an external service that the organization no longer controls. The classic scenario: your team deployed an app on Heroku at myapp.herokuapp.com, created app.example.com as a CNAME to it, then deleted the Heroku app.
The CNAME still exists, Heroku sees the hostname is unclaimed, and anyone can create a new Heroku app to capture traffic destined for app.example.com.
Services commonly affected include Heroku, GitHub Pages, AWS S3, Azure, Fastly, Shopify, and dozens more. The impact ranges from phishing (serving fake login pages on your domain) to cookie theft (if the parent domain sets cookies that the subdomain can read).
Detection involves checking whether CNAME targets return service-specific error pages indicating unclaimed resources. Tools like Subjack and Nuclei (which includes takeover detection templates) automate this. Metric Tower's TakeoverWatch scanner checks all discovered subdomains from Subfinder, Amass, and CrtSh against known takeover fingerprints across 30+ services.
Building a Subdomain Monitoring Program
One-time enumeration is useful, but your subdomain surface changes constantly. New services get deployed, old ones are decommissioned, and third-party integrations add records without your knowledge. A proper monitoring program involves:
Scheduled scans. Run subdomain enumeration on a regular cadence (weekly for high-value domains, monthly for everything else). Compare results against the previous baseline to detect new and removed subdomains.
DNS change detection. Monitor your nameservers for record additions, modifications, and deletions. A new CNAME or A record appearing unexpectedly deserves investigation. Metric Tower's DNS monitoring feature tracks all record types and alerts on changes, with severity classification based on record type.
Certificate Transparency alerting. Subscribe to CT log monitors for your domain. When any CA issues a certificate for a subdomain you don't recognize, you want to know immediately.
Subdomain takeover checks. Run takeover detection against your known CNAME records regularly. When a team decommissions a service, the DNS cleanup often lags behind by days or weeks.
Practical Tips for Better Enumeration
After running subdomain discovery across thousands of domains, here are the patterns that consistently improve results:
Use multiple passive sources. No single source has complete coverage. Running Subfinder and Amass together with crt.sh typically yields 30-50% more results than any one source alone.
Feed results forward. The output of passive enumeration should seed permutation generation. If you found staging-us.example.com, your permutation engine should try staging-eu.example.com, staging-ap.example.com, and similar patterns.
Validate everything. Passive sources contain stale data. Always DNS-validate your combined list before proceeding to port scanning or vulnerability assessment. This saves time and avoids false leads.
Check wildcard DNS. Some domains use wildcard A records (*.example.com resolving to a default IP). Without wildcard detection, your brute-force results will be full of false positives. Tools like Puredns handle this automatically.
Do not forget IPv6. AAAA records can reveal hosts that are not visible via IPv4. Include AAAA resolution in your validation step.
Scope permutations intelligently. Instead of blindly generating millions of permutations, look at the naming patterns in your initial results. If the organization uses {env}-{service}.example.com as a pattern, generate permutations that follow that convention.
From Subdomains to Findings: The Full Pipeline
Subdomain enumeration is not the end goal -- it is the foundation for everything that follows. Once you have a validated list of live subdomains, the next steps are:
- HTTP probing to identify web services, technology stacks, and response behaviors
- Port scanning to find non-HTTP services (databases, SSH, RDP, custom applications)
- Content discovery to find hidden endpoints, admin panels, and API documentation
- Vulnerability scanning to test discovered services against known CVEs and misconfigurations
Each stage narrows the scope while deepening the analysis. The subdomains you discover in phase 1 become the targets for every subsequent phase. This is why thorough enumeration matters: if you miss a subdomain, you miss everything behind it.
Key Takeaways
- 1 Combine passive and active enumeration -- no single source or technique provides complete coverage of an organization's subdomain surface.
- 2 Chain tools into a pipeline (collect, expand, validate, discover, scan) so each stage feeds the next and nothing falls through the cracks.
- 3 Check for subdomain takeover risks on every CNAME record -- dangling DNS entries to deprovisioned services are exploited regularly.
- 4 Build continuous monitoring into your program -- your subdomain surface changes constantly, and one-time scans have a short shelf life.
If you are looking to automate this entire pipeline, Metric Tower's automated recon workflow handles the full chain from passive enumeration through vulnerability scanning with a single scan configuration. The top subdomain enumeration tools comparison covers additional standalone options if you prefer to build your own pipeline from individual tools.