Subdomain Enumeration: Techniques for Finding Hidden Attack Surface

Short answer

Subdomain enumeration is the process of finding every DNS name that points to an organization's infrastructure. Organizations deploy hundreds of subdomains over time — staging environments, admin panels, partner portals, internal tools — and many of them are less secured than the main domain. Finding these is how attackers discover the attack surface that the organization forgot.

The idea in one minute

Imagine a company that secures its front door with a guard, cameras, and an alarm system. But over ten years, employees have propped open side doors, built unmarked entrances for deliveries, and constructed temporary access points that nobody remembers to close. A subdomain enumerator is someone who walks the perimeter and maps every single door, window, and hatch — including the one the company forgot existed.

The main domain example.com is the front door. admin.example.com, staging.example.com, dev.example.com, jenkins.example.com, vpn.example.com, partner-portal.example.com — these are the side entrances. Security teams audit the front door every quarter. The side entrances may never have been reviewed.

Passive enumeration techniques

Passive techniques leave no trace on the target's infrastructure — no DNS queries to the target's nameservers, no HTTP requests to their servers. The information is collected from public sources.

Certificate Transparency logs

Every HTTPS certificate issued by a public Certificate Authority is logged to Certificate Transparency (CT) logs. These logs are publicly queryable and contain every domain and subdomain that a certificate was issued for.

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

CT logs are the single most effective passive enumeration technique. They reveal subdomains that are not linked from any page, not indexed by search engines, and sometimes not even in DNS (internal-use certificates with private names). Tools like crt.sh, CertSpotter, and Google's CT search all query the same logs.

Search engine dorking

Google indexes subdomains through links, sitemaps, and JavaScript bundles. Search operators:

site:*.example.com
site:example.com -www
inurl:example.com intranet

Bing, Shodan, and Censys also index subdomain information. Censys is particularly effective because it scans every HTTPS certificate on the internet and makes the data searchable.

DNS records in public datasets

SecurityTrails, VirusTotal, AlienVault OTX, and DNSDumpster maintain historical DNS databases. These are particularly useful for finding subdomains that no longer exist — a subdomain that was taken down may still appear in historical data, and the subdomain's DNS record may have been re-registered by an attacker.

Web archive (Wayback Machine)

The Internet Archive stores snapshots of web pages. Finding a page at https://staging.example.com/admin/login in a 2019 snapshot means the subdomain existed, and if the DNS record was never cleaned up, it may still resolve to an IP that someone else now controls.

JavaScript source analysis

Modern web applications embed API endpoints, WebSocket URLs, and internal links in JavaScript bundles. Download the JavaScript files from the main domain and search for strings matching common subdomain patterns:

grep -ohP 'https?://[a-zA-Z0-9._-]+\.example\.com' *.js | sort -u

Active enumeration techniques

Active techniques send traffic to the target's infrastructure. They are more thorough but leave traces.

DNS brute force

The most reliable active technique. Given a list of common subdomain names, query the target's DNS server for each one. A response with an IP address means the subdomain exists.

for sub in $(cat common_subdomains.txt); do
  host "$sub.example.com" | grep "has address" && echo "$sub.example.com"
done

Wordlists: common_subdomains.txt should include at minimum 10,000 entries. The subdomains-top1million-5000.txt from SecLists and the commonspeak2 wordlists are standard. DNS brute force is rate-limited by the target's DNS server — expect throttling above 50 queries per second.

DNS zone transfer

Zone transfer (AXFR) is the DNS equivalent of asking the nameserver for its entire database. It almost never works on production nameservers, but it is always worth trying:

dig axfr @ns1.example.com example.com

If successful, you receive every DNS record for the domain in a single response — every subdomain, every IP, every MX and TXT record. Zone transfers that work on internal-only nameservers are a common finding in internal penetration tests.

DNS wildcard detection

Some domains have a wildcard DNS record (*.example.com returns an IP for any query). If wildcards exist, every subdomain in your brute force list will appear to resolve. Detect wildcards by querying random UUID subdomains:

dig "r9xkz7q2.example.com" +short
# If it returns an IP, wildcard is active.

If a wildcard exists, DNS brute force is ineffective — you need to probe each resolved subdomain with an HTTP request and compare the responses to the wildcard response.

Web enumeration

After DNS resolution, HTTP probing determines whether the subdomain serves web content. Tools like httpx and httprobe check common ports:

cat resolved_subdomains.txt | httpx -ports 80,443,8080,8443 -status-code -title

This step separates "DNS record exists" from "web application is running." Many subdomains have DNS records pointing to load balancers or CDNs that serve error pages for unknown hostnames — only a web probe confirms the subdomain is actually in use.

How attackers use subdomains

Forgotten staging environments

staging.example.com often runs the latest code before production. It may have:

• Debug endpoints enabled
• Weak credentials (admin/admin)
• Unpatched vulnerabilities
• Realistic test data (credit card numbers, PII)

Expired DNS records

A subdomain that was decommissioned but not removed from DNS can be registered by an attacker on a cloud provider. If api.example.com pointed to an AWS load balancer that was deleted, the attacker creates a new load balancer with the same DNS name and receives traffic intended for api.example.com.

Internal tools on the public internet

jenkins.example.com, grafana.example.com, kibana.example.com, gitlab.example.com, jira.example.com — these are intended for internal use but are frequently accessible from the internet with default credentials.

Verification: real vulnerability or false positive?

A subdomain that resolves to an IP is not necessarily a vulnerability. It becomes one when:

• The application on the subdomain is outdated or unpatched.
• The subdomain uses weak or default credentials.
• The subdomain exposes internal tools or debug interfaces.
• The DNS record points to a cloud service that the organization no longer controls (subdomain takeover).
• The subdomain has no valid TLS certificate (credential interception).

Real-world impact

The most common subdomain-based attacks are subdomain takeovers — when a DNS CNAME record points to an unclaimed cloud resource (Azure, AWS, GitHub Pages, Heroku). The attacker claims the resource on the same cloud provider and serves arbitrary content under the victim's domain. This enables phishing attacks that pass DKIM, SPF, and DMARC checks because the email originates from a legitimate domain. In 2020, researchers at Palo Alto Networks found over 200,000 domains vulnerable to subdomain takeover across the Alexa top million.

Prevention

1. Maintain a complete inventory of every DNS record in the organization. Automate discovery with the same tools attackers use.
2. Remove DNS records when decommissioning services. Add a monitoring check that alerts when a CNAME resolves to an unclaimed cloud resource.
3. Enforce TLS on every subdomain that accepts user connections. Use automated certificate management (ACME/LetsEncrypt).
4. Implement wildcard TLS certificates to protect against attackers who discover unlisted subdomains.
5. Add security headers to default server blocks so that unconfigured subdomains do not serve sensitive content.
6. Register common subdomain variants for internal-use-only services so they cannot be registered by attackers.

Related vulnerabilities

• Subdomain takeover — The direct consequence of forgotten DNS records pointing to deprovisioned services.
• SSRF — Internal subdomains that resolve to private IP ranges become SSRF targets.
• Information disclosure — Every subdomain is a data point in the attacker's reconnaissance phase.

Testing methodology (do this safely)

Start with passive enumeration (CT logs, search engines, historical DNS). Document every subdomain found. Then run active DNS brute force against the target with rate limiting (50 qps max). Probe each confirmed subdomain with HTTP requests. Compare responses to detect wildcard filtering. For each subdomain serving web content, check TLS certificate validity, security headers, and common admin paths. Only test your own applications or authorized bug bounty programs.

Further reading

• crt.sh: Certificate Transparency log search
• ProjectDiscovery: Subfinder
• OWASP Amass: Network mapping and attack surface discovery
• MITRE: CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor

Nyxeara perspective

Subdomain enumeration is the first step in every Nyxeara investigation. The discovery phase runs passive enumeration using Certificate Transparency logs, DNS record databases, and search engine data before any active probing begins. The results populate the entity model — each subdomain becomes an entity with an observed SSL certificate, HTTP response fingerprint, and technology stack. The correlation engine then links subdomains with the same IP range or the same TLS issuer to build an infrastructure map. Forgotten subdomains are surfaced as medium-severity findings with the tag "expanded-attack-surface" — not because the subdomain itself is vulnerable, but because it is a door the security team forgot to lock.