What is a subdomain takeover?
A subdomain takeover happens when a subdomain an organization controls in DNS points to a resource the organization no longer owns, and an attacker claims that resource. The DNS record is a dangling pointer: it names a target that has been deleted, but the record itself was never removed. Whoever can register that target now serves content from a hostname the organization still publishes.
The usual shape is a dangling CNAME. A team created shop.acme.example as a CNAME to a SaaS or cloud endpoint, then canceled the service or deleted the resource without deleting the DNS record. The endpoint name is now unclaimed, and on providers that let anyone register an arbitrary endpoint name, the attacker registers the exact name the CNAME still points to.
shop.acme.example. 300 IN CNAME acme-shop.provider-app.example.If acme-shop.provider-app.example was deleted at the provider and the provider lets a new account claim that name, the attacker claims it. Now https://shop.acme.example resolves to the attacker's content, on the organization's own domain, with a valid certificate the attacker can obtain because they control the host.
Why it matters
A subdomain that belongs to a real company is a strong asset for an attacker. It carries the trust of the parent domain, so phishing hosted on it is far more convincing. It can receive cookies scoped to the parent domain (.acme.example), enabling session theft. It is often on an allowlist for CORS, OAuth redirect URIs, or a content security policy, so takeover can pivot into account compromise on the main application. And it can host malware or serve as a redirect that a scanner trusts.
Which providers are vulnerable?
Whether a given service is vulnerable is not fixed. It depends on whether the provider verifies domain ownership before letting an account claim an endpoint name, and providers change that behavior over time. Do not assume any specific service is or is not exploitable today. The community-maintained can-i-take-over-xyz project tracks the current status per service, with a fingerprint (a response string or an NXDOMAIN condition) for each, and marks each as vulnerable, not vulnerable, or an edge case. Check it, and verify against the live service, rather than trusting a status you remember.
The two general conditions to reason about:
- Claimable endpoint names. Services that let any account register an arbitrary endpoint name are exploitable when a record dangles to a freed name. Object-storage and app-hosting platforms have historically fallen into this category under some configurations.
- NXDOMAIN dangles. If a
CNAMEpoints to a hostname that no longer resolves at all (NXDOMAIN), and the provider's DNS lets someone create that exact zone or record, the subdomain can be taken over even without a claimable app endpoint.
Many providers have added ownership verification specifically to close this, which is why a service that was exploitable one year is not the next. Hedge accordingly and confirm live.
How do you detect it?
Detection is a DNS-first exercise: find records that point somewhere, then check whether the target is actually claimed.
- Enumerate subdomains. Pull them from certificate transparency logs, DNS brute-forcing, and your own DNS zone exports. The zone you control is the authoritative starting list.
- Resolve each and read the chain. Use
digto see where a name actually points:
dig shop.acme.example CNAME +short
# acme-shop.provider-app.example.
dig acme-shop.provider-app.example +short
# (empty) -> the target does not resolve; investigate- Interpret the result. An empty answer or
NXDOMAINon the CNAME target is the strongest signal:
dig acme-shop.provider-app.example
# ... status: NXDOMAIN ...- Check the served response. Fetch the subdomain over HTTP and compare the body against the provider's known takeover fingerprint (for example a "no such app" or "bucket does not exist" style message). The fingerprints in can-i-take-over-xyz are the reference set.
- Confirm carefully. A takeover is proven by claiming the resource in a controlled way, not by a fingerprint alone. Do this only within an authorized rules of engagement, and never register a name to hold it hostage.
Run this continuously, not once. Subdomains and their targets change every time a team spins up or tears down infrastructure, so a clean scan is only clean for that moment.
How do you fix it?
The fix is DNS hygiene, and the durable version is ordering.
- Remove the DNS record when you deprovision the resource, and do it in the right order: delete the DNS record first, or at least confirm the resource is retained, before releasing the cloud resource. The gap between "resource deleted" and "record deleted" is the entire vulnerability window.
- Delete dangling records you already have. For every subdomain whose target no longer resolves or is no longer yours, remove the record.
- Prefer targets that cannot be re-registered by others. Where a provider offers domain-ownership verification or ties an endpoint to your account permanently, use it.
- Inventory and monitor. Keep an authoritative list of your DNS records and what each one points to, and alert when a target stops resolving. Ownership of DNS records should sit with a team, not scattered across whoever created them.
There is no application-layer patch and no WAF setting for this. It is a lifecycle problem: a record that outlived its target. It is closed by removing the record, and prevented by tearing down DNS and infrastructure together.
[ Sources ]
Written by Parameter · Last reviewed
