April 27, 2026 · 9 min read · subdomain-enumerationreconosint

Subdomain Enumeration: The 5 Techniques That Actually Work in 2026

Subdomain enumeration is the first real step in any reconnaissance operation. Find the right subdomains and you find dev servers, internal APIs, forgotten staging environments, and admin panels. Miss them and you miss the entire attack surface. Here's how security researchers do it in 2026.

Most organizations have way more subdomains than they realize. Dev servers, staging environments, internal tools, legacy applications — all of them exist in DNS somewhere, and all of them are reachable if you know where to look. A single forgotten subdomain with weak auth or an unpatched vulnerability has been the entry point for some of the biggest breaches in recent memory.

Subdomain enumeration is the process of finding those subdomains before an attacker does. Here's the playbook that security researchers actually use.

Technique 1: Certificate Transparency Logs

Certificate Transparency (CT) logs are the fastest, most comprehensive way to find subdomains. Every publicly trusted SSL/TLS certificate is logged publicly — meaning every subdomain that ever got a certificate is recorded and searchable. This includes internal hostnames that organizations didn't intend to expose.

The major CT log operators:

crt.sh — The most popular CT search interface. Search by domain and get every certificate ever issued.
Facebook CT API — crt.sh's infrastructure, accessible programmatically for automated workflows.
Google Transparency Report — Google's CT log search, fast and comprehensive.

To query crt.sh manually, visit https://crt.sh/?q=example.com. To automate it:

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

What makes CT logs powerful: they catch subdomains that no longer exist. If a dev server was decommissioned six months ago but had a certificate, it's still in the logs. The hostname is still resolvable in some cases, and even if it's not, it tells you what internal naming conventions the organization uses.

The Permanent Exposure Problem: CT logs are append-only. There's no mechanism to remove a subdomain from historical logs. If you issued a certificate for internal-api.prodaction.example.com three years ago, it's in the logs forever. There's no revocation for subdomains in CT — only certificate revocation, which most tools don't check. Assume every subdomain you've ever cert'd is permanently discoverable.

Technique 2: DNS Zone Transfer (AXFR)

A DNS zone transfer requests a complete copy of a domain's DNS records from a nameserver. If the nameserver is misconfigured to allow zone transfers from anyone, you get the entire DNS map in one shot — every subdomain, every record type, every internal hostname the DNS server knows about.

# Attempt a zone transfer
dig axfr @ns1.example.com example.com

# Using nslookup
nslookup
> server ns1.example.com
> ls -d example.com

AXFR works against nameservers that don't restrict who can request zone transfers. Many managed DNS providers block it by default, but misconfigurations still happen — especially on internal DNS servers, small registrars, and legacy infrastructure.

Pro Tip — Automated AXFR Discovery

Use dnsenum or fierce for automated zone transfer attempts

Tools like dnsenum and fierce automate AXFR attempts alongside dictionary-based subdomain guessing. They're not as sophisticated as modern asset discovery platforms, but they're fast and free.

dnsenum --enum example.com -f /usr/share/dnsenum/dns.txt

Technique 3: NSLOOKUP + Common Record Types

Not every subdomain has a certificate or appears in zone transfers. Querying DNS directly for specific record types can surface subdomains that other methods miss — especially mail servers (MX), text records (TXT), nameservers (NS), and canonical names (CNAME).

# Query multiple record types with dig
dig MX example.com +short
dig TXT example.com +short
dig NS example.com +short
dig CNAME dev.example.com +short

What each record type reveals:

MX records — Mail server hostnames. Often reveal internal naming patterns like mail.example.com or mx2.backup-mail.example.com.
TXT records — Can contain SPF configurations with internal IP ranges, domain verification tokens revealing internal systems, and third-party service hostnames (SendGrid, Salesforce, AWS).
NS records — Nameservers for subdomains — each NS record points to a potentially different infrastructure handling that subdomain segment.
CNAME records — Canonical name mappings reveal where subdomains actually point — cloud services, CDN endpoints, third-party platforms.

TXT records in particular often contain infrastructure metadata that organizations don't realize is public. SPF records list IP ranges. DKIM records reveal mail provider hostnames. Verification tokens can expose internal system names.

Technique 4: Permutation and Fuzzing

Passive methods find what's already recorded. Fuzzing finds what's not. Permutation fuzzing takes known subdomains and generates variations — adding prefixes like dev-, staging-, test-, or suffixes like -internal, -backup, -old — then checks if those variations resolve.

Common wordlists for permutation:

dev, staging, test, prod, qa, uat — Environment markers
admin, crm, erp, portal, dashboard — Internal tool names
api, v1, v2, beta, legacy — Version and API markers
internal, backup, old, archive — Lifecycle markers
mail, ftp, ssh, vpn, jira, confluence — Service-specific

# Using amass for permutation
amass enum -passive -d example.com -whitelist -限时 10m

# Using shuffledns with a wordlist
./shuffledns -d example.com -list subdomains.txt -w words.txt -r resolvers.txt -o found.txt

Technique 5: OWASP Amass + Asset Discovery Chaining

OWASP Amass is the most capable open-source subdomain enumeration tool. It chains multiple data sources — CT logs, crt.sh, SecurityTrails, Riddler, CertSpotter, DNSDB, and more — and runs them in coordination with brute-force wordlists and permutation logic.

Amass handles the entire enumeration lifecycle:

Passive crawling from public data sources (no direct DNS queries)
Active enumeration with wordlists and permutation
DNS resolution with wildcard detection
Infrastructure classification — identifies what's a cloud provider, CDN, or internal host
Output in structured formats for integration into further tooling

# Full Amass enumeration with all techniques
amass enum -include 2026-04-27  # specify cert date range
amass enum -active -d example.com -brute -w /path/to/wordlist.txt

# Amass tracking for ongoing monitoring
amass track -d example.com

Real Recon Example

Enumerating a Fictional Company: Meridian Financial

Let's say you're assessing meridianfinancial.com. Here's a realistic workflow:

Step 1 — CT log scan:

curl -s "https://crt.sh/?q=meridianfinancial.com&output=json" | jq -r '.[].name_value' | sort -u | grep -v "^$"

Result: admin.meridianfinancial.com, vpn.meridianfinancial.com, dev-api.meridianfinancial.com, staging.meridianfinancial.com, old-portal.meridianfinancial.com

Step 2 — MX record enumeration:

dig MX meridianfinancial.com +short

Result: mail.meridianfinancial.com, mail2.meridianfinancial.com. The naming suggests mail3 may exist.

Step 3 — TXT record enumeration:

dig TXT meridianfinancial.com +short

Result: SPF records showing AWS IP ranges, a DKIM record referencing sendgrid._domainkey, and a verification token for bmc.meridianfinancial.com — indicating they use BMC (BMC Software, an enterprise IT tool).

Step 4 — Permutation fuzzing:

Using discovered subdomains as seed: dev-api → dev-api-backup, dev-api-staging, api-dev. admin → admin-staging, admin-old, admin-v2.

Findings: dev-api.meridianfinancial.com resolves and appears to have an unauthenticated API explorer. old-portal.meridianfinancial.com redirects to a legacy login page with known exploits. The bmc.meridianfinancial.com subdomain runs an out-of-date BMC FootPrint ticketing system.

Protecting Your Subdomain Attack Surface

You can't remove subdomains from Certificate Transparency logs. Once a certificate has been issued and logged, it's permanent and public. Here's what you can actually do:

Audit CT logs for your domains regularly. Search crt.sh for your domains and identify every subdomain that has ever had a certificate. Even decommissioned subdomains are still in the logs.
Use internal naming conventions that don't expose intent. server-42.internal.prod.us-east-1.aws in a cert is better than admin-panel.internal.com.
Restrict which subdomains get certificates. Use a private PKI for internal services instead of public CAs. Internal hostnames don't need public certificates.
Monitor for unexpected new certificates. Services like CertSpotter and SecurityTrails can alert you when a new certificate is issued for your domain — including unexpected subdomains.
Use HSTS preloading for your main domain. While this doesn't hide subdomains, it ensures browsers never visit the non-HTTPS version of your primary domain.

The right approach: Treat Certificate Transparency as public. Any hostname you've ever put in a public certificate is discoverable. Build your security posture around that reality — don't try to un-ring the bell.

Find Your Subdomain Attack Surface

EdgeIQ's Subdomain Discovery tool combines CT log analysis, DNS enumeration, and permutation fuzzing to give you a complete map of your exposed subdomains — including ones you forgot existed.

Scan your domain free →

The Bottom Line

Subdomain enumeration is not a single technique — it's a workflow that combines passive CT log searches, DNS record queries, zone transfer attempts, permutation fuzzing, and chainable tools like Amass. Each technique catches subdomains that the others miss. The organizations with the worst subdomain exposure are usually the ones who didn't know half their subdomains existed.

Run your own enumeration before someone else runs theirs.