A PDF of every subdomain found: which names resolve, and which sites are live.
How It Works
Three searches run at once: two passive datasets, plus every hostname that ever got a certificate.
Names that still resolve are checked for a live website.
Overview
Most organizations cannot list the hostnames they own. Marketing stands up a
campaign site, a team ships a staging environment for one sprint, an acquisition
arrives with a domain nobody has audited. None of it is in the asset register,
and all of it is reachable.
This gives you the inventory: every subdomain three independent sources can find,
narrowed to the ones that resolve and answer. That resolved set is the input to
everything else you run, which is why it belongs on a schedule rather than in a
one-off audit. Run it weekly and the diff is the finding, because a host that
appeared since last run is the one nobody reviewed. It is the first step in
exposure management.
Three sources are used on purpose. subfinder and
amass query different passive datasets, and certificate
transparency catches hosts that were never in either, because a certificate was
issued whether or not anyone published the record.
Pipeline
Read the target domain.
subfinder and amass enumerate subdomains
from passive sources, in parallel.
A certificate transparency harvest pulls every hostname a CT log has seen for
the domain.
The three lists merge and deduplicate into one candidate set.
dnsx resolves each candidate and drops what does not exist.
httpx probes the survivors and records which answer over HTTP,
with their status and title.
The resolved inventory is written to a PDF report.
Inputs
Target domain. One apex per run, such as example.com. It ships with the
IANA example domain as the default, so an unedited run touches nothing you do
not own.
subfinder API keys. Optional config file. The passive sources work
without one, and adding keys widens the datasets subfinder can reach.
Source time caps. Subfinder is capped at 5 minutes and amass at 3, so one
slow source cannot hold the run open. Raise them when depth matters more than
wall clock.
Certificate transparency harvest. On by default and token-free. Nothing
to configure.
Outputs
Candidate hostname set. Every name the three sources returned, merged,
reduced to bare hostnames, and deduplicated.
Resolved inventory. The candidates that have an A record, which is the
set worth feeding to anything you run next.
Live host table. For each host that answers over HTTP, its status code,
title, server, resolved IP and detected technology.
PDF report. Stat cards, the live-host inventory and the full subdomain
inventory in one document, plus the HTML it was rendered from.
After the certificate transparency harvest merges in, the candidate set contains
hosts that are not on the target domain at all:
That is not a bug. A certificate covering several names puts all of them in the
log, so CT returns the neighbours a host shares a certificate with. It is also
useful: a shared certificate is evidence of shared infrastructure, and the
resolve step is what separates the two questions.
FAQ
How is this different from a one-shot subdomain lookup?
A single lookup queries one dataset and hands back a list of names. This queries
three independent sources, merges them, then resolves and probes what came back,
so what you keep is hosts that answer rather than names something saw once. On a
domain with a few years of history, most of a raw list is already dead, and the
gap between the two is the part you would otherwise check by hand.
Why use certificate transparency alongside passive DNS?
A certificate is issued whether or not anyone ever publishes a DNS record for
the name, so certificate transparency reaches hosts that are in no passive
dataset. It also returns the names a host shares a certificate with, which is
often how a second domain the same team owns turns up.
Why do names outside my domain appear in the results?
One certificate can cover several names, and the log returns all of them. Those
extras are evidence of shared infrastructure rather than noise, and the resolve
step keeps them separate from hosts you actually run.
Should I run this once or on a schedule?
On a schedule. The list is useful the first time, but the diff between runs is
the finding: a host that appeared this week is the one nobody has reviewed.
Does it send traffic to the target?
The three enumeration sources are passive. Only the resolve and probe steps
touch the target, and the probe is one HTTP request per host on ports 80 and
443.
Related workflows
Find Subdomain Takeovers. Reach for
this instead when you care less about which subdomains answer and more about
which of them point at services nobody owns.
Domain OSINT & Footprinting. Reach
for this instead when you want WHOIS, DNS and certificate history alongside
the names, without touching the target.