Mitigating Subdomain Takeover: How to Audit and Secure Dangling DNS Records

Subdomain Takeover Explained (and How to Fix It)

Dangling DNS records occur when a CNAME points to a decommissioned service like a deleted Heroku app or S3 bucket. High-profile entities including Uber and Microsoft have fallen victim to this vulnerability because DNS records often outlive the services they point to.

Why This Matters

In an ideal infrastructure model, service decommissioning includes atomic DNS updates, but the technical reality is that DNS cleanup is frequently omitted from shutdown checklists. This creates a security gap where valid HTTPS certificates and trusted brand names are used to host malicious content, effectively bypassing Content Security Policies (CSP) that whitelist internal subdomains and allowing for seamless phishing or session cookie theft.

Key Insights

• Vulnerability Vector: Any external hosting platform including Heroku, GitHub Pages, Netlify, and S3 can be a vector if CNAME records are not removed after service deletion.
• Cookie Security: Session cookies scoped to a root domain are accessible to any hijacked subdomain, leading to potential cross-subdomain session theft.
• Discovery via Certificate Transparency: Engineers can use crt.sh to query certificate logs to identify every historical subdomain ever issued a certificate for a specific domain.
• Community Intelligence: The EdOverflow/can-i-take-over-xyz repository tracks exploitable platforms and their specific error fingerprints to assist in automated detection.
• Tooling for Audits: ZeroHook and subjack are used by security teams to automatically flag dangling records and scan for takeover vulnerabilities.

Working Examples

Querying certificate transparency logs to discover all issued subdomains.

curl "https://crt.sh/?q=%.yourapp.com&output=json" | jq '.[].name_value' | sort -u

Verifying a dangling record by checking if the CNAME target returns a 404 or ‘No such app’ error.

dig CNAME staging.yourapp.com
curl -I https://yourapp.herokuapp.com

Practical Applications

• Use Case: Run dnsx for fast bulk DNS resolution to identify which CNAME targets in your zone file no longer resolve to active services.
• Pitfall: Neglecting A records pointing to decommissioned elastic IPs; if an attacker claims that IP in their own AWS account, they inherit the traffic.
• Use Case: Implement a mandatory DNS record deletion step in service decommissioning workflows to treat DNS entries with the same urgency as API key revocation.
• Pitfall: Renaming a GitHub repository without updating the corresponding CNAME, leaving the old address open for registration by third parties.

References:

• https://dev.to/rronyecz/subdomain-takeover-explained-and-how-to-fix-it-24be
• https://github.com/EdOverflow/can-i-take-over-xyz
• https://crt.sh/
• https://zerohook.org