Your forgotten dev servers, test environments, and old staging sites are low-hanging fruit for attackers. Here's how they find them.
When an attacker targets your business, the first thing they do is map your attack surface. Every subdomain they find is a potential entry point — an unpatched dev server, a forgotten test environment running old software, an internal tool accidentally exposed to the internet.
Most businesses have far more subdomains than they realize. The main site is protected. The forgotten test environment three years old running an exploitable version of something? Not so much.
In dev.portal.yourdomain.com, the subdomain is dev.portal. Subdomains are used to separate parts of a website — dev environments, specific services, regional deployments, internal tools. They're created freely and cheaply, which means they accumulate.
Attackers don't guess subdomains randomly. They enumerate them systematically using a range of techniques.
Every SSL/TLS certificate issued for a domain is logged publicly in Certificate Transparency (CT) logs. This is an FTC requirement in the US — Certificate Authorities must log all certificates they issue. These logs are searchable by anyone.
An attacker can pull every subdomain that's ever had a valid SSL certificate issued for it — including internal-sounding names like internal.portal.com, staging-api.company.com, jira.company.com, or vpn.company.com.
Attackers maintain massive wordlists of common subdomain names — dev, staging, test, internal, admin, api, uat, demo, old, backup. They then run these against your domain's DNS server, looking for anything that resolves.
This is fast with tools like amass, subfinder, or dnsgen. A typical wordlist attack against a single domain can test thousands of subdomain patterns in under a minute.
DNS zone transfers (AXFR) let you copy an entire DNS zone — every record for a domain. If a misconfigured DNS server allows zone transfers to unauthorized requesters, an attacker gets your complete DNS records in one query.
Most authoritative DNS servers are now configured to block unauthorized zone transfers, but old BIND servers and some misconfigured providers still allow it.
Google dorking, Shodan, and Censys all index subdomains. A quick search for site:*.yourdomain.com in Google will surface some subdomains that have been indexed. Shodan specifically indexesbanner data from internet-facing services and commonly returns internal tool subdomains.
Services that integrate with your domain — GitHub, Jira, Slack, AWS, Azure, Datadog — often create DNS records or subdomains as part of their setup. These are sometimes discoverable through their own enumeration or through exposed configuration files.
Finding a subdomain is reconnaissance, not exploitation. But from there, it's a short chain:
Subdomain takeovers are a particular risk — if a subdomain points to a service that's been decommissioned but the DNS record wasn't deleted, an attacker can claim that subdomain and host malicious content under your brand.
The answer is simple: use the same techniques attackers use, before they do.
Your attack surface includes every subdomain anyone's ever created for your domain. The only ones you're actively defending are the ones you know about. Everything else is a gamble — and attackers are very good at finding the gaps.
Scans Certificate Transparency logs, performs DNS enumeration, and maps your full subdomain landscape automatically.
View Plans →