1. Anatomy of Subdomain Takeover (Dangling CNAME)
A Dangling CNAME record occurs when an organization's authoritative DNS zone contains an alias pointing to an external domain hosted on a cloud platform (such as AWS S3, GitHub Pages, Heroku, Shopify, or Azure App Service), but the underlying resource in that cloud platform has been deleted or decommissioned without removing the corresponding DNS record.
In this situation, an attacker can register the exact same decommissioned resource name on the target SaaS platform (claiming the bucket name or application handle) and gain full control over the corporate subdomain (blog.company.com).
2. Vulnerable SaaS Provider Fingerprint Matrix
Each cloud platform produces a distinct error signature (HTTP header or body fingerprint) when receiving traffic intended for a custom domain whose internal resource is unclaimed:
| Cloud / SaaS Platform | Target CNAME FQDN Pattern | Vulnerability HTTP Fingerprint |
|---|---|---|
| Amazon Web Services (S3) | *.s3.amazonaws.com | <Code>NoSuchBucket</Code> |
| GitHub Pages | *.github.io | 404 There isn't a GitHub Pages site here. |
| Heroku Applications | *.herokuapp.com | No such app - Heroku |
| Microsoft Azure App Service | *.azurewebsites.net | 404 Web App - Not Found. |
3. Attack Vectors: Session Cookie Theft & High-Trust Phishing
Subdomain takeovers carry a Critical Severity Rating (CVSS 8.5+) due to the following exploit mechanisms:
- Session Cookie Hijacking: If corporate HTTP cookies set
Domain=.company.com, an attacker operating onsubdomain.company.comcan harvest active user authentication tokens. - CSP (Content Security Policy) Bypasses: Primary web applications often whitelist scripts loaded from owned subdomains (
script-src *.company.com). - High-Trust Phishing Portals: Attackers can obtain valid TLS certificates (Let's Encrypt) for the hijacked subdomain to host convincing credential harvesting portals.
4. Automated CLI Audit via `dig` and `curl`
Verify whether a subdomain points to an orphan target using terminal commands:
5. DNS Decommissioning Workflow & DevSecOps Best Practices
To mitigate subdomain takeover risks across cloud environments, DevSecOps teams should strictly enforce the following rule:
"Always delete the CNAME record in DNS first before decommissioning the app instance or cloud storage bucket on the SaaS provider."