Subdomain Finder

What Is Subdomain Enumeration?

Subdomain enumeration is the process of finding all subdomains that belong to a domain. Every subdomain — staging.example.com, api-v2.example.com, jenkins.internal.example.com — is a potential entry point. Attackers use subdomain discovery as the first step of reconnaissance because forgotten or misconfigured subdomains are one of the easiest things to exploit.

A free subdomain finder online automates this process. Instead of guessing subdomain names, it queries public data sources that already know which subdomains exist. The most reliable source is Certificate Transparency logs — public records of every SSL/TLS certificate issued by trusted Certificate Authorities.

How Certificate Transparency Subdomain Discovery Works

Since 2018, every certificate issued by a publicly trusted CA must be logged to at least two CT logs before browsers accept it (RFC 9162). This creates a complete, searchable record of every subdomain that has ever had a certificate.

When you enter a domain into this subdomain finder, it queries the crt.sh database, which aggregates logs from Google Argon, Cloudflare Nimbus, DigiCert Yeti, and others. For each certificate, it extracts the Subject Alternative Names (SANs), the actual subdomain entries. After deduplication, you get a clean list of every subdomain with certificate history.

This is passive reconnaissance. No traffic is sent to the target domain, and the data is entirely public. That's why CT-based enumeration is the standard first step in both authorized penetration testing and bug bounty programs.

5 Methods for Finding Subdomains

CT log queries are the most reliable method, but security professionals combine multiple techniques:

This tool uses the CT log method. For deeper enumeration, tools like subfinder and Sublist3r combine multiple data sources in a single scan.

Using Subdomain Findings for Bug Bounty

Subdomain discovery is the most common first step in bug bounty recon. Here's what to look for once you have a subdomain list:

• Subdomain takeover — A subdomain points to a service (Heroku, S3, Azure) that's been deprovisioned. If you can claim that service, you control the subdomain. Check for CNAME records pointing to unclaimed resources.
• Exposed admin panels — Subdomains like admin.*, jenkins.*, grafana.*, or kibana.* often have weaker access controls than the main application.
• Staging and development servers — staging.*, dev.*, test.* environments frequently run with debug mode enabled, default credentials, or outdated software.
• API endpoints — api-v1.*, api-internal.* may expose deprecated or undocumented API versions without proper authentication.
• Forgotten services — Subdomains with old "Last Seen" dates in CT logs may be running unpatched software that nobody monitors.

Always ensure you have explicit authorization before testing discovered subdomains. CT log data is public, but interacting with the services requires permission.

What Is Subdomain Takeover?

Subdomain takeover happens when a subdomain's DNS record (usually a CNAME) points to an external service that no longer exists. If an attacker registers that service, they control the subdomain.

Common takeover targets include AWS S3 buckets, GitHub Pages, Heroku apps, Azure Blob Storage, and Shopify stores. The subdomain blog.example.com might CNAME to example.herokuapp.com — if that Heroku app was deleted but the DNS record wasn't removed, anyone can create a new Heroku app with that name and serve content under blog.example.com.

After running a subdomain scan, check each discovered subdomain's DNS records for dangling CNAMEs. Tools like subjack and can-i-take-over-xyz automate this check.

How the Tool Works

This subdomain finder never touches the target domain directly. Instead, I query three public data sources in parallel and merge the results into one deduplicated list. The whole scan is passive reconnaissance, which means no DNS lookups or HTTP probes hit the domain you are scanning.

Certificate Transparency (crt.sh and Certspotter)

Certificate Transparency is an IETF standard (RFC 9162) that requires every publicly trusted TLS certificate to be written to at least two append-only logs before browsers trust it. Every time a CA issues a certificate for api.example.com or internal-tools.example.com, the hostname becomes public record within seconds. That is the "leak" I exploit for discovery.

I query two CT aggregators. crt.sh is Sectigo's free search engine over the major CT logs; it returns JSON with the certificate's Common Name and every Subject Alternative Name. Certspotter is SSLMate's CT feed; its free tier lets me fall back when crt.sh is rate-limited or slow.

Passive DNS (Anubis)

Passive DNS is the practice of recording DNS answers seen on the wire by resolvers, then offering that history as a lookup service. It catches subdomains that never appeared in a certificate, such as HTTP-only dev hosts or services behind a wildcard cert. Anubis aggregates several passive DNS sources plus prior scan results, which fills gaps that pure CT data leaves behind.

Coverage from any single passive DNS source is incomplete, because resolvers only see what their users look up. Blending Anubis with CT data still misses subdomains no one has ever queried or certified, but it significantly reduces the gap.

Race-with-grace pattern

crt.sh is the richest source but also the slowest and flakiest. I run all sources in parallel and use a race-with-grace pattern: the fast sources (Certspotter, Anubis) set a floor for how long to wait, then crt.sh gets a short additional grace window (~2.5 seconds) to complete. If crt.sh misses the window, the scan returns with a warning rather than hanging.

Results are then deduplicated case-insensitively, wildcard entries are dropped, and the list is capped at 500 subdomains for performance. Dates and certificate counts come from whichever CT source saw the hostname.

Why I don't use active DNS brute-force

DNS brute-force tools like amass brute or puredns hammer a domain with tens of thousands of guesses to see which ones resolve. That approach has three real costs. It generates traffic against the target's authoritative DNS servers, it trips rate limits and telemetry, and it only finds names that happen to live on your wordlist.

This tool is built for anyone on the internet to scan any domain without coordination. Running active brute-force from a shared endpoint would be noisy, ethically questionable, and trivially abused. Passive-only keeps the tool safe to use against domains you don't own, such as potential acquisitions or scope-expanded bug bounty targets.

Data Sources

The scanner blends three public sources. Each one has different coverage, so using them together reduces the number of subdomains that slip through.

The redundant CT sources are deliberate. crt.sh and Certspotter read from the same underlying CT logs, but they index and surface certificates on different schedules, so a subdomain that shows up in one can be missing from the other on any given day. Keeping both sources gives the scan a better floor when either one is having a bad hour.

What You Can't Find

Passive discovery has real blind spots. Knowing what the tool won't find keeps you from treating its output as a complete inventory.

• No public certificate, no passive DNS record. A subdomain that only served HTTP and was only ever resolved by its own admins is invisible to every source I query. These are rare on modern infrastructure but still exist on legacy services.
• Split-horizon and internal-only subdomains. Names that resolve only inside a corporate network (jira.internal.example.com on a private DNS view) never reach the public resolver cloud. They won't show up here, and they shouldn't — the whole point of split-horizon is to keep them private.
• Very recent subdomains. CT logs ingest certificates within minutes to hours, but aggregators like crt.sh lag by a little longer. A subdomain certified in the last hour or two may not yet be searchable.
• Expired and revoked certs still show. CT logs are append-only by design. I still return hostnames whose certs expired or were revoked, because the subdomain itself often still exists (or still has a dangling DNS record). Use the "last seen" date in the results to decide whether to follow up.

If you need exhaustive coverage — for a security program, not casual recon — pair this tool with active techniques on domains you own: DNS zone review, authoritative log analysis, and brute-force with a large wordlist.

Common Use Cases

• Bug bounty recon. Subdomain enumeration is the first step of almost every recon methodology. Always stay inside the program's scope and follow responsible disclosure rules; if a subdomain is listed as out-of-scope, don't touch it even if the CT log surfaces it.
• Asset inventory for security teams. Enterprise infra sprawls across marketing sites, HR vendors, acquired companies, and SaaS integrations. A quarterly CT-based sweep catches subdomains that never made it into the CMDB.
• Due diligence on acquisitions. Before buying a company, scanning their domain tree reveals the real external footprint: forgotten staging environments, expired certs on exposed services, and third-party vendor subdomains that inherit your trust.
• Catching shadow IT. Teams spin up tableau.department.example.com or demo.example.com through corporate wildcard certs or public CAs. CT logs surface the certificate the moment it's issued, letting security find the asset before an attacker does.

API Access

I don't publish a public API for this tool. The backend endpoint exists (POST /api/subdomain-finder) but requires a rotating HMAC token minted by the page itself, plus origin and rate-limit checks, so it won't work outside the browser flow on appsecsanta.com.

For scripted or automated usage, query the upstream sources directly: crt.sh exposes a JSON mode (?output=json), and Certspotter's CT Search API supports programmatic access with a free token. To browse my catalog of manual-use security checkers, see the Tools page.

Related Tools

Subdomain discovery is step one. These companion tools help you assess whatever you uncover.

• Security Headers Checker. Once you have a list of live hosts, grade each one's HTTP security headers (CSP, HSTS, X-Frame-Options) to find the subdomains with the weakest browser-level defenses.
• DNS Security Checker. Inspect SPF, DKIM, DMARC, DNSSEC, and CAA records for any subdomain you find, so you can spot spoofable mail domains and missing DNS hardening.
• SSL Checker. Feed each discovered hostname into the SSL checker to see cert validity, cipher strength, and protocol support. This is how I find subdomains still serving TLS 1.0 or expired certs.
• DAST tools. For authorized dynamic scanning of the web apps behind discovered subdomains, use a dedicated DAST scanner that can handle auth flows and modern JavaScript.
• SAST tools. Pair subdomain recon with static analysis of the codebases that serve them — the two together give full asset-to-code coverage.
• Mobile security tools. Mobile apps often talk to API subdomains never meant to face the web. A mobile security scanner helps check what those endpoints actually accept.

Frequently Asked Questions

Is subdomain finder free?

Yes. This subdomain finder is free, with no signup, no ads, and no per-scan limits beyond a shared rate limit to keep the upstream data sources healthy. I pay for the hosting and the Certspotter tier out of pocket because I want the basic CT-based tooling to stay open to everyone.

How many subdomains can I find?

The tool returns up to 500 unique subdomains per scan, sorted alphabetically. That cap exists so the page stays snappy and the CSV export stays small; for most domains it's enough to see the full public footprint. Very large properties (hundreds of product lines, enterprise portals) will occasionally hit the ceiling — in that case, run the scan against a more specific host like eu.example.com.

Is it legal to find subdomains of someone else's domain?

Reading public Certificate Transparency logs and public passive DNS is legal in every jurisdiction I'm aware of. The data was put on the public record by Certificate Authorities and ISPs, and enumerating it sends zero traffic to the target. What changes the legal picture is what you do with the list.

Once you start probing the discovered services (running scans, trying logins, hitting APIs), you need authorization. For bug bounty, that means staying inside the program's scope. For your own estate, it means internal sign-off.

How often is data updated?

Certificate Transparency logs ingest within minutes of issuance, and crt.sh and Certspotter typically surface new certificates within a few hours. Anubis passive DNS refreshes on an irregular schedule driven by its upstream sources. Scan results are cached in Cloudflare KV for six hours, so rescanning the same domain within that window returns the cached list.

Can I find hidden or internal subdomains?

Not if they are truly internal. Split-horizon subdomains that only resolve on a corporate DNS server won't appear, and neither will subdomains that never got a public certificate or a public DNS query. What the tool does surface is the gray area — hosts an org considered "internal" but that got a public Let's Encrypt cert, or that ended up in a passive DNS record because someone accessed them from a home network.

What's the difference between subdomain finder and subdomain scanner?

The terms are used interchangeably online, but I draw a line between them. A subdomain finder (this tool) performs passive discovery — reading public records to list hostnames. A subdomain scanner actively probes each discovered host to check status, technology, open ports, or vulnerabilities.

For active scanning of discovered assets, use a dedicated DAST tool and get authorization first.

Does it find subdomains protected by Cloudflare?

Yes, because Cloudflare doesn't hide the hostname itself — it hides the origin IP behind it. A subdomain like app.example.com that sits behind Cloudflare still appears in CT logs the moment a certificate is issued (whether by Cloudflare's Universal SSL or the origin's own CA). What you won't get from any passive source is the origin server address, which is a separate recon problem.

How accurate is the data?

Accuracy depends on what you mean. For "does a certificate exist for this hostname", CT log data is definitive — every mainstream browser enforces CT, so anything with a public TLS cert since 2018 is in the logs. For "is this subdomain currently live", the answer is no: CT logs record issuance, not active hosting, so you'll see hostnames whose certs expired or whose DNS records were removed.

Use the "last seen" date as a freshness hint, and verify individual hosts with an SSL or DNS check before acting on the result.