Dangling CNAME Subdomain Takeover

Subdomain takeover through dangling CNAMEs is one of the most common — and most preventable — DNS security issues. It happens when a DNS CNAME record points to a resource that no longer exists, allowing an attacker to claim that resource and serve content on your subdomain.

How it works

The attack follows a simple pattern:

1. You provision a SaaS service and point a subdomain to it: app.example.com CNAME myapp.herokuapp.com
2. Later, you cancel the service or delete the app, but forget to remove the DNS record
3. The CNAME now points to a resource that doesn't exist — it's "dangling"
4. An attacker creates an account on Heroku (or whatever service) and claims the name myapp
5. Your subdomain app.example.com now serves the attacker's content

Why it's dangerous

A subdomain takeover gives the attacker control over content served under your domain. This enables:

• Phishing: The attacker can host a convincing phishing page on app.example.com, leveraging your domain's reputation
• Cookie theft: If your parent domain sets cookies broadly (e.g., .example.com), the attacker can read them from the subdomain
• Valid SSL certificates: The attacker can obtain legitimate SSL certificates for the subdomain through providers like Let's Encrypt
• SEO abuse: The attacker can host spam or malware content, damaging your domain's search ranking
• Brand damage: Anything served on your subdomain reflects on your organization

Commonly vulnerable services

Any SaaS platform that allows custom domains and uses a shared hosting model can be vulnerable. The most commonly exploited include:

• Heroku (*.herokuapp.com)
• GitHub Pages (*.github.io)
• AWS S3 (*.s3.amazonaws.com)
• Azure (*.azurewebsites.net, *.cloudapp.net)
• Shopify, Zendesk, Fastly, Netlify, Surge.sh, and many others

Detection methods

• DNS enumeration: Enumerate all subdomains (via certificate transparency logs, DNS zone transfers, or brute force) and check each CNAME for liveness
• NXDOMAIN detection: If a CNAME target returns NXDOMAIN, the resource likely doesn't exist
• HTTP fingerprinting: Many SaaS platforms return distinctive error pages when a custom domain isn't configured (e.g., Heroku's "No such app" page)
• Continuous monitoring: Regularly re-scan your subdomains for new dangling records

Prevention

• Remove DNS records when decommissioning services: Make this part of your offboarding checklist
• Maintain a subdomain inventory: Document what each subdomain is for and which service it points to
• Use DNS monitoring: Get alerts when CNAME targets stop resolving
• Restrict DNS record creation: Limit who can create DNS records through change management processes
• Claim subdomains proactively: On platforms that allow it, reserve your namespace even if you're not actively using it