Subdomain finder. Passive CT-log discovery.
Type a root domain. We query Certificate Transparency logs via crt.sh and surface every unique sub-domain ever issued a public SSL cert. Passive — no scan packets at the target, no agent install.
Type a root domain. We query crt.sh for every cert ever issued to a sub-domain of it, then de-duplicate the SAN lists and surface the unique hostname list. This is passive recon — no scan traffic touches the target. The list is exactly what an attacker, an auditor, or a bug-bounty hunter would see in the public CT logs.
Apex only — we'll prepend the wildcard for you.
Large orgs return thousands of unique sub-domains. Query may take 5-15s.
// no query yet
Sources used
- crt.sh — Sectigo's public CT log aggregator
- RFC 6962 — Certificate Transparency standard
- certificate.transparency.dev — Google CT documentation
- OWASP Information Gathering — passive recon practice
No data is sent to Digital Heroes servers. Query goes from your browser directly to crt.sh.
Privacy: queries go to crt.sh only; Digital Heroes doesn't log.
Three signal classes in the list.
Real services. The interesting part of any list. api.example.com, admin.example.com, staging.example.com — these are running services with public certs. For an asset audit, every one of these is worth confirming you know what it is, who owns it, and whether it's patched. For an attack-surface review, they are the targets.
CI / CD ephemera. Modern platforms auto-issue certs for every preview, every branch, every deploy. Vercel issues for git-branch-name-team.vercel.app on every push. Netlify does the same. GitHub Pages issues for branch deploys. These are usually safe to ignore via the filter input — anything with a hex string, a UUID-like fragment, or "preview" / "deploy" / "branch" in the name.
Customer / tenant sub-domains. If the target is a SaaS, you'll often see a long list of {customer}.target.com entries — one per customer. Useful for understanding the customer base size, less useful for asset audit. Most SaaS platforms now issue wildcard certs to avoid this leak; older or self-hosted ones still expose the customer list.
Four jobs this tool covers.
Job 1: Attack surface inventory. Most security teams discover sub-domains they didn't know existed. The marketing team spun up a campaign sub-domain three years ago. A consultant launched a tool sub-domain that's still online. A vendor required a CNAME. Run this against your apex periodically and pipe the output to a CSV. Compare to the last quarter's list — the diff is your "things we didn't know about" list. Pair with our SSL Expiry Monitor by pasting the output directly.
Job 2: M&A due diligence. Before signing on an acquisition, run this against the target's apex. The list tells you the full surface area you are inheriting — every API, every legacy service, every customer-facing sub-domain. A target with 2,000 sub-domains and no inventory is a different integration project than one with 30 well-managed ones. Combine with our WHOIS Lookup on the apex for the corporate-record side.
Job 3: Brand impersonation monitoring. Run this against typo-squat domains (your-brand-name.io, your-brand.support, etc.). If they have any sub-domains with valid certs, someone is operating a service under your brand name on a domain you don't control. The list of sub-domains tells you what they are pretending to be — login pages, support portals, account portals. Common starting point for a UDRP or trademark complaint.
Job 4: Bug-bounty scope expansion. Programs that explicitly include "*.example.com" in scope are inviting you to test every sub-domain. CT-log enumeration is the standard first step of any program's recon. The list this tool produces is exactly what every bug-bounty hunter uses on their first day on a new program. It is also what they then feed into automated scanners to find the unloved corners of the surface area.
Six questions users ask.
How does CT-log enumeration work?
Every publicly-trusted SSL certificate issued since Chrome enforced Certificate Transparency in 2018 has been logged in append-only public ledgers. crt.sh aggregates all of them. When we query crt.sh for %.example.com, we get back every cert ever issued for any sub-domain of example.com — typically thousands of entries for an active organization. We de-duplicate the SAN lists and surface the unique hostname list. This is passive recon: no traffic touches the target's servers, only the public CT log aggregator.
Why use CT logs vs DNS brute force?
DNS brute force enumerates by guessing wordlists (api.example.com, admin.example.com, dev.example.com, …) and sending DNS queries until one resolves. It is loud (many packets at the DNS resolver, sometimes the target), slow (thousands of guesses), and misses anything not in the wordlist. CT-log enumeration is silent, fast, and finds every sub-domain that's ever been issued a public cert — including weird names you would never guess. The catch: it only finds sub-domains that have had a cert. Internal-only or never-cert'd hosts won't appear.
Is this legal?
Yes. CT logs are public by design — Google's CT framework was created precisely so anyone can audit cert issuance. Querying crt.sh is no different from running a Google search. The data is public, the protocol is public, and the use case (security audit, asset inventory, M&A diligence) is legitimate. The same data is used by every major bug-bounty program for asset discovery. We do not advise running this against organizations you have no business relationship with for purposes beyond research.
Why are some sub-domains weird-looking strings?
Two patterns: (1) auto-generated previews from CI/CD platforms — Vercel preview URLs like git-branch-name-team.vercel.app, Netlify deploy previews, GitHub Pages branch deploys; (2) wildcard expansion artefacts where the cert is *.example.com and crt.sh has indexed the wildcard literally. The filter input above the list lets you search-narrow to the meaningful names. Numeric / hex sub-strings are usually safe to ignore — they are CI ephemera, not real services.
What's the use case for asset discovery?
Three main jobs: (1) attack-surface audit — find sub-domains your security team didn't know about so you can triage their patching status; (2) M&A due diligence — see the full sub-domain footprint of a target before signing; (3) brand monitoring — find sub-domains using your brand name registered by impersonators (typo-squat domains often issue Let's Encrypt certs that show up in CT logs). For attack-surface continuous monitoring, pair with a service like Detectify or Censys; this tool is for the on-demand audit.
Does this tool log my queries?
No. The query is sent only from your browser to crt.sh. Nothing is logged on Digital Heroes servers. crt.sh is operated by Sectigo and follows their published privacy practices. There is no signup, no email field, and no analytics beacon that includes your query.