Subdomain Takeover: How It Works & How to Prevent It

A subdomain takeover is an attack where someone claims a subdomain you no longer control and serves their own content from it. It happens when a subdomain still has a DNS record pointing to a third-party service that has since been deleted or was never provisioned — a dangling DNS record. Because the subdomain still belongs to your domain, whatever the attacker publishes there inherits your brand's trust, cookies, and reputation.

How a subdomain takeover works

The root cause is almost always a dangling CNAME (or sometimes an A record) that points to an external platform. The typical sequence:

1. You create shop.example.com and point it via CNAME at a hosted service — say a GitHub Pages site, an S3 bucket, or a Heroku app.
2. Later you stop using that service and delete the resource — but you forget to remove the DNS record.
3. The subdomain now resolves to a platform that no longer has anything provisioned for it. The platform shows a generic "not found" page.
4. An attacker spots the dangling record, re-registers that exact resource name on the same platform, and now controls what shop.example.com serves.

The DNS record was never malicious — the danger is the gap between deleting the resource and removing the record that still points at it.

Why it is dangerous

• Trusted phishing. A login page on shop.example.com looks completely legitimate — it is your real domain, with a valid certificate if the platform issues one.
• Cookie and session theft. Cookies scoped to .example.com are sent to the hijacked subdomain, exposing sessions across the parent domain.
• OAuth and CORS abuse. If the subdomain is whitelisted as an OAuth redirect or a trusted CORS origin, an attacker can abuse those trust relationships.
• Reputation damage. Malware or scam content served from your own domain harms brand trust and can get the parent domain blocklisted.

Which services are commonly affected

Any platform where a subdomain name can be claimed by whoever asks first is a candidate: static hosting (GitHub Pages, GitLab Pages), cloud storage and CDNs (AWS S3, CloudFront, Fastly), app platforms (Heroku, Azure App Service), and SaaS tools (help desks, status pages, form builders). Each leaves a recognisable fingerprint on its unclaimed page — for example There isn't a GitHub Pages site here or an S3 NoSuchBucket error — which is exactly what both attackers and defenders look for.

How to detect subdomain takeovers

1. Enumerate every subdomain you have. You cannot secure what you have not listed. Start with the free subdomain finder to build a complete inventory.
2. Resolve each one and inspect the target. Look for CNAMEs pointing at third-party platforms, then check whether the platform actually serves your content or a generic "unclaimed" page.
3. Match the fingerprint. A dangling subdomain returning a known "no such site / bucket / app" message is a live takeover candidate.

Open-source tooling such as subjack, nuclei takeover templates, and the community can-i-take-over-xyz list catalogue the fingerprints for dozens of platforms.

How to prevent subdomain takeovers

• Deprovision in the right order. When retiring a service, remove the DNS record first (or at the same time), never leave it pointing at a deleted resource.
• Keep a DNS inventory. Track which subdomain points at which external service so orphaned records are obvious.
• Monitor continuously. Subdomains and their targets change constantly. One-off checks miss records created after the last audit — the same reason SSL certificate monitoring matters. Continuous discovery that re-checks your subdomains on every scan catches a dangling record before an attacker does; Secably's attack-surface monitoring is built for exactly this, or start with the free subdomain finder above.

Related guides

Subdomain takeover lives at the intersection of DNS and exposure. Understand the records involved — the CNAME record that usually dangles and the A record — and pair discovery with the subdomain finder to map your surface.

Frequently asked questions

What causes a subdomain takeover?

A dangling DNS record: a subdomain still points (usually by CNAME) to a third-party service whose resource has been deleted or never created, letting an attacker claim that resource and control the subdomain.

How do I know if a subdomain is vulnerable?

Enumerate your subdomains, resolve each, and look for ones pointing at an external platform that returns a generic "not found / no such bucket / no site here" page. That fingerprint means the resource is unclaimed and takeable.

How do I fix a dangling subdomain?

Remove the orphaned DNS record, or re-claim and properly configure the resource it points to. Going forward, always delete DNS records as part of decommissioning a service.