Subdomain Takeover: How Dangling DNS Records Let Attackers Hijack Your Domain

A subdomain takeover occurs when a DNS record — typically a CNAME — points to an external service that no longer exists, and an attacker claims that service endpoint to serve content on your subdomain. The attacker does not need to compromise your DNS or registrar. They simply register the unclaimed resource on the cloud provider, and the existing DNS record does the rest.

This is one of the most practical DNS vulnerabilities I encounter because it requires no sophisticated tooling. An attacker with a free Heroku, GitHub Pages, or Azure account can take over a Fortune 500 subdomain in minutes if the right conditions exist.

How Subdomain Takeover Works

The attack follows a predictable pattern:

1. A company creates a service — say, a blog hosted on Heroku — and sets up blog.example.com as a CNAME pointing to example-blog.herokuapp.com

2. The service is decommissioned. The team deletes the Heroku app but forgets to remove the DNS record.

3. The CNAME still exists. blog.example.com still points to example-blog.herokuapp.com, but that Heroku app no longer exists.

4. The attacker claims the endpoint. The attacker creates a new Heroku app and configures it to respond on example-blog.herokuapp.com.

5. The takeover is complete. Anyone visiting blog.example.com now sees the attacker's content, served under the victim's domain name.

blog.example.com  →  CNAME  →  example-blog.herokuapp.com
                                         ↓
                              (deleted by company)
                                         ↓
                              (claimed by attacker)

The key insight is that the DNS record creates a trust relationship with the cloud provider. When the underlying resource is released, that trust becomes exploitable.

Vulnerable Cloud Providers

Not all cloud services are equally vulnerable. A service is susceptible to subdomain takeover if:

1. It allows users to register custom hostnames
2. Releasing a resource makes that hostname available for anyone to claim
3. It returns a distinctive error page when no app is configured (making detection easy)

Commonly vulnerable services:

Some providers have added mitigations. For example, AWS CloudFront now verifies domain ownership before allowing custom domains, and Heroku has added restrictions. But many services remain vulnerable, and configurations vary.

Real-World Impact

Subdomain takeovers have been reported against major organizations:

• Microsoft has had multiple subdomain takeovers reported through their bug bounty program, including Azure-related subdomains
• Uber, Starbucks, and Slack have all had takeover vulnerabilities disclosed by security researchers
• Government domains (.gov) have been found vulnerable when agencies decommission cloud-hosted services without cleaning up DNS

An attacker controlling your subdomain can:

• Serve phishing pages that appear to be on your domain, bypassing user suspicion
• Steal cookies if the parent domain's cookie scope includes subdomains (e.g., cookies set for .example.com)
• Bypass Content Security Policy if your CSP trusts *.example.com
• Damage brand reputation by hosting inappropriate or malicious content
• Issue TLS certificates for the subdomain using domain validation (which only requires serving a file on the domain)

How Attackers Discover This Weakness

Attackers use automated tools to scan for dangling records at scale:

1. Enumerate subdomains using certificate transparency logs, DNS brute-forcing, or passive DNS databases
2. Resolve each subdomain and check for CNAME records pointing to cloud providers
3. Check if the target is unclaimed by looking for provider-specific error pages

# Check if a subdomain has a dangling CNAME
dig blog.example.com CNAME +short
# Returns: example-blog.herokuapp.com

# Check if the Heroku app exists
curl -s -o /dev/null -w "%{http_code}" https://example-blog.herokuapp.com
# 404 with "No such app" = vulnerable

Tools like subjack, nuclei, and can-i-take-over-xyz automate this process across thousands of subdomains.

How to Detect Vulnerable Subdomains

Manual Check

For each CNAME record in your zone:

# List all CNAME records (if you have zone access)
dig example.com AXFR @your-nameserver | grep CNAME

# For each CNAME, check if the target resolves
dig target.herokuapp.com A +short

# If it returns NXDOMAIN or a provider error, it is vulnerable
curl -I https://blog.example.com

Automated Scanning

Use the DNS Inspector to review all records for a domain. Look for CNAME records where:

• The target returns NXDOMAIN
• The target shows a cloud provider's default error page
• The target is a cloud service hostname pattern you do not recognize

Continuous Monitoring

The best defense is continuous monitoring. Set up periodic scans of your DNS records that alert when a CNAME target becomes unresolvable.

How to Defend Against It

Remove Records When Decommissioning Services

This is the primary defense. Every service decommissioning checklist should include "remove associated DNS records" as a mandatory step.

# Process:
1. Identify all DNS records pointing to the service
2. Remove the DNS records FIRST
3. Then decommission the service

Removing records first prevents the window of vulnerability. If you decommission the service first, there is a gap where the CNAME exists but the target is unclaimed.

Audit DNS Records Regularly

Schedule quarterly (or monthly for large organizations) audits of all DNS records:

• Identify all CNAME records pointing to external services
• Verify each target is still active and under your control
• Remove any records pointing to services you no longer use

Use Domain Verification Where Available

Some cloud providers support domain verification tokens (TXT records or specific file placements) before accepting custom domains. Use these features when available, as they prevent an attacker from simply claiming your hostname.

Avoid Wildcard CNAME Records

A wildcard CNAME like *.example.com → something.cdn.com is extremely dangerous. If the CDN account is decommissioned, every possible subdomain becomes vulnerable simultaneously.

Mitigation Checklist

• DNS records are removed before or simultaneously with service decommissioning
• Regular audits check all CNAME records for dangling targets
• Wildcard CNAME records are avoided or carefully monitored
• Cloud provider accounts are inventoried and matched against DNS records
• Domain verification features are used where providers support them
• Cookie scope does not unnecessarily include all subdomains
• CSP does not trust wildcard subdomains unless necessary
• Monitoring alerts when CNAME targets become unresolvable

Common Misconfigurations

• Decommissioning the cloud service without removing the DNS record — the most common cause of subdomain takeover
• Using wildcard CNAME records that create takeover risk for every possible subdomain
• Setting cookies on the parent domain (.example.com) without considering that compromised subdomains inherit them
• Trusting *.example.com in CSP headers, allowing a taken-over subdomain to bypass content security
• No DNS record inventory — many organizations cannot even list all their DNS records, let alone audit them

Ethical Note

Subdomain takeover testing against domains you do not own is a gray area. While some bug bounty programs explicitly include it, claiming a subdomain without authorization could be considered unauthorized access in some jurisdictions. Only test against your own domains or domains covered by an active bug bounty program with subdomain takeover in scope. If you discover a vulnerability, report it responsibly through the organization's security contact.

This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Hijacking, DNS Zone Transfer Attack.