In 2020, a security researcher found a subdomain belonging to a major financial institution , dev-analytics.bank.example.com , that was running an outdated Grafana instance with default credentials. The subdomain had been set up by a data team two years earlier for a proof-of-concept project that was subsequently abandoned. The DNS record was never removed. The Grafana instance was never decommissioned. The infrastructure was provisioned via a personal cloud account that was later folded into the corporate AWS organization but not integrated into the organization's security monitoring. The Grafana instance provided access to internal metrics that included database connection strings, API endpoint patterns, and user activity volumes , intelligence that would have been valuable to any attacker targeting the bank's production infrastructure.
This story is not unusual. It is the norm. Any organization that has existed for more than a few years, that has more than a handful of development teams, and that uses cloud infrastructure, accumulates subdomains the way a house accumulates things in the attic: steadily, silently, and without anyone maintaining an accurate inventory.
Why Subdomain Sprawl Is Inevitable
Subdomains are cheap to create and expensive to track. Creating a subdomain requires a DNS record and, if HTTPS is desired, a TLS certificate. In organizations with self-service cloud provisioning, a developer can create both in minutes. Tracking that subdomain , recording who created it, what it hosts, whether it is still needed, who is responsible for its security , requires organizational processes that most organizations do not have.
The sources of subdomain sprawl are mundane:
Development and staging environments. Every application gets a development, staging, and sometimes QA subdomain. These environments are often provisioned with production-like configurations (same cloud provider, same software stack) but without production-like security controls (weaker authentication, relaxed network policies, older software versions). When the application launches, the staging subdomains persist because nobody removes them.
Vendor and partner integrations. SaaS products, marketing platforms, and business tools often require custom subdomains for CNAME verification, single sign-on, or branded portals. When the vendor relationship ends, the subdomain may remain: the DNS CNAME still points to the vendor's infrastructure, creating a potential subdomain takeover vulnerability if the vendor releases the associated resource.
Proof-of-concept and experimental projects. Teams create subdomains for hackathon projects, internal tools, data dashboards, and experimental services. These are "temporary" by intention and permanent by default.
Acquisitions and mergers. Acquired companies bring their own domain structures, which are folded into the parent organization's DNS without comprehensive review. Subdomains from the acquired company may run software that the parent organization's security team has never assessed.
How Attackers Discover Subdomains
The attacker's subdomain discovery process combines multiple data sources, each revealing a different subset of the target's DNS infrastructure:
Certificate Transparency (CT) logs. Every publicly-trusted TLS certificate is logged in CT logs (a requirement since 2018). Services like crt.sh provide searchable interfaces to these logs. Querying %.example.com returns every certificate ever issued for any subdomain of example.com, including internal subdomains that were not intended to be discoverable. CT logs are the single most productive subdomain discovery source because they are comprehensive (every HTTPS subdomain is logged) and historical (certificates issued years ago are still in the logs).
Passive DNS databases. Services like SecurityTrails, VirusTotal, and Farsight DNSDB aggregate DNS resolution data from multiple vantage points. They record which subdomains resolved to which IP addresses over time, providing both current and historical subdomain data. A subdomain that was only active briefly , a staging server that existed for a few weeks , may still appear in passive DNS records.
DNS brute-forcing. Methodical querying of common subdomain names against the target's DNS servers. Wordlists combining common prefixes (dev, staging, admin, api, internal, test, beta, old, legacy) with the target's domain reveal subdomains that follow predictable naming conventions. Modern tools like massdns can resolve millions of subdomain candidates per minute.
Search engine indexing. Google dorks (site:*.example.com) and Bing searches reveal subdomains that were indexed by search engine crawlers. This often exposes subdomains that were unintentionally accessible to the public internet.
The aggregation of these sources produces a comprehensive subdomain inventory that is often more complete than the target organization's own records. This is the fundamental asymmetry: the attacker's enumeration tools are automated and comprehensive, while the defender's inventory is manual and incomplete.
From Discovery to Exploitation
Once subdomains are discovered, the exploitation process is systematic. Each live subdomain is probed for:
Software identification. HTTP response headers, page titles, favicon hashes, and CSS patterns identify the software running on each subdomain. A Grafana instance, a Jenkins server, a WordPress installation, a phpMyAdmin interface, and a Kubernetes dashboard each have distinctive fingerprints that can be automatically classified.
Known vulnerabilities. The identified software version is checked against CVE databases. An outdated Grafana instance may be vulnerable to CVE-2021-43798 (path traversal), CVE-2023-3128 (authentication bypass), or other known flaws. Nuclei templates and similar tools automate this matching at scale.
Authentication weaknesses. Default credentials are tested. Brute-force attacks are attempted against login forms without rate limiting. Token-based authentication with known defaults is checked. Many forgotten subdomains run with the factory-default credentials because they were never configured for production use.
Subdomain takeover. If a subdomain's DNS CNAME points to an external service (AWS S3, Heroku, Azure, GitHub Pages) that no longer exists, the attacker can claim that resource and serve arbitrary content under the target's domain. This is particularly dangerous because the content is served under the target's domain with a valid TLS certificate, making phishing and credential harvesting attacks highly convincing.
Building a Continuous Discovery Program
The defensive counterpart to attacker enumeration is a continuous discovery program that maintains an accurate, up-to-date inventory of the organization's external surface. The components are:
Automated enumeration on a schedule. The same tools and data sources that attackers use , CT log monitoring, passive DNS queries, DNS brute-forcing , should run continuously against your own domains. The output feeds into an asset inventory that tracks each subdomain's discovery date, current resolution, hosting infrastructure, and identified software.
Ownership assignment. Every discovered subdomain must be mapped to a responsible team or individual. Subdomains without clear ownership are the highest-risk assets because nobody is responsible for their security, patching, or decommissioning. The discovery program should flag unowned subdomains and escalate them until ownership is established or the subdomain is removed.
Lifecycle management. Subdomains should have explicit creation justification, security classification, and review dates. A staging subdomain created for a product launch should have a review date 30 days after launch, at which point it is either confirmed as still needed (with a new review date) or decommissioned. Without this lifecycle process, subdomains accumulate indefinitely.
Integration with vulnerability management. Discovered subdomains should be automatically added to the organization's vulnerability scanning scope. A new subdomain that appears in the inventory should trigger an initial security assessment: software identification, known vulnerability check, authentication assessment, and exposure classification.
The honest difficulty of this program is not technical , the enumeration and scanning tools are mature and largely automated. The difficulty is organizational: establishing the ownership mapping, enforcing the lifecycle process, and ensuring that the inventory is actually used for security decision-making rather than existing as a report that nobody reads. The organizations that do this well treat external surface management as an ongoing operational function, not a periodic project.
Subdomains are not optional attack surface. They are the default state of any growing organization's internet presence. The choice is not between having subdomains and not having them. It is between knowing what you have and hoping that attackers do not find what you have forgotten.