Subdomain Finder

What Is Subdomain Enumeration?

Subdomain enumeration is the process of collecting candidate hostnames below a domain. A returned name — staging.example.com, api-v2.example.com, jenkins.internal.example.com — may expand the asset list, but it does not prove that the host resolves, is reachable, or is vulnerable.

A free subdomain finder online automates this process. Instead of guessing subdomain names, it can query public datasets for names they have observed. Certificate Transparency logs are one useful source: public, append-only ledgers of submitted certificates and precertificates.

How Certificate Transparency Subdomain Discovery Works

Browser CT policies can require Signed Certificate Timestamps from approved logs before accepting a publicly trusted certificate. CT makes submitted certificate metadata auditable, but a domain-search service is not a complete inventory of every hostname or currently deployed cert.

When you enter a domain, the checker queries crt.sh plus Cert Spotter, HackerTarget, and Anubis. It extracts returned names, removes wildcards and duplicates, filters them to the submitted domain, sorts them, and returns at most 500 rows.

AppSec Santa sends no DNS brute-force queries or HTTP probes to the submitted domain. It does send requests to four upstream discovery services, each with its own data collection and coverage limits.

5 Methods for Finding Subdomains

Different discovery methods expose different evidence and blind spots:

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

A subdomain list can provide leads during authorized bug-bounty recon. Treat each result as unverified until scope and current state are checked:

• 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.* may identify administrative interfaces. The hostname alone says nothing about their access controls.
• Staging and development servers — staging.*, dev.*, test.* names may identify non-production environments, but the label does not establish their configuration or exposure.
• API endpoints — api-v1.*, api-internal.* may identify API surfaces that need an authorized ownership and exposure check.
• Historical names — An old CT not_after value is not a last-reachability observation. Resolve and assess ownership separately.

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 the service lets another account claim the abandoned target, the record may allow that account to control the subdomain.

Takeover conditions are provider-specific and change over time. A dangling CNAME is a lead, not proof: the referenced resource must also be claimable under the provider's current behavior.

For authorized review, verify DNS records and provider-specific claimability without attempting to take control. The can-i-take-over-xyz project documents provider fingerprints and false-positive caveats.

How the Tool Works

AppSec Santa does not send DNS brute-force queries or HTTP probes to the submitted domain. I query four upstream services in parallel and merge their returned names into one deduplicated list.

Certificate Transparency (crt.sh and Cert Spotter)

Certificate Transparency is an IETF standard (RFC 9162) for public, append-only certificate logs. Browser policies can require evidence of CT logging for publicly trusted certificates, but CT search results are not a complete hostname inventory and do not prove current deployment or reachability.

I query two CT aggregators. crt.sh returns indexed certificate records in JSON, including Common Name and Subject Alternative Name fields when available. Cert Spotter supplies a second CT query. I use both results when available; the public endpoint can also return no data or fail.

Other public sources (HackerTarget and Anubis)

HackerTarget Hostsearch and Anubis can return names absent from the two CT queries. Anubis exposes a public subdomain lookup endpoint. This page does not independently verify either provider's collection method, freshness, or coverage.

Upstream-source results remain incomplete. A hostname can be missing because it was never observed, a source failed or timed out, cached data is stale, or the final 500-row cap excluded it.

Race-with-grace pattern

I start all four source queries together. The checker waits for Cert Spotter, HackerTarget, and Anubis, then allows crt.sh up to an additional 2.5 seconds. If crt.sh misses that window, other results can still return.

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.

I omit active brute-force because a shared public endpoint would create direct target traffic and abuse risk. Public discovery data still does not grant permission to probe the returned hosts.

Data Sources

The checker queries four public endpoints. Each may return incomplete, stale, unavailable, or overlapping data.

crt.sh and Cert Spotter are separate CT search services. Querying both can improve resilience when one is unavailable, but it does not guarantee complete coverage.

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 can be absent from every source I query.
• 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.
• Recent or unindexed names. A newly created hostname or certificate may not yet appear in an upstream search service.
• Expired and revoked certs still show. CT logs are append-only by design. I still return hostnames whose certs expired or were revoked. The displayed not_after value is not proof that the host remained reachable until that date.

For a security program, combine authorized public-source discovery with authoritative DNS or cloud inventory and other evidence appropriate to the environment. No single method guarantees exhaustive coverage.

Common Use Cases

• Bug bounty recon. Subdomain enumeration can support authorized reconnaissance. 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 comparison. Compare returned names with an authorized inventory to identify candidates for ownership and current-state verification.
• Due diligence on acquisitions. Before buying a company, public-source results can identify hostnames for ownership, scope, and current-state review. They are not a complete external footprint.
• Catching shadow IT. Teams spin up tableau.department.example.com or demo.example.com through corporate wildcard certs or public CAs. A matching CT record can surface a hostname, but not its owner, reachability, or security posture.

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 Cert Spotter's CT Search API supports programmatic access under its current terms. To browse my catalog of browser-based security checkers, see the homepage.

Related Tools

These companion pages cover selected follow-up checks. Confirm ownership, authorization, and current reachability before interacting with a host.

• Security Headers Checker. Inspect selected HTTP response headers, including CSP, HSTS, and X-Frame-Options. The check is not a complete browser-security review.
• DNS Security Checker. Inspect DNSSEC, SPF, DMARC, CAA, NS, SOA, MX, and the queried host's CNAME. The checker does not discover DKIM selectors or test every subdomain.
• SSL Checker. Check a public HTTPS response, redirects, HSTS, CT metadata, and a DANE/TLSA signal. It does not test live certificate chains, ciphers, or protocol versions.
• DAST tools. For authorized dynamic testing of web applications behind discovered hostnames, choose a DAST scanner whose documented coverage matches the application's authentication and client-side behavior.
• SAST tools. Pair subdomain recon with static analysis of codebases that are confirmed to serve them. The relationship still needs ownership and deployment evidence.
• Mobile security tools. Mobile apps may use separate API hostnames. Mobile testing can provide evidence about the client and its authorized endpoints.

Frequently Asked Questions

Is subdomain finder free?

Yes. It is free and requires no signup or user-supplied API key. The current shared limit is 15 checks per hour for each IP address, and each response contains at most 500 hostnames.

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 manageable. Reaching fewer than 500 results still does not mean the output is complete.

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

Public availability of discovery data does not answer every legal, contractual, or authorization question. Applicable rules depend on the jurisdiction, agreement, program scope, and subsequent activity.

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?

Freshness depends on each upstream service and is not guaranteed. Successful results are cached for six hours, so a repeat check during that period may return 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. Public records can still expose names that an organization intended for limited use. The tool cannot determine whether a returned name is truly internal, public, owned, or reachable.

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?

It can, if one of the queried sources returns the hostname. Reverse proxying does not guarantee that a name appears in CT search results, and this checker does not attempt to identify the origin server.

How accurate is the data?

Results are discovery leads, not a complete or current inventory. CT data records submitted certificate metadata rather than active hosting, while the other sources have their own unknown coverage and freshness limits.

The displayed "last seen" value is a certificate not_after date, not a reachability observation. Verify ownership, scope, DNS, and service state separately before acting.