May 2, 2026 · 8 min read · SubdomainReconAttack Surface

Free Subdomain Finder: How to Map Your Entire Attack Surface Before Attackers Do

Development servers, staging environments, old admin panels — your subdomains are an attack surface you probably didn't know you had. Here's how to find all of them, for free.

Your main website is locked down. HTTPS, security headers, patched software, maybe a WAF. Good. Now here's what attackers see when they look at you: your primary domain — and everything else you've forgotten about.

Subdomains are everywhere. The dev environment your agency spun up two years ago and forgot about. The staging server that has the same credentials as production. The legacy admin panel at admin.yourdomain.com that nobody uses but nobody deletes. Every one of them is a potential entry point. Most small businesses have no idea how many they have.

This is the recon step attackers run first. Let's do it before them.

Why Subdomains Are Attackers' Favorite Hunting Ground

The main domain gets attention. Security patches, monitoring, proper configuration — it all tends to happen on the primary domain. But subdomains are often forgotten:

Development and staging environments rarely get the same security treatment as production
Old subdomains from projects that ended often stay live with no monitoring
Third-party integrations and embedded tools get their own subdomains with minimal oversight
Cloud services (AWS, Azure, GCP) create subdomains automatically for infrastructure few people track

In 2021, a security researcher found that a Fortune 500 company's test environment at test.fortune500company.com was still connected to the same internal network as production. The subdomain had been sitting exposed for three years. This pattern is more common than you'd think.

How Subdomain Enumeration Actually Works

Attackers and security researchers use three primary techniques to find subdomains at scale:

1. Certificate Transparency Logs (fastest, most comprehensive)

Every publicly issued SSL certificate gets logged in the Certificate Transparency (CT) system. These logs are public and searchable. An attacker can query crt.sh or similar services to find every subdomain that had a certificate issued for it — including development domains, internal-sounding names, and forgotten infrastructure. This method alone often finds 2-10x more subdomains than the company knows about.

To do this yourself: go to crt.sh and search for your domain. Sort by date and look at everything issued in the last 12 months.

2. DNS Enumeration (brute-force approach)

Tools like Amass, Subfinder, or massdns can take common subdomain prefixes — dev, staging, test, admin, api, app, beta, uat, prod — and DNS-resolve them against your domain. If staging.yourdomain.com resolves to an IP, it's a live subdomain. This catches subdomains that were registered but never got certificates.

3. Web Archive and Search Engine Discovery

Wayback Machine, Censys, and SHODAN all expose subdomains that were live at some point. Sometimes you find infrastructure that no longer resolves via DNS but still exists in archived records — useful for finding long-abandoned subdomains that might still be accessible.

Free Tools for Subdomain Enumeration

Amass: The gold standard for passive subdomain enumeration. amass enum -passive -d yourdomain.com pulls from dozens of sources including CT logs, DNS records, and web archives. Free and runs in about 5 minutes.
Subfinder: Faster than Amass, focuses on passive sources. Good for quick enumeration: subfinder -d yourdomain.com
crt.sh: Direct Certificate Transparency search at crt.sh — no tool needed, just enter your domain
Assetfinder: A lightweight wrapper that runs Amass and Subfinder together. Simple: assetfinder yourdomain.com
EdgeIQ Subdomain Hunter: Browser-based option for quick checks without installing anything

What Attackers Do With the Subdomains They Find

The pattern: Find a forgotten staging server → notice it's running outdated software with known exploits → use it as a pivot point to access the internal network → laterally move to production database. This is the most common SMB breach chain, and it starts with one subdomain nobody remembered to secure.

Once attackers have a list of subdomains, they run automated scans against all of them looking for:

Default credentials on admin panels and internal tools
Outdated software with known CVEs
Misconfigured cloud storage (S3 buckets, open Azure blob storage)
Exposed git repositories (.git/config, /wp-admin on forgotten WordPress installs)
Internal API documentation left publicly accessible

What to Do Right Now

Run an Amass passive scan on your domain: amass enum -passive -d yourdomain.com
Also check crt.sh for your domain — note any subdomains you don't recognize
For every subdomain you find, ask: "Do we still use this? Who owns it? Is it patched and monitored?"
Any subdomain you can't account for — treat as a security risk until proven otherwise. Take it offline or bring it under the same security policy as your main domain.
If you have cloud infrastructure (AWS, GCP, Azure), audit all running instances and DNS entries — cloud consoles often expose things that DNS enumeration finds.

Every forgotten subdomain is a potential incident. Find them first.

Every forgotten subdomain is a potential entry point.

Find All Your Subdomains →