Subdomain Enumeration

Why Subdomains Matter

The main domain (example.com) is usually well-hardened — it faces constant attacks and has dedicated security teams. Subdomains, however, are often neglected. Development servers, staging environments, internal tools, and forgotten applications live on subdomains. These are your primary targets because they typically have:

• Weaker security controls
• Default credentials
• Debug modes enabled
• Outdated software
• Less monitoring

Method 1: Certificate Transparency Logs

As covered in passive recon, CT logs are the fastest way to discover subdomains. They are passive, comprehensive, and reveal subdomains that are not linked anywhere.

# crt.sh query
curl -s "https://crt.sh/?q=%.example.com&output=json" | jq -r '.[].name_value' | sort -u

# Google Transparency Report
curl -s "https://transparencyreport.google.com/transparencyreport/api/v3/httpsreport/securecerts?domain=example.com" | jq '.certs[].dnsNames[]' | sort -u

Method 2: DNS Brute-Forcing

DNS brute-forcing queries DNS servers with a wordlist of common subdomain names. If the DNS server returns a record, the subdomain exists.

# Using dnsrecon
dnsrecon -d example.com -t brt -n 8.8.8.8 -w subdomains-top1million-5000.txt

# Using ffuf with DNS mode
ffuf -u "https://FUZZ.example.com" -w subdomains.txt -t 100

Method 3: Search Engine Enumeration

Search engines index subdomains that may not appear in CT logs or DNS:

# Google dork
site:*.example.com -site:www.example.com

# Bing
site:*.example.com

Method 4: Reverse DNS Lookups

If you know the target's IP range, perform reverse DNS lookups to find subdomains pointing to those IPs:

# Using dnsrecon
dnsrecon -r 192.168.1.0/24 -n 8.8.8.8

# Using nmap
nmap -sL --dns-servers 8.8.8.8 192.168.1.0/24

Method 5: Zone Transfer Attempt

DNS zone transfers (AXFR) replicate DNS records between servers. Misconfigured DNS servers allow anyone to download the entire zone file:

# Attempt zone transfer
dig @ns1.example.com example.com AXFR

# Using dnsrecon
dnsrecon -d example.com -t axfr -n ns1.example.com

Zone transfers are rarely allowed on modern DNS servers, but always try — some misconfigurations still exist.

Amass — The Comprehensive Enumerator

Amass (by OWASP) is the most powerful subdomain enumeration tool. It combines passive and active techniques, integrating with dozens of data sources:

# Passive enumeration only
amass enum -passive -d example.com -o subdomains.txt

# Active enumeration with brute-forcing
amass enum -brute -d example.com -w /usr/share/wordlists/deepmagic.com-prefixes-top50000.txt -o subdomains.txt

# Full enumeration with all sources
amass enum -d example.com -o subdomains.txt

Amass integrates with:

• Certificate transparency logs
• Search engines
• DNS resolvers
• Web archives
• Passive total databases
• Social media platforms

Subfinder — Fast and Simple

Subfinder is a fast, passive subdomain discovery tool written in Go:

# Basic enumeration
subfinder -d example.com -o subdomains.txt

# With all sources enabled
subfinder -d example.com -all -o subdomains.txt

# Recursive enumeration (enumerate subdomains of subdomains)
subfinder -d example.com -recursive -o subdomains.txt

Assetnote — Curated Intelligence

Assetnote provides curated subdomain wordlists based on real-world data:

# Download Assetnote wordlist
curl -s "https://wordlists-cdn.assetnote.io/data/manual/best-dns-wordlist.txt" -o assetnote-dns.txt

# Use with amass
amass enum -brute -d example.com -w assetnote-dns.txt

Validating Results

After enumeration, you have a list of potential subdomains. Many will be dead, parked, or wildcard entries. Validate them:

# Check which subdomains resolve
for sub in $(cat subdomains.txt); do
  host "$sub.example.com" | grep "has address" && echo "$sub"
done

# Using httpx to check which are alive
httpx -l subdomains.txt -silent -status-code -title -tech-detect -o alive.txt

Handling Wildcard DNS

Some domains use wildcard DNS: *.example.com resolves to the same IP for any subdomain. This floods your results with false positives.

Detection:

# Query a random subdomain that should not exist
host random12345.example.com
# If it resolves, wildcard DNS is in use

Filtering:

When wildcard DNS is active, validate each subdomain by checking if it returns unique content:

# Compare response of real subdomain vs random subdomain
curl -s "https://real.example.com" | md5sum
curl -s "https://random12345.example.com" | md5sum
# If hashes match, it is a wildcard response

Practical Workflow

1. Passive enumeration — Amass passive, crt.sh, DNS history
2. Active brute-force — Amass brute, dnsrecon with wordlists
3. Validation — httpx to check which subdomains are alive
4. Deduplication — Sort and remove duplicates
5. Categorization — Group by technology, response type, and potential value

Categorizing Discovered Subdomains

Once you have a validated list of subdomains, categorize them by potential value:

High Priority:

• dev, staging, test, uat — Development environments with weaker security
• admin, manage, console, panel — Administrative interfaces
• api, api-v1, api-v2, graphql — API endpoints
• internal, intranet, corp — Internal tools exposed to the internet
• vpn, remote, mail, email — Remote access and communication

Medium Priority:

• blog, forum, community — User-generated content (XSS, CSRF targets)
• shop, store, payment — E-commerce functionality
• cdn, static, assets — Content delivery (may have path traversal)

Low Priority:

• www, web, home — Main production site (already well-tested)
• Parked domains and redirects

Technology Fingerprinting

Identify the technology stack of each subdomain:

# Using httpx
httpx -l subdomains.txt -silent -tech-detect -title -status-code

# Using WhatWeb
whatweb -i subdomains.txt --aggression 3

Different technologies have different vulnerability profiles. A Jenkins server has known RCE exploits; a WordPress site has a large plugin vulnerability database.

Practical Example: Finding a Staging Server

You enumerate subdomains for example.com and find:

dev.example.com      — 200 OK, nginx, "Development Portal"
staging.example.com  — 200 OK, Apache, "Staging Environment"
api.example.com      — 200 OK, Node.js, JSON response
admin.example.com     — 403 Forbidden, nginx

You prioritize:

1. staging.example.com — Likely has debug enabled, default credentials, and production data
2. admin.example.com — 403 means it exists; try different paths and methods
3. dev.example.com — Development environment may have source code exposure
4. api.example.com — API endpoints often have weaker authentication

Documenting Findings

For each discovered subdomain, record:

Subdomain: staging.example.com
IP: 203.0.113.10
Status: 200 OK
Technology: Apache/2.4.41, PHP 7.4
Title: Staging Environment
Priority: High
Notes: Default admin credentials work (admin/admin)

This documentation feeds directly into your vulnerability assessment and reporting.