Subdomain Takeover: How a Dangling CNAME Becomes Someone Else's Website

The mechanics, step by step

1. Your team launches a microsite: promo.example.com is CNAMEd to yourbrand.github.io, a Heroku app, an Azure blob endpoint, an S3 website bucket, or a similar named platform resource.
2. The campaign ends. Someone deletes the app or bucket — but not the DNS record. The CNAME now dangles: it resolves to a provider endpoint that says "no such site."
3. On many platforms, resource names are first-come-first-served. An attacker registers the same name — yourbrand.github.io, the same bucket name — and the platform happily serves their content wherever that name is referenced.
4. Your DNS still points there, so promo.example.com now renders attacker-controlled content, often with a valid certificate the attacker can provision for it.

Why it is worse than defacement

• Phishing with your own domain. A credential-harvesting page on a genuine subdomain of your company defeats the "check the URL" advice entirely.
• Cookie theft. Cookies scoped to .example.com are sent to every subdomain — including the one the attacker now controls.
• CSP and CORS bypass. Policies that trust *.example.com now trust the attacker.
• Email from your name. Depending on your SPF configuration, a taken-over service can sometimes send mail that authenticates as you.

How dangling records happen to careful teams

Nobody plans a dangling CNAME. They accumulate through ordinary entropy: marketing tools adopted and dropped, a contractor's staging environment, a migration that moved the app but not the DNS zone, a free-tier platform that deleted an inactive project. DNS zones only grow — deleting a record feels risky, so records outlive the things they point to. This is why takeover is consistently among the most-reported issues on bug bounty programs.

How to find dangling CNAMEs in your own zone

1. Enumerate your subdomains. Your DNS provider's zone export is the ground truth for records; certificate transparency logs reveal hosts that got certificates over the years, including ones missing from your current mental inventory.
2. Resolve every CNAME and note where it lands — especially names ending in platform suffixes: github.io, herokuapp.com, azurewebsites.net, s3.amazonaws.com, cloudfront.net, netlify.app and similar.
3. Check what answers. A provider error page like "There isn't a GitHub Pages site here" or an NXDOMAIN on the target is the signature of a claimable resource. Each platform has its own tell; community-maintained lists (such as the "can-i-take-over-xyz" project) document which providers are actually claimable.
4. Repeat on a schedule. The zone you audited in January is not the zone you have in June. This is a textbook job for continuous external monitoring — Bastion, for instance, watches CT logs for new subdomains on your verified domains and flags CNAMEs that resolve to unclaimed platform endpoints.

Prevention: order of operations

The whole class of bug reduces to one rule: DNS dies first. When decommissioning anything a DNS record points at, remove or repoint the record before deleting the resource. Add it to the offboarding checklist for vendors and campaigns. Where platforms support it, verify domain ownership with the platform (many now require TXT-record proof precisely to prevent takeovers) so a deleted resource name cannot simply be re-claimed against your domain.

Frequently asked questions