How to Find Your Exposed Subdomains Before Attackers Do
By ScruteX Published
Attackers map your subdomains before they touch anything else. It is the cheapest move in the whole attack chain: a handful of automated queries against public records returns every forgotten staging server, retired marketing microsite, and abandoned app that still points at your domain. Nobody notices, because none of it touches your infrastructure.
To find your exposed subdomains, combine passive discovery (certificate transparency logs, passive DNS, your own DNS records, code and app artifacts) with active enumeration (wordlist resolution and HTTP probing), then check every live host for its running service, certificate state, authentication, and dangling DNS records. Run it continuously, not once.
That is the short answer. The rest of this post is the operational detail: what each source actually returns, where each one goes blind, how to test for a subdomain takeover without breaking anything, and how to decide which of the 300 hosts you just found matters this week.
Why do exposed subdomains keep causing breaches?
A subdomain is any host published under your domain: app.example.com, staging.example.com, vpn.example.com. Each one is a doorway. The dangerous ones are the doorways nobody remembers building.
Forgotten subdomains share a pattern. They still resolve, so they are reachable. They are no longer maintained, so they run old software. They sit outside the patching program, outside the monitoring, and outside the asset register that your auditor asked for. That combination is what turns a marketing microsite from 2021 into an entry point in 2026.
The data supports the pattern.Data Breach Investigations Report found that exploitation of vulnerabilities rose 34% year over year and accounted for 20% of breaches. Internet-facing edge devices and VPNs made up 22% of the assets targeted through vulnerability exploitation, up from 3% the year before. The same report found organizations fully remediated only about 54% of those edge-device vulnerabilities across the year, taking a median of 32 days. Forgotten subdomains are exactly the class of internet-facing asset that sits inside that gap, because nobody assigned an owner to close it.
Attacker reconnaissance against DNS and certificate records is documented behavior, not speculation. MITRE ATT&CK catalogs it under Gather Victim Network Information: DNS (T1590.002), Search Open Technical Databases: Digital Certificates (T1596.003), and Active Scanning: Wordlist Scanning (T1595.003). Every technique in that list runs against public data or your public edge. You can run the same techniques against yourself, legally, today.
Step 1: What counts as "your" subdomains?
Scope first. Teams that skip this step enumerate one apex domain, find forty hosts, and declare the job done while the real exposure sits in a domain the marketing team registered for a product launch.
Build the scope from four sources:
- Every registered domain your organization owns. Pull the full portfolio from your registrar accounts, not from memory. Include country-code variants, campaign domains, and domains inherited through acquisitions.
- Subsidiary and acquisition domains. Acquired companies bring acquired attack surface. Their old staging environments become yours the day the deal closes.
- Vendor-hosted subdomains. CNAMEs pointing at SaaS platforms, CDNs, status pages, help centers, and email vendors are yours in the eyes of an attacker and your customers, even though the compute belongs to someone else. These are also where most takeovers happen.
- Development and partner zones. Internal-sounding zones (corp, internal, dev) that were published to public DNS at some point.
Write the scope down and get it approved. Active enumeration against a domain you do not own or have written authorization to test is not research. Passive discovery carries no such constraint, which is one reason to start there.
Step 2: How do you find subdomains passively?
Passive discovery reads public records and third-party archives. It sends nothing to your infrastructure, produces no logs on your side, and finds names that no wordlist would ever guess. It is what an attacker does on day one.
| Source | What it returns | Where it goes blind |
|---|---|---|
| Certificate transparency logs | Every host that ever had a publicly trusted TLS certificate, including internal-sounding names teams assumed were private | Hosts with no certificate, self-signed certificates, or coverage under a wildcard entry only |
| Passive DNS archives | Names that resolved historically, including retired records worth checking for dangling targets | Coverage depends on the provider's sensor network; absence is not proof |
| Your own authoritative DNS zones | The definitive list of what you publish, including records nobody remembers creating | Only covers zones you control; vendor-delegated zones sit elsewhere |
| SPF, DKIM, DMARC, and MX records | Third-party services authorized to act as your domain | Reveals vendor relationships, not always hostnames |
| Content Security Policy headers | Hosts your own applications trust and call at runtime | Application-specific, and only as accurate as the policy |
| JavaScript bundles, source maps, mobile app packages | Internal API hostnames developers hardcoded into shipped code | Needs manual review, and often returns the highest-value findings |
| Public code repositories and CI configuration | Staging URLs, internal endpoints, deployment targets committed by mistake | Frequently the finding you least want a stranger to make first |
| Search operators and web archives | Indexed pages on hosts your team has forgotten | Index coverage is partial and skews toward public content |
| ASN and IP range ownership with reverse DNS | Hosts running on netblocks registered to you | Cloud-hosted assets sit on shared provider ranges and will not appear |
Certificate transparency deserves particular attention. Since Chrome began requiring CT logging for publicly trusted certificates in April 2018, effectively every certificate your teams issue becomes a public record within hours. That is good for the web and inconvenient for anyone who assumed naming a host
internal-billing-api kept it quiet. It did not. It published it. Passive discovery routinely returns names the owning team swears do not exist. That is the point. Treat the output as leads, not as an inventory.
Step 3: How do you confirm which subdomains are live?
Active enumeration turns leads into an inventory. It probes, so it needs authorization and it will appear in logs.
Resolve everything first. Take every candidate name from Step 2 and check whether it resolves. Before you trust the results, test for wildcard DNS: query a random string like
zq7x9k2m.example.com. If it answers, the zone responds to everything and your brute-force output will be worthless until you filter for the wildcard's response fingerprint. Brute-force the gaps. Test common names against each zone using a wordlist: dev, test, uat, staging, admin, vpn, mail, git, jenkins, grafana, api, legacy, old, backup. Add permutations of names you already found, because infrastructure comes in families. If
api-eu-1 exists, try api-eu-2 and api-us-1. Probe for live services. Resolution proves a record exists. It does not prove anything is listening. Probe HTTP and HTTPS on common ports, capture status codes, redirect chains, page titles, and server headers. This is where a list of 900 names collapses into 140 live hosts and 12 that need attention today.
Feed the results back. Every live host presents a certificate, and that certificate's Subject Alternative Name field often lists siblings you missed. Harvest them and run the loop again. Two or three iterations usually exhausts the domain.
Check virtual hosts. Several sites frequently share one IP. A host that returns nothing on its IP directly may serve a full application when requested by name.
The specific tools matter less than the sequence. Discover, resolve, filter wildcards, probe, harvest certificates, repeat.
Step 4: What should you check on each subdomain?
A list of subdomains is not a finding. What each one runs is the finding. For every live host, capture:
| Check | What you are looking for |
|---|---|
| Service and version | Outdated frameworks, unpatched web servers, end-of-life software |
| HTTP status and redirect chain | Hosts that quietly redirect to third-party infrastructure |
| TLS certificate state | Expired, self-signed, mismatched names, or a certificate issued by a CA your organization does not use |
| Authentication | Admin panels, dashboards, and login pages reachable from the open internet |
| DNS target liveness | CNAME or NS records pointing at resources that no longer exist (see Step 5) |
| Intended exposure | Should this host be internet-facing at all? Staging almost never should be |
| Ownership | If no team claims it, it is orphaned, and orphaned assets do not get patched |
That last row is the one teams skip and regret. A finding without an owner becomes a ticket that ages out. Record the owning team at discovery time, while the context is fresh.
Step 5: What is a subdomain takeover and how do you test for one?
A subdomain takeover happens when a DNS record on your domain still points at a resource that has been decommissioned, leaving the target claimable by anyone. An attacker registers that resource on the provider, and your subdomain starts serving their content, on your brand, under a valid certificate.
Three variants show up in practice:
- Dangling CNAME. The most common.
promo.example.compoints at a cloud app or CDN endpoint that was deleted. The provider will hand that endpoint name to whoever asks next. - Dangling NS delegation. A zone was delegated to a nameserver or hosted zone that no longer holds the record set. Whoever recreates it controls the whole subtree.
- Expired domain in the chain. Your CNAME points at a third-party domain that lapsed. Someone re-registered it.
To test safely: resolve the full record chain for each subdomain, identify the final target and its provider, and check whether the target still exists. Providers return recognizable responses for unclaimed resources. That response, plus a live DNS record pointing at it, is your finding. Verify claimability on assets you own. Never claim a resource on a domain you do not control, and do not test third-party domains without written permission.
MITRE ATT&CK covers this behavior under Compromise Infrastructure: Domains (T1584.001), which explicitly includes hijacking subdomains through dangling DNS records. Adversaries do this because a trusted subdomain defeats the domain-based instincts you have spent years training into your staff and customers.
Step 6: How do you prioritize what you found?
Discovery produces volume. Volume produces paralysis. Rank findings by what an attacker can actually reach and use, not by raw CVSS, which describes a vulnerability in isolation and knows nothing about whether your host is reachable or the flaw is being weaponized this month.
A working model:
| Tier | Finding | Why it ranks here |
|---|---|---|
| Act now | Dangling DNS records with a claimable target | Zero-cost takeover, immediate brand and phishing impact |
| Act now | Internet-facing admin or VPN interfaces with known exploited flaws | Edge devices are where exploitation activity has concentrated |
| This week | Live hosts running end-of-life or unpatched software with public exploit code | Reachable and weaponized |
| This week | Staging or pre-production reachable from the internet | Weaker controls, real data, no monitoring |
| This month | Expired or mismatched certificates on live hosts | Erodes trust signals and often marks an unowned asset |
| Backlog | Live hosts, patched, authenticated, intentionally public | Track them, do not chase them |
This is the prioritization stage of a continuous exposure program. CTEM is a framework developed by Gartner, Inc. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates. Its five stages (scoping, discovery, prioritization, validation, mobilization) map onto exactly what this post walks through, and the two stages teams skip are validation and mobilization. Finding a dangling record is discovery. Confirming it is claimable is validation. Getting it deleted by a named owner with a deadline is mobilization. Only the third one reduces risk.
Scrutex handles this stage through Vulnerability Insights and its Exploit Context Layer, which enriches each finding with weaponization status, active campaign intelligence, and whether the asset is actually reachable. Threat Insights adds region and sector context, so an exposure that matches campaigns running against your industry in your geography rises above one that does not.
Step 7: How often should you scan for exposed subdomains?
Continuously. This is the step that decides whether the previous six were worth doing.
Subdomains appear constantly. A developer spins up a preview environment. Marketing launches a campaign host through an agency. A vendor provisions a portal on your domain. None of those events route through security. An annual discovery exercise misses eleven months of new exposure, and the exposure that causes the incident is almost always the one created after the last scan.
Continuous means three things in practice: rescan on a schedule measured in hours, diff each run against the last so you see what is new rather than re-reading the full inventory, and alert a named owner when something appears. Diffing is the part teams underestimate. Reading a 400-line report weekly is a task nobody completes. Reading "three new hosts since yesterday, one with an expired certificate" takes eleven seconds.
There is a regulatory edge to this as well. CERT-In's 2022 directions require certain cyber incidents to be reported within six hours of being noticed. NIS2 sets a 24-hour early warning for significant incidents in scope. APRA CPS 234 expects regulated Australian entities to maintain an information asset inventory and controls matched to criticality. You cannot report on, or defend, an asset that never made it into your inventory.
What most teams get wrong
Treating the list as the deliverable. A spreadsheet of 600 hostnames with no service data, no owner, and no priority is a document, not a control.
Enumerating one apex domain. Most organizations own more domains than their security team knows about. Scope from the registrar, not from memory.
Ignoring the vendor-hosted layer. Subdomains delegated to SaaS platforms are the ones most likely to dangle, because deprovisioning the service rarely triggers a DNS cleanup.
Assuming obscurity. Certificate transparency published your internal-sounding hostnames the moment you issued a certificate. Naming conventions are not a control.
Running it once. The single most common failure. A point-in-time scan describes a state that no longer exists by the time the report is circulated.
There is a fair counter-argument worth stating. Open-source enumeration chains are excellent, free, and used by professionals every day. Teams with engineering time to maintain wordlists, resolvers, diffing logic, and alert routing can build a strong discovery pipeline themselves, and many do. The trade is maintenance. A three-person security team that builds this pipeline now owns a pipeline. That is a real cost, and it is why the build-versus-buy answer differs honestly between a mature 40-person security function and a solo practitioner covering vulnerability management, compliance, and vendor risk before lunch.
Who this protects outside your company
The people who pay for a forgotten subdomain are usually not the people who forgot it.
When an attacker claims a dangling subdomain, they serve content from a hostname your customers have been trained to trust, with a valid certificate on your name in the address bar. Every piece of phishing advice you have given your users (check the domain, look for the padlock) fails at once. Credentials harvested there are real credentials, and they get reused elsewhere. That is the same exposure Scrutex tracks in Data Exposure Insights, where leaked credentials and stealer logs surface, often carrying internal hostnames that reveal yet more attack surface.
Cleaning up subdomain exposure is one of the few security tasks where the benefit reaches past your perimeter to the customer who never hears about it.
Where Scrutex fits
Scrutex runs external attack surface discovery continuously through Vulnerability Insights. Add your domain and brand keywords, and it enumerates subdomains, checks each for exposed services, open ports, expired certificates, outdated technologies, and dangling subdomains, then alerts you when something new appears. Findings are ranked by real-world exploitability rather than raw CVSS, so what reaches you is what an attacker could reach first.
The rest of the external picture connects to it. Brand Insights covers the inverse problem: lookalike domains and typosquats that you do not own but that impersonate you. Data Exposure Insights monitors dark web sources, paste sites, and breach corpora for credentials and source code tied to your domain. Threat Insights supplies curated CTI mapped to your region and sector. Vendor Insights extends the same posture scoring to third parties. Validation runs through continuous automated red teaming and on-demand automated penetration testing, with a human approving the plan before the AI pen testing agent executes it.
Setup is agentless. No software to install, no professional services engagement, no six-month rollout. Scrutex reports a 92% reduction in mean time to detect and a 48-hour median remediation time across its measured customer deployments, and monitors more than 1.2 million digital assets; these are Scrutex's own figures and individual results vary. All five core modules are available on the free tier with no credit card at platform.scrutex.ai/sign-up.
Key takeaways
- Attackers enumerate your subdomains first because it is cheap, quiet, and effective. Do it before they do.
- Scope from your registrar portfolio, not from memory. Include subsidiaries and vendor-hosted subdomains.
- Passive discovery (certificate transparency, passive DNS, code and app artifacts) finds names no wordlist will guess. Active enumeration confirms which are live.
- Dangling DNS records are the highest-severity finding in this whole exercise. They cost an attacker nothing and hand them your brand.
- Prioritize by real-world exploitability and reachability, not by raw CVSS score.
- A one-time scan is stale within days. Continuous discovery with diffing and owner alerts is the actual control.
FAQ
Q: How do I find all subdomains of my domain?
A: Combine passive discovery from certificate transparency logs, passive DNS, your own DNS zones, and code artifacts with active enumeration that resolves a wordlist and probes for live hosts. Passive methods find forgotten names; active methods confirm which are reachable. Harvest certificate SAN fields from live hosts and repeat the loop.
Q: What is a subdomain takeover?
A: A subdomain takeover happens when a DNS record still points at a decommissioned resource, letting an attacker claim that resource and serve their content from your trusted subdomain. The most common form is a dangling CNAME pointing at a deleted cloud or SaaS endpoint.
Q: Which subdomains are the biggest risk?
A: Hosts with dangling DNS records, internet-facing admin and VPN interfaces, and staging environments exposed to the public internet. These tend to be unpatched, unmonitored, and missing from the asset inventory, which is why they stay exploitable for months.
Q: Is subdomain enumeration legal?
A: Passive discovery reads public records and sends nothing to the target, so it carries no access constraint. Active enumeration probes infrastructure and should only run against domains you own or have written authorization to test.
Q: How often should I scan for exposed subdomains?
A: Continuously, with results diffed run over run. New subdomains appear whenever a developer, a marketing team, or a vendor provisions one, and none of those events route through security. Alert on what changed rather than reissuing the full inventory.
Q: Can attackers find subdomains I never made public?
A: Yes. If a host was ever issued a publicly trusted TLS certificate, its name is in the certificate transparency logs permanently. Internal-sounding names, staging hosts, and admin panels are all discoverable this way, and naming conventions offer no protection.