By Xhield Team · June 23, 2026 · 10 min read
An attacker opens a browser tab
They type your primary domain into a free, publicly available tool. Within 30 seconds, they have a list of 47 subdomains — including a developer portal, a forgotten staging environment, and an internal HR tool that was briefly internet-facing three years ago.
Your security team's CMDB lists 6 subdomains. The attacker now knows about 41 more.
This isn't a hypothetical. Subdomain enumeration is one of the first steps in any offensive reconnaissance, and it's one of the most consistently underestimated gaps in how enterprises understand their own attack surface. Every technique an attacker uses is passive, free, and leaves almost no trace on your systems.
This post covers the full playbook — every technique, every tool, and what attackers do once they've built the list. And at the end, a defender checklist to run this against yourself before your next VAPT engagement.
1. Why subdomains are a prime attack vector
Subdomains are treated differently from the primary domain — less scrutiny, weaker security controls, longer patch cycles, and in many cases, no monitoring at all. They exist in a middle ground between "official infrastructure" and "something someone set up for a project."
They accumulate fast and decay slowly. Every new product line, marketing campaign, regional site, acquired brand, internal API endpoint, or developer environment tends to get its own subdomain. Few organisations have a reliable process for decommissioning them when the project ends. The result: a growing tail of live subdomains that nobody is actively managing.
Attackers specifically look for patterns that suggest weaker controls:
dev.andstaging.— development environments with fewer access controls and often real dataadmin.andportal.— management interfaces, frequently with different authentication than productionapi.— often exposes endpoints not intended for public consumptionvpn.andremote.— access infrastructure, high-value targets for credential attackslegacy.andold.— decommissioned applications still running, rarely patchedinternal.— tools that were never supposed to be public-facing at all
Each of these naming patterns carries a distinct set of likely vulnerabilities. An attacker who finds staging-payments.companyname.com resolving to a live server knows exactly where to look next.
There is also a specific subdomain risk worth calling out separately: subdomain takeover. This occurs when a subdomain's DNS record still points to a third-party service — an S3 bucket, a GitHub Pages site, a Heroku app — that the organisation no longer controls. An attacker who claims that service takes ownership of the subdomain entirely, gaining a trusted domain to serve phishing pages or malware from.
2. Technique 1 — certificate transparency logs
In 2018, browsers began requiring all TLS certificates to be logged in public Certificate Transparency (CT) logs before they would be trusted. The intention was to prevent fraudulent certificate issuance. The side effect: every subdomain that has ever had HTTPS enabled is now permanently and publicly recorded.
This is one of the most powerful passive reconnaissance techniques available, and it requires nothing more than a browser.
Tool: crt.sh
Query %.companyname.com on crt.sh and the full historical subdomain list appears immediately — every subdomain that has ever had a certificate issued against your domain, including wildcard certificates that reveal naming conventions, certificates issued for acquired entities, and certificates from years ago for services that no longer exist.
What makes this particularly impactful for attackers is what it reveals that the organisation itself may have forgotten: a subdomain from a product that was discontinued, a certificate issued during a brief cloud migration that was later reversed, a subdomain belonging to a company acquired three years ago whose infrastructure was never fully absorbed.
Defender action: Query crt.sh against your own primary domain and every subsidiary domain right now. Every result is exactly what an attacker sees. Flag anything the team does not immediately recognise — those are the entries worth investigating first.
3. Technique 2 — passive DNS and historical records
Passive DNS databases record every DNS resolution observed across the internet over time. Unlike CT logs, which only capture subdomains that had certificates issued, passive DNS captures anything that ever resolved — including HTTP-only subdomains, internal tools briefly exposed, and infrastructure that predates widespread HTTPS adoption.
Even subdomains that were active for a matter of weeks years ago leave a trace in passive DNS. An attacker uses this to build the most complete picture possible of what has ever existed in an organisation's DNS namespace.
Key tools in this category:
SecurityTrails provides historical DNS records, current A/MX/NS resolution data, and subdomain discovery across a broad dataset. The free tier covers basic subdomain lookups; the paid tier adds historical depth and bulk queries.
Shodan crawls the internet continuously and indexes what's running on IP addresses. Cross-referencing Shodan results against an IP range reveals subdomains through reverse IP lookups — finding subdomains that share hosting with known assets.
VirusTotal aggregates passive DNS data from multiple sources and offers strong historical depth. Useful as a cross-check against SecurityTrails results, and particularly good at surfacing subdomains that appear in malware reports or threat intelligence feeds.
Censys provides enterprise-grade internet scan data with broader coverage than free tools. The combination of certificate data, banner grabbing, and passive DNS makes it the most comprehensive passive source available.
4. Technique 3 — brute-force and wordlist-based enumeration
Unlike the passive techniques above, brute-force subdomain enumeration is active: it systematically tests whether common subdomain patterns exist by attempting DNS resolution against a large wordlist. api.companyname.com, dev.companyname.com, blog.companyname.com, uat.companyname.com — and thousands more — each queried in rapid succession.
This is the only technique in the subdomain enumeration playbook that generates traffic to the target's DNS infrastructure — but in practice, most organisations don't monitor external DNS query volume, so it rarely triggers alerts.
The four tools that define this technique:
Amass (OWASP project) is the most comprehensive subdomain enumeration tool available. It combines brute-force wordlist testing, passive DNS sources, certificate transparency data, and web scraping into a single enumeration engine. A full Amass run against a target typically returns significantly more subdomains than any single passive technique alone.
Subfinder takes a passive-only approach, aggregating results from over 40 data sources without making any active probing attempts. It is exceptionally fast and produces no footprint on the target. Used by both attackers wanting to stay quiet and defenders doing continuous discovery.
dnsx handles DNS resolution at scale — it validates which of the discovered subdomains actually resolve to live hosts, filtering out dead entries and returning the actionable list. Typically used after Amass or Subfinder to clean up results.
MassDNS is a high-performance DNS resolver built for scale. It can check millions of potential subdomain permutations in minutes by parallelising DNS queries across multiple resolvers.
Wordlist quality matters as much as tool choice. The most effective attackers don't use generic wordlists — they build context-specific lists from the organisation's naming conventions, known technology stack patterns, industry-standard naming (common in fintech, healthcare, and SaaS), and variations observed in CT log results. A company that names one subdomain payments-api-v2 is likely to have others following the same pattern.
5. Technique 4 — web crawling, scraping, and public source mining
Beyond DNS-based techniques, subdomains surface in a surprising number of public sources that most organisations never audit.
JavaScript files in the primary site frequently reference internal API endpoints, staging URLs, and subdomains used for assets, analytics, or feature flags. These are visible in any browser's developer tools, no special access required.
The Wayback Machine (web.archive.org) holds historical snapshots of websites going back decades. Links to subdomains that existed years ago — including ones that were public by mistake for a brief period — appear in these snapshots and remain discoverable long after the subdomain itself has been taken down.
Google dorks extend this further: site:*.companyname.com returns every subdomain Google has ever crawled and indexed. Any subdomain that was publicly accessible long enough for a search engine crawler to visit it appears here.
GitHub and public code repositories are consistently the most overlooked source. Developer comments, configuration files, CI/CD pipeline scripts, environment variable examples, and API documentation in public repositories frequently contain internal subdomain URLs, S3 bucket names, and endpoint references that were never meant to be public.
Job postings and technical documentation complete the picture. A job description referencing a specific internal tool, a public API docs page that names the staging endpoint, a conference talk slide deck that shows a screenshot of an internal dashboard URL — all of these are indexed, searchable, and available to anyone who looks.
6. What attackers do with the list — from enumeration to exploitation
Once a complete subdomain list is built, the next phase begins: each subdomain is probed for what's running on it, whether authentication is required, what software version is exposed, and whether any known vulnerabilities apply.
The first automated check most attackers run is technology fingerprinting — tools like httpx and whatweb hit each subdomain and return the web server, framework, CMS, and response headers. This takes seconds per subdomain and immediately identifies the highest-value targets.
Subdomain takeover is checked simultaneously. For every subdomain in the list, the DNS record is checked to see whether it points to a third-party service the organisation no longer controls. A CNAME pointing to an unclaimed S3 bucket, an expired Heroku app, or a decommissioned GitHub Pages site is an immediate takeover opportunity — the attacker simply claims the third-party service and inherits the subdomain.
Priority targeting then narrows the list. Attackers focus effort on admin., vpn., api., and dev. subdomains first, because they are statistically more likely to have weaker access controls, higher-privilege functionality, or real data. A forgotten staging environment running an older, unpatched version of the production application is often the easiest path into a well-defended production system.
The connection to VAPT scope is direct: this entire process takes under an hour. If none of these subdomains are in your VAPT scope document, none of this exposure gets tested. When a breach eventually occurs through one of them, the post-incident review will find that the subdomain existed, was discoverable, and had been sitting exposed for months or years before anyone looked.
7. How to run this against yourself — and what to do with the results
The most effective thing a security team can do before any VAPT engagement is run the attacker's subdomain enumeration playbook against their own domain. Here is the five-step process:
Step 1 — Certificate transparency first. Query %.companyname.com on crt.sh and repeat for every subsidiary and acquired brand domain. Export the full list. Flag anything the team does not immediately recognise — those entries deserve investigation before anything else.
Step 2 — Layer in passive DNS. Cross-check your crt.sh results against SecurityTrails and VirusTotal. Subdomains that appear in passive DNS but not in CT logs are particularly interesting — they may predate HTTPS adoption or may never have had a valid certificate, which itself is a security concern.
Step 3 — Run Subfinder or Amass. Compare tool results against what passive sources returned. Any gap — subdomains the tools find that aren't in passive DNS, or vice versa — is worth investigating. Amass in passive mode is a good starting point; save active brute-forcing for when you want maximum coverage.
Step 4 — Check every live subdomain for dangling DNS. For each subdomain that resolves, verify that the DNS record points to infrastructure your organisation actively controls. Any CNAME pointing to a third-party service should be immediately reviewed — if that service can be claimed by a third party, it is a takeover risk and a remediation priority.
Step 5 — Update your VAPT scope. Every live, organisation-controlled subdomain discovered through this process belongs in your next VAPT scope document. The scope should be built from what is actually there — not from memory, not from a CMDB last updated eighteen months ago.
Doing this once before a VAPT engagement is valuable. Doing it continuously — so that new subdomains are discovered and added to scope as they're provisioned, and decommissioned ones are flagged when their DNS records go stale — is what closes the gap permanently.
Know your subdomain footprint before an attacker does. Start with xhield →
Related reading: