find-hidden-subdomains

Find hidden subdomains

The hosts an organization forgot about are the ones worth finding, and most of
them announced themselves the moment someone requested a TLS certificate.
Certificate Transparency turns that into a searchable, permanent, historical
index — free and completely passive. The beginner's mistake is treating a CT hit
as a live host: most of what you pull back does not resolve, and that is
information too, not noise.

Which source first

You hold	Start with	Why
An apex domain	crt.sh wildcard query	Broadest free coverage, includes long-dead names
A domain behind a wildcard cert	Passive DNS, then archives	CT will only show you *.example.com
A guess at a naming convention	CT to learn the convention, then a wordlist	Learn the pattern before brute-forcing anything
An org name, not a domain	Certificate search by subject organization	Finds domains you did not know they owned
A cert you already have	Its SANs, then its serial and issuer	SANs give siblings; serial finds the exact cert elsewhere
A need for current hosts only	Resolve the candidate list	CT is historical by nature; DNS is the liveness oracle

How CT actually works

CAs submit every certificate they issue to append-only, cryptographically
verifiable public logs. The log returns a Signed Certificate Timestamp, and
mainstream browsers refuse to trust a publicly-trusted certificate that does not
carry SCTs from qualified logs. So participation is not voluntary: if the
certificate works in a browser, it is in the logs.

Three consequences that matter to you:

• Nothing is removed. Logs are append-only. A hostname that appeared in a
  cert five years ago is still there after the host is gone.
• You see precertificates and certificates. CAs log a precertificate first,
  then the final cert, so most names appear at least twice. Deduplicate.
• Only publicly-trusted certs are covered. A private/internal CA, a
  self-signed cert, or a Cloudflare origin certificate never reaches a log. CT is
  blind to those hosts entirely.

crt.sh

The web UI takes ?q=, where % is a wildcard, and output=json gives you
machine-readable results.

# every name ever seen in a cert covering example.com or a subdomain
curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' | sed 's/^\*\.//' | sort -u

# skip expired certs when you want a bias toward current infrastructure
curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].name_value'

# an identity search on an organization string, which finds unknown domains
curl -s 'https://crt.sh/?q=Example+Corporation&output=json' | jq -r '.[].name_value'

The q parameter is an identity search: it matches domain names, and it also
matches subject fields such as the organization name, which is how you find
domains the brief never mentioned.

Useful JSON fields: name_value (all names on the cert, newline-separated),
common_name, issuer_name, not_before / not_after, serial_number,
entry_timestamp, and id (open https://crt.sh/?id=<id> to read the cert).

crt.sh also exposes its database read-only over Postgres — host crt.sh, port
5432, user guest, database certwatch. That lets you write real SQL against
the certificate index instead of paginating JSON. It is a shared free service:
keep queries bounded and expect to be cut off if you hammer it.

Alternatives and other CT front-ends, with their coverage and access models, are
in reference/subdomain-sources.md.

The SAN field is the prize

Browsers ignore the Common Name; the subjectAltName extension holds the real
list of covered hostnames. Read it as a statement about what one team deployed
together:

• A cert with a handful of related names is an intentional grouping — those hosts
  belong to the same service and probably the same admin.
• A cert with dozens of unrelated names is a hosting provider's or CDN's bundled
  certificate. Those names are other customers, not your target's assets.
  This is the single biggest false-positive source in CT-based enumeration.
• Names from different registrable domains on one cert are the good find: it
  means one operator manages both, which surfaces acquisitions, rebrands and
  undisclosed sibling brands. Verify before concluding — see the bundling trap
  above.
• Internal names leak here constantly: jira, owa, vpn, *.corp.example.com,
  hostnames with rack or datacenter codes, and product codenames that never
  shipped publicly.

Wildcards hide, they don't reveal

*.example.com covers every subdomain and names none of them. An org that
switched to a wildcard, typically alongside DNS-01 ACME automation, effectively
went dark in CT from that point. When you see a wildcard:

• Mine CT for the period before the wildcard, when per-host certs existed.
• Move to passive DNS, which records answers rather than certificates.
• Check archives and search indexes for hostnames (read-deleted-pages,
  google-like-a-spy).
• Look for hosts that must still have their own cert for technical reasons: a
  deeper label than the wildcard covers (a.b.example.com needs its own), and
  anything on a different apex.

Combining sources, then resolving

CT gives you history. Passive DNS gives you observed reality. Wordlists give you
names nobody published. Use all three, and keep them labelled by origin, because
the confidence you can assign depends on where a name came from.

subfinder -d example.com -all -silent -o passive.txt   # aggregates many passive sources
amass enum -passive -d example.com                     # different source mix, slower
dnsx -l passive.txt -a -resp -silent                   # resolve candidates to A records

Resolution turns candidates into three buckets: resolves to an address, resolves
to a CNAME (read the target — it names the vendor, and a dangling one is a
takeover candidate to report), or does not resolve at all. Dead names are still
findings: they date the infrastructure, expose naming conventions, and sometimes
resolve again later.

Detect wildcard DNS before you trust any brute-force result. Resolve a
random name that cannot exist, such as zzq7x-nonexistent.example.com. If it
answers, the zone resolves everything and your entire brute-force list is
false positives.

Draw the line clearly: querying CT, passive DNS, search engines and archives
never touches the target. Resolving candidate names through a public recursive
resolver is effectively invisible but does generate lookups. Wordlist
brute-forcing is high-volume DNS traffic, visible to the target's DNS provider
and sometimes rate-limited or blocked. HTTP-probing the results with a tool like
httpx is active — you are connecting to the target's servers. Flag
brute-forcing and probing in your scope notes, and skip them if the engagement
is passive-only.

What a name pattern implies

Do not treat all discovered hosts as equal. dev, staging, uat, vpn,
legacy, old, and admin panels carry very different risk and follow-up than
www. The triage table is in
reference/name-pattern-triage.md.

Where this goes wrong

• Bundled and multi-tenant certs. Shared hosting and CDN certificates put
  unrelated customers on one cert. Always check whether the other names on a
  cert plausibly belong to your target before adopting them.
• CT is not an asset inventory. It is a record of certificate requests.
  Hosts behind internal CAs, self-signed certs, origin certificates, or plain
  HTTP are absent. Never report a CT-derived list as complete.
• Names outlive hosts. Most historical CT names are dead. A list of 400
  subdomains, unresolved, is a list of 400 unverified claims.
• Names outlive ownership. A cert issued for a hostname while the domain
  belonged to a previous owner still shows up under the current owner's query.
  Check not_before against the domain's registration and transfer history via
  who-owns-this-domain.
• CNAME'd third parties are not the target's assets. A hostname the target
  owns pointing at a SaaS tenant is the target's relationship, not its
  infrastructure. Do not treat vendor exposure as the target's exposure.
• Aggregators disagree, and quietly. Each tool queries a different set of
  sources; free tiers truncate results without telling you. Two tools returning
  the same 50 names may both be reading the same one source.
• Deliberate poisoning. Nothing stops anyone from getting a certificate for
  a name they control on a domain that looks like the target's. Typosquats show
  up in CT searches looking like the target's own hosts. Check the registrable
  domain character by character.

Confidence grading

• Confirmed asset — the name resolves, and it is under a domain whose
  registration you have verified, on infrastructure consistent with the target's
  other hosts (same ASN, same cert issuer, same naming convention).
• Probable asset — a CT name under a verified target domain that no longer
  resolves, or a name that resolves into a vendor's shared platform. Real name,
  unproven current state.
• Unconfirmed — a name from a cert bundled with unrelated customers, a
  brute-force hit in a wildcard-DNS zone, a name on a different registrable
  domain with no corroborating link, or an aggregator result you have not seen
  the underlying cert or DNS answer for.

Record for every host: where the name came from, the cert id or passive-DNS
source, the not_before date, and the resolution result with a timestamp.

Worked example

Target: example-health.test, scope is passive-only.

crt.sh with %25.example-health.test returns 61 unique names. Deduplicating
precert/cert pairs cuts it to 38. Three are interesting immediately:
vpn-uat.example-health.test, jira.internal.example-health.test, and
billing-legacy.example-health.test.

One cert carries 44 names across nine unrelated companies — a managed hosting
provider's bundle. Discard the 43 that are not the target's. That is the dead
end, and it would have inflated the report by more than the real findings.

Resolving the 38: 12 answer. jira.internal does not resolve publicly, but its
existence in a cert confirms an internal naming convention and a Jira instance —
worth noting even though there is no host to look at. vpn-uat resolves to an
appliance vendor's netblock, which goes to find-exposed-servers.

An identity search on the organization name from one of the certs returns two certs
for examplehealth-group.test, a domain nobody mentioned in the brief. WHOIS via
who-owns-this-domain shows the same registrant organization. That is the pivot
that expanded the engagement.

Grade: 12 resolving hosts confirmed, jira.internal probable (real name,
not publicly reachable), the sibling domain probable pending a corporate
filing.

Pivots

New selector	Goes to
Live hostnames and their IPs	find-exposed-servers
Sibling and acquired domains	who-owns-this-domain, who-really-owns-it
Organization name from a cert subject	x-ray-a-company
Dead hostnames with historical content	read-deleted-pages
Dev/staging hostnames, repo-looking names	secrets-in-git-history
Indexed files on newly found hosts	google-like-a-spy
A large host/domain/IP set to structure	graph-the-network

Legal and ToS notes

Reading CT logs and passive DNS is publishing-by-design: the data exists to be
read. Two limits are real. First, free services like crt.sh are shared
infrastructure — heavy automated querying gets you blocked and is discourteous;
use bounded queries and cache results. Second, DNS brute-forcing and HTTP probing
send traffic to the target and, depending on volume and jurisdiction, can be
argued as unauthorized activity; keep them inside written scope per
../../ETHICS.md. Discovering a dangling CNAME or an exposed
staging host obliges you to report it, not to test it.