What Is Subdomain Enumeration and Why Does It Matter for Security?

Why Subdomains Matter to Attackers

When an attacker targets an organisation, they do not start with the main website. They start by mapping everything: every subdomain, every IP address, every service. Subdomain enumeration is the process of discovering all of the subdomains that exist under a target domain — and it is typically the first step in any serious reconnaissance phase.

The reason this matters is simple: the main website at `example.com` is almost always the best-maintained part of an organisation's web presence. It gets updates, monitoring, and attention. The subdomains — `staging.example.com`, `old.example.com`, `api.example.com`, `dev-portal.example.com`, `legacy.example.com` — often do not. They accumulate over years as services are stood up for projects, acquired companies, or development environments, and then forgotten when the project ends. The underlying infrastructure may still be running an unpatched version of a framework from three years ago.

How Subdomain Enumeration Works

Attackers use several techniques to discover subdomains, most of which require no special access:

**Certificate Transparency logs** — Every SSL certificate issued for a subdomain is publicly logged in Certificate Transparency (CT) logs, which are searchable. A simple query to [crt.sh](https://crt.sh) for a domain returns every certificate ever issued — which means every subdomain that ever had HTTPS configured. This is the single most reliable passive enumeration technique and requires no interaction with the target.

**DNS brute force** — Tools iterate through wordlists of common subdomain names (`www`, `mail`, `api`, `staging`, `dev`, `admin`, `portal`, `login`, `app`, and thousands more) and send DNS queries for each. Any that resolve to an IP address are valid subdomains. Modern wordlists contain millions of entries.

**Public search engines and web archives** — Google dorking (`site:example.com`) returns indexed subdomains. The Wayback Machine at web.archive.org has crawled content from subdomains that may no longer be publicly linked but still exist.

**DNS zone transfers** — If a DNS server is misconfigured to allow zone transfers to any IP address (rather than only to authorised secondary DNS servers), a single query returns the entire zone file — every subdomain in one response. Zone transfer misconfiguration is less common than it used to be but still appears.

**Passive DNS databases** — Services like SecurityTrails, Shodan, and VirusTotal maintain passive DNS databases accumulated from internet-wide scanning. These record DNS resolutions observed historically, revealing subdomains that existed even if DNS records have since been removed.

What Attackers Find

Forgotten staging and development environments

Staging environments are built to test new features before deployment to production. They often run the same application code but with weaker configuration: debug mode enabled, stack traces exposed, less restrictive authentication, or older versions of dependencies. A staging environment at `staging.example.com` that is reachable from the internet and protected only by HTTP basic authentication (or not protected at all) is a common finding.

Legacy applications

Applications built and deployed years ago may be running on outdated frameworks with known CVEs. If they are no longer actively used, they receive no security updates — but if the subdomain still resolves and the server still responds, they are part of the attack surface.

Admin panels

Internal tools deployed to subdomains — monitoring dashboards, admin panels, CI/CD interfaces, database management tools — are sometimes made internet-accessible during setup and never locked down. `grafana.example.com`, `jenkins.example.com`, `kibana.example.com` on a public IP with default credentials is a finding that appears in penetration tests with some regularity.

Subdomain takeover opportunities

When a subdomain points to a third-party service — a GitHub Pages site, a Heroku app, an S3 bucket, a Netlify deployment — but the service configuration has been removed, the DNS record becomes dangling. An attacker can claim the service (for example, by creating a new GitHub Pages site for the same repository) and serve content from your subdomain. This is subdomain takeover, covered in depth at [what is subdomain takeover](/blog/what-is-subdomain-takeover). From the visitor's perspective, the content appears on your domain with your SSL certificate.

Defensive Enumeration

Running subdomain enumeration against your own domain is a legitimate and valuable activity. Knowing what subdomains exist — and which of them should exist — is the prerequisite for reducing your attack surface.

The practical process:

1. Run a CT log search (crt.sh for your domain) and export every subdomain ever certificated 2. Run a DNS brute force using a comprehensive wordlist 3. For each discovered subdomain: determine whether it should exist, who owns it, and whether it is still actively maintained 4. For subdomains that should not be public, add network-level access controls 5. For subdomains pointing to third-party services that are no longer configured, remove the DNS record immediately to prevent subdomain takeover 6. Maintain an inventory going forward — add subdomain discovery to your change management process so new subdomains are documented when created

Automated monitoring tools can alert you when new subdomains appear in CT logs for your domain, giving you near-real-time visibility into changes.

Yrzo AI's security assessment includes subdomain enumeration as part of attack surface discovery, identifying subdomains present in CT logs and checking each for common misconfigurations. From yrzoai.dev.