Subdomain Takeover: The Silent Risk Hiding in Your DNS

The dangling CNAME problem

A subdomain takeover happens when a DNS record points to a resource that no longer exists — and an attacker claims that resource to serve content under your domain.

The classic scenario: your team spins up a staging environment on Heroku at myapp.herokuapp.com and creates a CNAME record staging.yourdomain.com → myapp.herokuapp.com. Later, the Heroku app is deleted — but the CNAME record is forgotten. The subdomain is now "dangling" — it resolves but points to nothing. An attacker can register the same Heroku app name and immediately serve content at staging.yourdomain.com under your trusted domain.

Why this is serious

An attacker who controls a subdomain of your domain can:

• Serve phishing pages that appear to come from your organisation
• Steal session cookies if you have set cookies with Domain=.yourdomain.com (which scopes cookies to all subdomains)
• Bypass Content-Security-Policy rules that whitelist your own domain
• Issue certificates for the subdomain from some CAs (though Certificate Transparency logging now makes this detectable)
• Send email from the subdomain if SPF/DMARC are not scoped to cover subdomains

The most commonly affected services

Any platform-as-a-service that uses customer-specific hostnames is potentially affected. Services with well-documented takeover techniques include:

• GitHub Pages (username.github.io)
• Heroku (appname.herokuapp.com)
• AWS S3 buckets (bucket.s3.amazonaws.com)
• Azure App Service (appname.azurewebsites.net)
• Fastly, Shopify, Zendesk, Helpjuice, Ghost, Tumblr

Cloud providers are adding ownership verification to close this gap, but legacy CNAME records from before those controls existed remain vulnerable.

How to detect dangling CNAMEs

For each CNAME record in your DNS:

1. Resolve the CNAME target
2. If the target resolves but returns an error page (There is no app at that hostname, NoSuchBucket, Repository not found), the subdomain may be vulnerable
3. Check the error message against known takeover fingerprints for that service

VP Shield automates this — it resolves each CNAME in your domain's DNS and checks the response against a database of known vulnerable service fingerprints.

Prevention

• Clean up DNS when decommissioning: make DNS record removal part of every infrastructure teardown checklist
• Audit regularly: run subdomain enumeration and CNAME checking quarterly
• Use CAA records: restrict which CAs can issue certificates for your domain and subdomains
• Scope DMARC to subdomains: add sp=reject to your DMARC record so attackers cannot send email from subdomains either