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.

A dangling service reference is a candidate for investigation. Actual takeover requires the provider to allow an unrelated account to serve the victim hostname. Historical fingerprints and signup behavior do not prove present-day claimability. The historical dangling-CNAME study is a separate prevalence question.

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. Takeover is conditional. A third party would need to obtain the exact resource and satisfy or bypass the provider's current hostname-binding controls. The error page alone does not demonstrate this.

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)
                                         ↓
                              (takeover only if current provider controls permit)

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:

Treat the provider table as historical candidate fingerprints, not a current vulnerable-provider list. Microsoft's dangling-DNS guidance describes ownership protections and service-specific prevention. Verify current provider rules and test only with disposable resources you own; do not claim a third party's endpoint.

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)

The same trust failure plays out with a far larger blast radius one level up the hierarchy, where expired name server domains turn into lame delegations that hand an attacker full DNS authority over every domain delegating to them, not just a single subdomain.

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, NSEC zone walking, 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 the Heroku app: capture the body AND the status separately.
# -o /dev/null would discard the body, leaving nothing to match on.
curl -s -w "\n[status: %{http_code}]\n" https://example-blog.herokuapp.com | grep -iE "No such app|status:"

The provider's error string is the signal, not the status code. A bare 404 tells you very little on its own: plenty of live applications return 404 for an unknown path.

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

# NXDOMAIN or a provider error means the record is DANGLING.
# That is a finding to investigate, not a confirmed takeover.
curl -I https://blog.example.com

Keep those two conclusions apart. A dangling record tells you the target resource is gone or unconfigured. Whether the hostname is actually claimable is a separate, provider-specific question, and often the answer is no: many providers require domain verification before another account can attach a hostname, reserve identifiers after release, or bind names to the original account. GitHub Pages is the clearest example, where verifying your custom domain stops other users from attaching it even after a site is disabled. Confirm against the provider's current rules before calling a subdomain vulnerable, and confirm it on your own assets rather than by attempting to claim someone else's.

Automated Scanning

Export the zone from your DNS provider and reconcile it with cloud/resource inventory. Use DNS Inspector to check known names; public lookups do not enumerate a complete zone. 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. Keep control of the service while cached DNS references expire
4. Verify the transition, then decommission and release the resource

Removing records first and retaining the resource through cache expiry reduces 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 first; the resource remains controlled through relevant cache expiry before release
• 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.