Subdomain Discovery

Find active subdomains for a given domain by checking common naming patterns and DNS records.

Evidence ASSESSED

Checked against: Passive subdomain sources via rapiddns.io

RED TEAM 0 findings BLUE TEAM control did not hold

How It Works

Subdomain discovery is the process of finding sub-domains of a target domain to map its attack surface or architecture:

Brute-force: We check a list of common subdomains (like dev, blog, api) and verify if they have DNS records.
Infrastructure Mapping: Helps identify forgotten staging servers or shadow IT resources.
Security Auditing: Subdomains are often less secured than the main domain, making them high-value targets for testing.

Our Subdomain Discovery tool enumerates the subdomains of any domain using certificate transparency logs and DNS resolution. Most organisations have more subdomains than they realise, and the forgotten ones are where attackers look first.

What is Subdomain Discovery?

Subdomain discovery finds the hostnames that exist beneath a domain. There is no way to ask DNS for a list — the protocol provides no such query — so enumeration relies on indirect sources.

Certificate transparency logs are the most productive. Every publicly trusted certificate issued since 2018 must be logged, and those logs are searchable, so any subdomain that has ever had a certificate is discoverable. Wildcard certificates hide individual names, but most organisations issue per-host certificates somewhere.

Other sources include wordlist-based resolution, passive DNS collected by resolvers, and search engine indexes. None is complete, and combining them produces a better picture than any one alone.

DNS provides no way to list subdomains directly
Certificate transparency logs are the richest source
Every public certificate since 2018 is publicly logged
Wordlist resolution finds names that never had certificates
No single method is complete

Why Subdomain Discovery Matters

Subdomains accumulate. A staging environment for a project that shipped two years ago, a marketing microsite from a campaign that ended, an old admin panel replaced but never decommissioned — each remains reachable, running software nobody has updated since it was deployed.

Attackers enumerate subdomains as a first step precisely because this is so reliably productive. A well-defended main application is often adjacent to a forgotten subdomain running an unpatched framework, and that is the way in. Dangling DNS records pointing at deprovisioned services are a related and equally common finding.

Forgotten subdomains run software nobody has updated
Staging and development environments are typically less hardened
Dangling records enable subdomain takeover
Attackers enumerate subdomains as a standard first step
You cannot secure infrastructure you do not know exists

How This Subdomain Discovery Works

The tool queries certificate transparency logs and verifies which discovered names resolve.

Validates the domain input against format and SSRF safety checks
Queries certificate transparency logs for certificates naming the domain
Extracts every subdomain appearing in those certificates
Resolves each discovered name to determine whether it is currently active
Reports the results, distinguishing resolving names from historical ones

How to Use Subdomain Discovery

Enter a domain you own or are authorised to assess
Run the discovery to query certificate transparency and resolve results
Review the list for hostnames you do not recognise
Pay particular attention to names suggesting staging, development or administration
Investigate anything unexpected rather than assuming it is inactive

Understanding Your Subdomain Discovery Results

Discovered names fall into several categories worth treating differently:

Field / Value	Meaning
`Active subdomain`	Resolves to an address and is presumably serving something. Every one is attack surface that should correspond to a system you know about.
`Historical only`	Appears in certificate logs but no longer resolves. Usually decommissioned, though the certificate record remains public permanently.
`Staging or dev`	Names containing dev, staging, test, uat or qa. These are typically less hardened, run older code, and frequently expose debug interfaces or test credentials.
`Administrative`	Names such as admin, panel, portal or vpn. High-value targets that should be restricted by source address or behind authentication at the network level.
`Dangling record`	Resolves to a CNAME target that no longer exists. A direct subdomain takeover risk requiring immediate removal.
`Wildcard certificate`	A certificate for *.example.com hides the individual names it covers. Its presence means certificate transparency will under-report your actual subdomain inventory.
`Third-party service`	Points at an external platform. Each represents a dependency on infrastructure you do not control and should be reviewed periodically.

Common Problems & How to Fix Them

This is the normal and expected outcome, and it is the point of running the exercise.

Build an inventory. For each name, establish what it is, who owns it, whether it is still needed, and what software it runs. Decommission what is obsolete — removing the DNS record first, then the service — and bring the rest under patching and monitoring.

Non-production systems typically run older code, have weaker credentials, and sometimes expose debug endpoints or copies of production data.

Restrict them by source address, put them behind a VPN, or at minimum add HTTP authentication. Ensure they carry a noindex directive so they do not appear in search results, and never load production data into them.

A subdomain pointing at a deprovisioned service is a direct takeover risk. On many platforms an attacker can claim the unused target and serve their own content on your subdomain, harvest cookies scoped to your domain, and obtain a valid certificate in your name.

Delete the DNS record immediately, then audit the rest of the zone for other aliases pointing at services you no longer use.

Certificate transparency cannot reveal names covered by a wildcard, so the discovered list will be incomplete.

Supplement with wordlist-based resolution, passive DNS data, and your own DNS zone export. Reviewing the zone file directly is the only complete source, and it is available to you even though it is not available to an attacker.

Certificates are sometimes issued for names that were planned but never deployed, or for internal names that were never public.

Note that certificate transparency records are permanent and public, so an internal hostname that appeared in a certificate is disclosed forever. Avoid putting internal naming into publicly trusted certificates.

Best Practices

Enumerate your own subdomains regularly, not just during assessments
Maintain an inventory recording owner, purpose and software for each
Remove the DNS record before decommissioning the service it points at
Restrict staging and development environments by source address
Avoid putting internal hostnames into publicly trusted certificates
Review third-party service subdomains periodically for continued need
Combine certificate transparency with your own zone export for completeness

Security Recommendations

Treat every discovered subdomain as attack surface until confirmed otherwise
Scan specifically for dangling records, since takeover is both easy and high impact
Restrict which subdomains carry authentication cookies so a takeover of one cannot compromise the main application
Remember certificate transparency is public and permanent — attackers see the same list you do
Prioritise staging and administrative subdomains, which are both more valuable and typically less defended
Only enumerate domains you own or are explicitly authorised to assess

Frequently Asked Questions

DNS provides no way to list subdomains, so enumeration uses indirect sources. Certificate transparency logs are the most productive, since every publicly trusted certificate issued since 2018 is logged and searchable.

Certificate transparency logs are public by design — the transparency requirement that lets you detect mis-issued certificates also lets anyone enumerate the names you have obtained certificates for. The visibility cuts both ways.

One whose DNS record points at a service that no longer exists, typically a deprovisioned cloud resource. On many platforms an attacker can claim that target and serve content on your subdomain, which is called subdomain takeover.

From certificate transparency, largely yes — a certificate for *.example.com does not name the individual hosts. It does not hide them from DNS-based enumeration or passive DNS, so it reduces rather than eliminates discoverability.

Regularly, and certainly after any significant infrastructure change. Subdomains accumulate through normal project work, and an inventory that is a year old will be missing things.

Querying public certificate transparency logs is simply reading public data. Actively resolving and probing third-party infrastructure without authorisation is a different matter and may be unlawful. Only assess domains you own or have permission to test.

Remove the DNS record first, then decommission the service. Doing it in that order prevents a window where the record points at a deprovisioned resource that someone else could claim.