Your organization probably has more subdomains than you realize. Beyond your primary domain and the handful of subdomains you intentionally created, there are likely dozens of forgotten subdomains from old projects, abandoned integrations, test environments, and shadow IT. Each subdomain is a potential entry point for attackers. Many organizations experience breaches not through their primary application, but through an unpatched test environment or forgotten integration that was never meant to be production-facing but never got taken down. This guide walks through subdomain enumeration techniques attackers use, how to inventory your actual attack surface, and how to eliminate or properly secure forgotten subdomains that shouldn't exist.
Understanding Your Subdomain Attack Surface
A subdomain is a domain like api.yourcompany.com, staging.yourcompany.com, or mail.yourcompany.com. Unlike files and directories on your main website (which you control), subdomains are separately configured. Each can point to different servers, be hosted by different providers, and have different security controls. A forgotten staging environment with weak password authentication is an attacker target. An abandoned integration endpoint with default credentials is a way in. A test API with no authentication is a gift to attackers.
Subdomain enumeration is identifying all subdomains associated with your domain. For the primary domain yourcompany.com, enumeration might discover: www (web server), api (API endpoint), mail (email server), staging (staging environment), app (internal application), cdn (content delivery), dev (development environment), test (testing environment), and dozens of others. Some of these are intentional and should exist. Many are forgotten—created for a short-term project, deployed to staging, and never cleaned up when the project ended.
Each subdomain represents configuration decisions about what services run there, who can access them, what data they contain, and what security controls protect them. The problem is visibility: most organizations can't answer basic questions about their own subdomains. "How many subdomains do we have?" "What services run on each one?" "Who maintains each one?" "Which are staging vs. production?" Attackers can answer these questions about your domain faster than you can, giving them the advantage.
Subdomain Enumeration Techniques Attackers Use
Attackers enumerate subdomains through multiple passive techniques that leave no forensic trace. SSL certificate transparency logs are public records of every SSL certificate issued for your domain, including all subdomains. A single certificate might list 50+ subdomains. Attackers query certificate transparency logs (crt.sh, censys.io) to find subdomains you didn't realize were publicly documented.
DNS zone transfers are legitimate DNS operations for transferring DNS data between servers. If misconfigured, they leak your entire subdomain list. Attackers attempt zone transfers against your nameserver—if successful, they get your complete DNS configuration. This is rare on modern systems but still found on poorly maintained infrastructure. Search engines have indexed subdomains for years. Attackers use Google search operators like site:*.yourcompany.com to find subdomains mentioned on your website or elsewhere on the internet.
Brute-force enumeration tries common subdomain names against your domain: www, api, mail, admin, test, staging, dev, backup, cdn, database, and thousands of others. Tools like Subfinder, Amass, and Assetfinder automate this, testing thousands of common subdomain names in minutes. Most tools use pre-compiled word lists of common subdomains. Any subdomain with a DNS record (even if it's not running a service or is intentionally offline) is discovered.
Passive DNS databases (PassiveDNS, SecurityTrails, Censys) record historical DNS queries. These databases contain DNS records for subdomains that no longer exist, showing historical infrastructure. An attacker can query these databases to find subdomains you once used but decommissioned years ago. If that old subdomain was never properly cleaned up, the underlying service might still be running and accessible.
Conducting Your Own Subdomain Enumeration
Before attackers enumerate your subdomains, enumerate them yourself. Use Subfinder, a free tool that queries multiple sources (certificate transparency, DNS, search engines, brute-force) and returns all discovered subdomains: subfinder -d yourcompany.com. You'll get a list of every subdomain the tool can find. Most startups are shocked by how many subdomains exist.
Cross-reference this list against your actual infrastructure. For each subdomain, answer: What service runs here? Who owns it? Is it still in use? Is it supposed to be publicly accessible? Create a spreadsheet documenting your subdomains: subdomain name, what's running on it, owner, maintenance status, security controls, and whether it's publicly accessible. This spreadsheet becomes your authoritative subdomain inventory.
Categorize subdomains: production (customer-facing, critical), staging (pre-production testing), development (development work), internal (employee-facing tools), integration (third-party integrations), legacy (deprecated but not yet decommissioned), and orphaned (forgotten, no active owner). This categorization helps you prioritize security efforts.
For each subdomain, test its security posture. What's running on it? Can you access it without authentication? Does it have default credentials? Is it outdated software? Run a vulnerability scan (Nessus, Qualys) against each subdomain. You'll often find that forgotten subdomains are running old, unpatched software because no one maintains them.
Eliminating or Securing Forgotten Subdomains
The easiest security improvement is elimination: decommission and delete subdomains that serve no purpose. If a subdomain is deprecated or orphaned, remove its DNS record and shut down the underlying service. Each deleted subdomain is one fewer attack vector. Be systematic: identify all subdomains with no documented owner or purpose, notify relevant teams that these will be deleted (in case someone's using it undocumented), and delete them.
For subdomains you need to keep, ensure they have security controls matching their purpose. Development and staging subdomains don't need the same security as production, but they need some controls: authentication (not default credentials), no access to production data, regular patching, and monitoring. Many staging environment breaches happen because the staging environment was treated as "less important" and received minimal security attention—then attackers used it as a pivot point to access production.
Document your subdomain architecture. Include which subdomains exist, what services run on them, their purpose, their owner, and their security controls. When new subdomains are created for new projects or integrations, add them to this documentation immediately. When subdomains are decommissioned, remove them. This ongoing inventory prevents "we forgot that exists" situations.
Implement a naming convention for subdomains that makes their purpose obvious: prod-api.yourcompany.com for production API, staging-app.yourcompany.com for staging application, internal-tools.yourcompany.com for internal tools. This makes it obvious what each subdomain's purpose is, reducing confusion and accidental misconfiguration.
Preventing Subdomain Takeover
Subdomain takeover occurs when a subdomain's DNS record points to a service that no longer exists or isn't properly configured. An attacker can take ownership of that service and serve their own content from your subdomain. For example: you have cdn.yourcompany.com pointing to a CloudFront distribution. You delete the CloudFront distribution but forget to remove the DNS record. An attacker creates their own CloudFront distribution and claims the subdomain, now serving content from yourcompany.com domain.
After decommissioning a service, immediately remove its DNS record. Don't leave orphaned records pointing to non-existent services. Verify that DNS records point to the correct services: a CNAME should point to an active service you control, an A record should point to an active IP address you own. Regularly verify that services subdomains point to are still under your control.
Subdomain enumeration is something attackers do routinely and organizations rarely do. This imbalance gives attackers visibility into your infrastructure that you don't have. Conducting regular subdomain enumeration, maintaining an authoritative inventory, and eliminating forgotten subdomains closes this visibility gap and significantly reduces your attack surface.
RedRadar can enumerate all your subdomains, identify forgotten or misconfigured ones, and help you harden your subdomain security posture.
Subdomain enumeration is one of the most common reconnaissance techniques used by attackers—and one of the easiest to overlook. While your main domain might have tight security, every exposed subdomain is a potential entry point that could put your entire company at risk.
In this guide, we'll explain what subdomain enumeration is, why attackers use it, and how to secure your subdomains before they become a liability.
What Is Subdomain Enumeration?
Subdomain enumeration is the process of discovering all subdomains associated with a target domain. Attackers use this to map out your organization's digital footprint and identify overlooked assets they can exploit.
For example, an attacker might discover:
- staging.yourcompany.com (development environment with weak security)
- api-old.yourcompany.com (deprecated API endpoint still accessible)
- vpn.yourcompany.com (exposed VPN access)
- test.yourcompany.com (testing environment with default credentials)
- mail.yourcompany.com (email server misconfigurations)
Each of these represents a potential attack surface your security team might not even know about.
How Attackers Enumerate Subdomains
Subdomain enumeration doesn't require sophisticated hacking. Attackers use publicly available tools and data sources:
Passive Enumeration
Certificate Transparency Logs: Every SSL certificate issued for your domain (including subdomains) is publicly logged. Tools like Shodan, Censys, and crt.sh make these logs searchable. An attacker can find every subdomain you've ever issued a certificate for in seconds.
DNS Records: Tools query historical DNS data (via Wayback Machine, DNS archives) to find subdomains that existed in the past.
Search Engine Caches: Google and other search engines have indexed pages on your subdomains—attackers search for site:*.yourcompany.com to find them.
Public Databases: Services like Shodan, Censys, and VirusTotal maintain databases of subdomains discovered by millions of users.
Active Enumeration
Brute Force: Attackers use wordlists of common subdomain names (www, api, admin, staging, test, etc.) and probe your domain to see which ones resolve.
Zone Transfers: If DNS is misconfigured, attackers may be able to request a full zone transfer—getting a list of all subdomains at once.
Why Subdomain Enumeration Is Dangerous
Subdomain enumeration is the reconnaissance phase of an attack. Once attackers have a map of your infrastructure, they move to exploitation:
- Staging and dev environments often have weaker security controls and admin panels left publicly accessible
- Old/deprecated subdomains may still be running on older, unpatched software
- Forgotten infrastructure (acquired companies, old projects) sits unmonitored
- Misconfigured cloud storage (S3 buckets, Azure Blobs) attached to subdomains can leak sensitive data
- Email and DNS records can be used for phishing, domain takeover, or email spoofing
One compromised subdomain can lead to lateral movement into your main systems—or worse, your entire infrastructure.
How to Secure Your Subdomains
1. Audit Your Subdomains
First, enumerate your own subdomains before attackers do:
- Check Certificate Transparency logs: Use crt.sh or similar to see every certificate issued for your domain
- Query DNS records: Use dig +short -x or nslookup to list your DNS records
- Search Shodan/Censys: See what your subdomains look like to the outside world
- Review your infrastructure: Talk to your dev and ops teams about all running services
2. Decommission Unused Subdomains
Delete DNS records for any subdomains you no longer use. If you can't delete them, redirect them to your main domain with an HTTP 301 redirect.
Never leave subdomains pointing to old/unmaintained servers.
3. Enforce HTTPS on All Subdomains
Every subdomain should have a valid SSL/TLS certificate. Use a wildcard certificate (*.yourcompany.com) to simplify management and ensure all future subdomains are covered.
4. Add Security Headers
Configure security headers on all subdomains to prevent clickjacking, XSS, and other attacks:
- X-Frame-Options: DENY
- X-Content-Type-Options: nosniff
- Strict-Transport-Security: max-age=31536000
- Content-Security-Policy tailored to your service
5. Restrict Access to Sensitive Subdomains
Staging, admin, VPN, and test subdomains should never be publicly accessible:
- IP whitelist your office networks
- Require VPN access
- Use authentication (OAuth, SAML, MFA)
- Hide them from public DNS (use a private DNS server for internal use)
6. Monitor Subdomain Creation
Set up alerts for new DNS records created on your domain. Services like Certificate Transparency monitoring will notify you whenever a new certificate is issued—if someone (or an attacker) creates an unauthorized subdomain, you'll know immediately.
7. Scan for Subdomain Takeover
Subdomain takeover is when an attacker registers a subdomain that points to a service you no longer control (expired Heroku app, decommissioned S3 bucket, etc.). Attackers can then serve malware or phishing from that subdomain using your domain name.
Check for dangling DNS pointers regularly using tools like SubTakeover or specialized services.
The Bottom Line
Subdomain enumeration is one of the first steps attackers take against any target. Your subdomains are a critical part of your attack surface—and they're often the easiest part to overlook.
Audit your subdomains now, remove what you don't need, and secure what you do. A single misconfigured subdomain could expose your entire company.
Need help assessing your security posture? RedRadar's automated OSINT Security Exposure Reports identify exactly which of your external assets—including subdomains—are exposed or misconfigured. Get your security assessment today at https://redradar.aisolutionsdev.com/.