How to Find All Subdomains of a Domain

Subdomain enumeration is the foundation of external reconnaissance. Every subdomain represents a potential entry point -- a forgotten staging server, an unpatched admin panel, a legacy application that nobody remembers deploying. According to the Verizon 2025 Data Breach Investigations Report, third-party involvement in breaches doubled to 30%, and a significant portion of these breaches trace back to assets that organizations did not know they had.

The problem is straightforward: you cannot protect what you cannot see. Most organizations vastly underestimate the number of subdomains associated with their primary domain. A company with a single website might have fifty, a hundred, or even thousands of subdomains -- each one a potential attack vector.

Why Subdomain Enumeration Matters

Every subdomain tells a story. staging.example.com reveals a development workflow. vpn.example.com reveals remote access infrastructure. jenkins.example.com reveals a CI/CD pipeline. old-api.example.com reveals a deprecated service that might still be running with known vulnerabilities.

For security professionals, subdomain enumeration is the first step in attack surface management. For investigators conducting due diligence, it reveals the true scope of a target's digital infrastructure. For compliance teams, it identifies shadow IT -- services deployed outside the visibility of the security team.

The methods below range from completely passive (no direct interaction with the target) to semi-active (standard DNS queries). All of them use publicly available data sources.

Method 1: Certificate Transparency Logs

Certificate Transparency (CT) is one of the most reliable sources for subdomain discovery. When an organization obtains a TLS certificate from a Certificate Authority, that certificate is logged in public CT logs. These logs are append-only, publicly auditable, and contain the exact domain names the certificate was issued for.

The key source here is crt.sh, a public interface to CT log data maintained by Sectigo. A single query to crt.sh for a domain returns every certificate ever issued for that domain and all of its subdomains.

CT logs are particularly valuable because they capture subdomains that may no longer resolve in DNS. A certificate issued for internal-api.example.com three years ago tells you that domain existed -- even if the DNS record has been removed, the server might still be accessible by IP address.

Method 2: Passive DNS Databases

Passive DNS works by recording DNS query/response pairs observed by sensors distributed across the internet. Unlike CT logs, which only capture domains with TLS certificates, passive DNS captures any domain that has been queried -- including HTTP-only services, internal redirects, and API endpoints.

Key passive DNS sources include SecurityTrails, VirusTotal, Farsight DNSDB, and RiskIQ. Each maintains its own network of sensors, so results vary between providers. For maximum coverage, query multiple sources.

The advantage of passive DNS over active DNS brute force is that it discovers domains you would never guess. Brute forcing relies on wordlists -- if the subdomain az2-prod-redis-cache.example.com is not in your wordlist, you will never find it. Passive DNS databases recorded it when someone queried it.

Method 3: DNS Brute Force Enumeration

DNS brute forcing works by resolving a wordlist of common subdomain names against the target domain. For each word in the list, a DNS query is sent for word.example.com. If the domain resolves to an IP address, it exists.

The effectiveness of brute forcing depends entirely on the quality of the wordlist. Generic wordlists (admin, api, dev, staging, www) catch the obvious ones. Specialized wordlists based on the target's technology stack or naming conventions catch more. Tools like subfinder and amass combine brute forcing with multiple data sources for comprehensive results.

The limitation: brute forcing is active -- it generates DNS queries that the target's DNS infrastructure can log. It is also incomplete by definition, since it cannot find subdomains not in the wordlist.

Method 4: Search Engine Dorking

Search engines index content, and content lives on subdomains. Google and Bing both support the site: operator, which restricts results to a specific domain or subdomain.

Search engine dorking is fully passive and reveals subdomains that host actual content. The results often include context -- page titles, snippets, and URLs that hint at the purpose of each subdomain. A result from status.example.com with a title of "System Status" tells you more than a DNS record alone.

Combine site: with other operators for targeted discovery: site:example.com filetype:pdf finds documents, site:example.com inurl:api finds API endpoints, and site:example.com intitle:"login" finds authentication portals.

Method 5: Web Scraping and Link Analysis

The target's own website often references its subdomains. JavaScript files may contain API endpoint URLs. HTML source may reference CDN subdomains, image servers, or external services. Sitemaps (sitemap.xml) and robots.txt files may list internal paths and subdomains.

Crawling the main website and extracting all URLs from the HTML source, JavaScript files, CSS files, and embedded resources can reveal subdomains that do not appear in any other data source. These are often the most interesting findings -- internal services referenced in client-side code that were never intended to be public.

Tools Comparison

The difference between raw enumeration tools and an intelligence platform like MAGO is context. Finding 200 subdomains is step one. Understanding which ones run outdated software, which have missing security headers, and which expose sensitive services -- that is where enumeration becomes intelligence. See What is Domain Intelligence for the full picture.

What a Subdomain Scan Reveals

Consider a typical medium-sized organization. A comprehensive subdomain scan might reveal:

• 50-100 active subdomains -- far more than the IT team expects
• Development and staging servers exposed to the internet with default credentials
• Legacy applications running outdated frameworks with known CVEs
• Third-party services (helpdesk, status page, analytics) configured as CNAME records
• Internal tools (Jenkins, Grafana, phpMyAdmin) accessible without VPN
• Dangling DNS records pointing to decommissioned cloud resources (subdomain takeover risk)

Each of these findings represents actionable intelligence. The staging server needs access controls. The legacy app needs patching or decommissioning. The dangling DNS records need cleanup before an attacker claims them.

Best Practices for Subdomain Enumeration

Combine multiple methods for maximum coverage. No single source captures everything. CT logs miss HTTP-only services. Passive DNS misses newly created domains. Brute forcing misses non-standard names. Search engines miss non-indexed content.

Run enumeration regularly, not once. New subdomains are created constantly -- every time a developer spins up a test environment, every time marketing launches a campaign microsite, every time a third-party vendor configures a service. Continuous monitoring catches these before attackers do.

Validate findings. A subdomain that resolves in DNS might not have an active web server. A certificate in CT logs might be revoked or expired. Enrichment -- checking HTTP response codes, security headers, TLS configuration, and technology fingerprinting -- separates noise from actionable findings.

Document everything. For compliance, legal, or incident response purposes, maintain a historical record of your subdomain inventory. Changes over time often reveal more than a single snapshot.