Subdomain Takeover: How Dangling DNS Records Become Attack Vectors

Introduction

Subdomain takeover is one of the most quietly dangerous vulnerabilities on the modern internet. It does not require exploiting a software bug, breaking encryption, or guessing a password. It requires a single forgotten DNS record -- a CNAME pointing to a cloud service that no longer exists -- and an attacker who notices before you do.

The attack is devastatingly simple. An organization provisions a cloud resource, creates a DNS record pointing a subdomain to that resource, and eventually decommissions the service. The DNS record stays behind. The attacker claims the now-vacant resource on the cloud provider and instantly controls content served under the organization's trusted domain. No alerts fire. No logs are generated on the victim's infrastructure. From the outside, everything looks legitimate. To understand the full scope of what DNS records expose, see DNS Security: What Your Domain Configuration Reveals to Attackers.

This vulnerability persists because DNS records are managed by one team, cloud infrastructure by another, and nobody owns the gap between them.

How Subdomain Takeover Works

A CNAME record is an alias. When a browser requests blog.example.com and finds a CNAME pointing to example-corp.ghost.io, the browser follows the chain and loads content from Ghost's servers. The critical assumption is that the organization controls what is served at the CNAME target. When that assumption breaks, an attacker steps in.

The technical mechanics vary by provider, but the pattern is consistent:

1. Provision: The team creates a resource -- an S3 bucket, a Heroku app, an Azure App Service, a GitHub Pages site.
2. Configure DNS: A CNAME record is added: docs.example.com → example-corp.s3-website-us-east-1.amazonaws.com.
3. Decommission: Months or years later, the resource is deleted. The S3 bucket is removed, the Heroku app is torn down, the Azure subscription lapses.
4. The gap: The CNAME record remains in the DNS zone. It now points to a hostname that exists on the cloud provider's infrastructure but is not claimed by anyone.
5. Takeover: An attacker creates a new resource on the same cloud provider, claims the orphaned hostname, and now controls the content served at docs.example.com.

The attacker does not need access to the victim's DNS provider, registrar, or any internal system. They only need an account on the same cloud platform.

Which Services Are Vulnerable

Not all cloud services are equally susceptible. The vulnerability depends on how the provider handles hostname claims for deleted resources.

Amazon S3 is one of the most commonly exploited. When an S3 bucket is deleted, its name becomes available for anyone to re-register. If a CNAME points to example-corp.s3.amazonaws.com and that bucket no longer exists, an attacker creates a new bucket with that name and the subdomain is compromised.

GitHub Pages allows users to configure custom domains. If a repository with Pages is deleted but the CNAME remains, an attacker creates a new repository, enables Pages with the matching custom domain, and GitHub serves their content on the victim's subdomain.

Heroku assigns *.herokuapp.com hostnames to applications. Deleted app names can be reclaimed. A CNAME to example-app.herokuapp.com becomes exploitable the moment the app is removed.

Azure services including App Service, Traffic Manager, and Cloud Services follow similar patterns. Resource names exist in global namespaces, and deletion frees them for re-registration.

Other affected services include Fastly, Shopify, Pantheon, Surge.sh, and dozens more. The community-maintained can-i-take-over-xyz repository tracks which services are currently vulnerable.

How Attackers Find Dangling Records

Discovering vulnerable subdomains is not difficult. Attackers use a combination of techniques that are entirely passive and leave no trace on the target's systems.

Certificate Transparency Logs

Every publicly trusted TLS certificate issued for a domain is logged in Certificate Transparency (CT) logs. These logs are append-only, publicly queryable, and contain a historical record of every subdomain that has ever had a certificate issued for it. An attacker queries CT logs for %.example.com and gets back a comprehensive list of subdomains -- including ones created years ago for services that no longer exist.

Tools like crt.sh, certspotter, and subfinder automate this enumeration. A single query returns subdomains that the organization may have forgotten about entirely.

DNS Brute-Force Enumeration

Attackers run wordlists of common subdomain names -- staging, dev, test, app, beta, docs, status, demo, legacy -- against the target domain, resolving each one. Any subdomain that returns a CNAME to a cloud provider hostname gets flagged for further investigation. Resolving the CNAME target reveals whether the resource still exists or returns an error page indicating the resource is unclaimed.

Error Fingerprinting

Each cloud provider returns a distinctive error for unclaimed resources. S3 returns NoSuchBucket, GitHub Pages a plain 404, Heroku No such app, and Azure a specific HTML error page. Attackers automate checks for these signatures across thousands of subdomains in minutes.

The Impact Goes Beyond Defacement

Subdomain takeover is often categorized alongside website defacement, but the real impact is far more severe.

Phishing under a trusted domain. An attacker controlling support.example.com can host a pixel-perfect login page. The URL is on the organization's actual domain. Browser address bars show the legitimate domain. Even security-aware users have no visual indicator that anything is wrong. Phishing campaigns launched from a trusted subdomain have dramatically higher success rates.

Cookie theft and session hijacking. Cookies set on a parent domain (example.com) are sent to all subdomains by default. If a session cookie is set with Domain=.example.com, it is transmitted to the attacker-controlled subdomain on every request. Session tokens, authentication cookies, and CSRF tokens can be harvested without user interaction beyond visiting the compromised subdomain.

OAuth and SSO exploitation. Many OAuth configurations whitelist redirect URIs by subdomain pattern. If *.example.com is an allowed redirect, the attacker-controlled subdomain becomes a valid OAuth callback endpoint, enabling token theft in authorization code flows.

Credential harvesting at scale. Combined with email campaigns from the organization's own domain (possible if email authentication is weak), an attacker can build a complete phishing pipeline -- emails from noreply@example.com directing users to login.example.com -- that is nearly indistinguishable from legitimate communications.

SEO poisoning. Attackers can host spam or malware distribution pages on the subdomain. Search engines attribute this content to the parent domain, damaging reputation and search rankings.

Prevention: Closing the Gap

Subdomain takeover is entirely preventable. The challenge is operational, not technical.

Maintain a DNS Inventory

The single most effective prevention measure is knowing what DNS records you have and why each one exists. Maintain a living inventory that maps every CNAME to the service it points to, the team that owns it, and the date it was last verified. If nobody can explain why a record exists, investigate and remove it. Good domain management practices -- including auto-renewal, registrar lock, and WHOIS privacy -- are also essential; our domain registration and WHOIS hygiene guide covers the basics.

Automate Dangling Record Detection

Manual quarterly reviews catch some issues, but automation catches them in real time. Run scheduled checks that resolve every CNAME in your zone and verify the target resource still exists. Flag any CNAME that returns a cloud provider error page indicating an unclaimed resource. This turns a slow-burn vulnerability into an actionable alert.

Delete DNS Records Before Deprovisioning

The decommission order matters. Remove the DNS record first, then delete the cloud resource. If you delete the resource first, there is a window during which the dangling record is exploitable. Codify this in your runbooks and enforce it through infrastructure-as-code pipelines.

Use Infrastructure as Code

When DNS records and cloud resources are managed through Terraform, Pulumi, or CloudFormation, deleting a resource and its corresponding DNS record happens atomically. Drift detection catches manual changes that create records outside the IaC workflow.

Restrict Wildcard DNS

Wildcard DNS records (*.example.com) match any subdomain without an explicit record. A wildcard CNAME pointing to a cloud provider makes every possible subdomain a potential takeover target. Avoid wildcard CNAMEs entirely; if unavoidable, ensure the target resource cannot be claimed by third parties.

Monitor Certificate Transparency Logs

CT logs are a discovery tool for both attackers and defenders. Set up monitoring for certificate issuance on your domain. Any certificate issued for a subdomain you do not recognize warrants immediate investigation -- it may indicate an attacker has already completed a takeover and is obtaining a TLS certificate to make the phishing page more convincing. Pairing CT monitoring with DNSSEC and CAA records further hardens your DNS -- see our DNSSEC and CAA records setup guide for implementation steps.

What CyberShield Checks

CyberShield's posture assessment directly addresses subdomain takeover risk through two complementary modules.

The DNS check module resolves and analyzes all DNS records for your domain, identifying CNAME records and verifying that their targets resolve to active resources. Dangling CNAMEs that return error responses characteristic of unclaimed cloud resources are flagged as high-severity findings with specific remediation steps.

The CT subdomain discovery module queries Certificate Transparency logs to enumerate every subdomain that has ever had a certificate issued. This uncovers subdomains that may not appear in your documentation -- historical subdomains from former employees, temporary project domains, and testing infrastructure that was never decommissioned. Each discovered subdomain is checked for resolution status and potential takeover conditions.

Together, these modules give you the same visibility that attackers have into your subdomain landscape, but with prioritized findings and actionable remediation guidance instead of an exploit. Start a scan to see if your domain has dangling records waiting to be claimed.