How to find exposed subdomains (and why they matter)

When someone probes an organization, they rarely start at the front door. They start by mapping your subdomains — because that's where the forgotten, half-finished and under-protected stuff lives: admin., dev., staging., jenkins., vpn., an old marketing microsite nobody patches. Your main site can be locked down while a staging box with default credentials sits wide open on a subdomain.

Why exposed subdomains are risky

• Unprotected internal tools. Admin panels, CI servers and dashboards that were "only going to be temporary."
• Weaker security posture. Dev/staging sites often skip the headers, auth and patching the main site has.
• Subdomain takeover. A subdomain pointing (via CNAME) at a de-provisioned cloud service can sometimes be claimed by an attacker and served as "you."
• Information leakage. Even just the names reveal your stack and internal structure.

How attackers find them (so you can too)

The easiest source is public and requires no scanning at all: Certificate Transparency (CT) logs. Every time anyone issues a TLS certificate, it's recorded in public logs. So every subdomain you've ever put HTTPS on is effectively listed.

• crt.sh — search %.yourdomain.com at crt.sh to see certificate-logged subdomains instantly.
• subfinder / amass — command-line tools that aggregate CT logs, DNS and other sources: subfinder -d yourdomain.com -silent.
• Search engines — site:yourdomain.com -www surfaces indexed subdomains.

The one-click way

If you'd rather not run tools, SurfaceWatch pulls your domain's subdomains from public certificate logs as part of its one-click check, and flags the ones that look like admin, dev or staging systems — so you see your exposed attack surface next to your headers, cookies and email security, in one grade.

What to do with a risky subdomain

For each one that shouldn't be publicly reachable:

1. Put it behind access control — a VPN, single sign-on, or IP allowlist.
2. Take it down if it's no longer needed, and remove its DNS record.
3. Fix dangling CNAMEs — if a subdomain points at a service you no longer use, delete the record to prevent takeover.
4. Bring survivors up to standard — the same headers, HTTPS and patching as your main site.

You can't protect what you can't see. Listing your own subdomains the way an attacker would is one of the highest-value things you can do in ten minutes — and it only has to find one forgotten box to be worth it. Only enumerate domains you own or are authorized to test.