Subdomain Takeover: Detection, Exploitation & Prevention Guide

A subdomain takeover stems from a synchronization breakdown between authoritative DNS zone configurations and third-party cloud infrastructure lifecycles. In fast-moving development teams, engineers regularly spin up temporary proof-of-concept projects, marketing landing pages, and microservices hosted on multi-tenant SaaS providers. As infrastructure changes, resources are terminated in cloud vendor dashboards while their corresponding DNS records - frequently CNAME, ALIAS, or A records - remain live indefinitely.

When a visitor navigates to an affected hostname like promo.example.com, their browser resolves the CNAME target (such as example-promo.s3-website-us-east-1.amazonaws.com). Because the S3 bucket was deleted, AWS returns a standard NoSuchBucket error message. An external adversary scanning Certificate Transparency logs or utilizing passive DNS databases can detect this state within minutes. By simply creating a new public S3 bucket named example-promo inside any AWS account they control, the attacker claims the subdomain instantly. The attacker's content is now transparently served under https://promo.example.com.

Beyond basic website defacement, modern attackers exploit subdomains for sophisticated corporate espionage. Because modern web browsers share cookies across subdomains when the domain=.example.com attribute is configured on session identifiers, an adversary controlling an abandoned subdomain can execute session fixation attacks or capture authentication credentials. Furthermore, enterprise email filtering systems and Single Sign-On (SSO) redirect URIs frequently trust all subdomains of a corporate domain, allowing attackers to bypass OAuth redirect validations and steal authorization codes. You can explore how attackers execute broader enterprise intrusion chains in our Anatomy of a Data Breach Guide and discover unknown assets with the Attack Surface Reconnaissance Tool.

Detecting dangling subdomains requires understanding the specific HTTP responses and DNS error signatures returned by multi-tenant cloud providers. When a tenant relinquishes a resource name, the platform's edge routers generally return identifiable error codes indicating that the custom domain points to the provider's routing layer, but no active tenant account currently claims that identifier.

For example, GitHub Pages returns 404 There isn't a GitHub Pages site here when a CNAME file does not match an active repository. An attacker can create a free GitHub repository, push an index.html file, add a CNAME file containing your subdomain, and claim full control. Similarly, Heroku returns 404 Heroku | No such app, which allows an attacker to execute heroku create app-name and immediately link your corporate hostname. AWS S3 requires the attacker to register the exact bucket name in the specified AWS region, after which AWS will route web traffic directly to their malicious payload.

Below is an authoritative matrix of common cloud providers vulnerable to subdomain takeovers, their characteristic diagnostic signatures, and their exploitation complexity. To systematically verify whether your organization's external records are pointing to abandoned cloud resources, run the DNS Record Lookup Tool alongside our Free Security Tools Directory.

Mitigating subdomain takeovers requires transitioning from ad-hoc manual reviews to automated, continuous external attack surface management (EASM). Modern engineering ecosystems deploy code hundreds of times per week across dozens of ephemeral cloud environments; manual DNS spreadsheets cannot prevent dangling pointers from slipping through.

First, adopt atomic Infrastructure as Code (IaC) using Terraform, Pulumi, or AWS CloudFormation. Configure resource lifecycle definitions so that DNS records and their corresponding cloud assets are created and destroyed inside the exact same deployment step. If an S3 bucket is destroyed in a Terraform manifest, the corresponding Route 53 CNAME record must be destroyed simultaneously. Never allow developers to delete cloud resources in the vendor console without updating DNS.

Second, implement continuous perimeter scanning with the WeSecureX Website Scanner and Subdomain Finder. The WeSecureX engine ingests passive DNS telemetry, Certificate Transparency logs, and active DNS brute-forcing to maintain an exhaustive directory of every corporate hostname. Each discovered subdomain is interrogated against known cloud provider fingerprint databases. When a dangling pointer is identified, real-time alerts are dispatched to your security operations team, allowing you to delete the orphan DNS record before an external researcher or adversary claims it. Learn more about continuous attack surface hygiene in our Attack Surface Management Guide.