The Name That Points Nowhere: A Dangling CNAME Takeover
The challenge
Kestrel Bank keeps a tidy DNS zone, which is the problem. One of its subdomains still has a CNAME pointing at a cloud bucket that the marketing team deleted when a campaign ended. The name resolves, the target does not exist, and anyone can walk up to that cloud provider and claim the empty name. Whoever does gets to serve content from a genuine kestrelbank.example address. Cross-reference the records and name the subdomain that can be taken over.
What you'll learn
- Explain how a CNAME to a deprovisioned resource becomes claimable
- Recognise a provider's does-not-exist response as a takeover signature
- Cross-reference a DNS export against live probes to find the dangling record
- Describe the impact of serving content from a real subdomain
- State the safe decommissioning order for DNS and cloud resources
Skills tested
Prerequisites
- What a CNAME record is
- The idea of cloud buckets / hosted resources
How it works
A subdomain takeover is possible when a DNS record points at a third-party resource that has been deleted but whose name anyone can re-create. The record still resolves; the thing it resolves to is an empty slot waiting to be claimed.
The tell is the target's response. A live target answers normally; a claimable one returns the provider's does-not-exist error, such as NoSuchBucket. That means the resource was torn down while the CNAME pointing at it was left behind.
Claiming the name lets an attacker serve content from a genuine subdomain of the victim, which carries real trust: cookies scoped to the parent domain, customer familiarity and the ability to obtain a valid certificate.
Common mistakes
- Picking a live subdomain. status, docs and login all point at targets that answer normally.
- Blaming the deleted bucket. The bucket being gone is fine; the leftover CNAME is the vulnerability.
- Answering the target host. The takeover-able name is the Kestrel subdomain, not the cloud target it points at.
- Ignoring the probe. Without checking each target's response you cannot tell the dangling record from the healthy ones.
How to defend against it
Tie DNS lifecycle to resource lifecycle.
- Remove or repoint a DNS record at the moment the resource behind it is decommissioned. Delete the record before the resource, or hold the name.
- Adopt a teardown checklist so DNS cleanup is never the step that gets left open.
- Continuously scan your zones for CNAMEs whose targets return known takeover signatures, across every provider you use.