Subdomain Takeover: Risks and How to Prevent It

A subdomain takeover is the hijacking of a legitimate subdomain that happens when a DNS record (usually a CNAME) still points to an external service that has already been deprovisioned, leaving the record dangling and free for an attacker to claim that resource and serve content under your domain. The root cause is not a specific software bug but an operational mismatch: someone deletes an Amazon S3 bucket, a GitHub Pages site or an Azure resource, yet forgets to remove the DNS record that referenced it. That orphaned record (dangling DNS) is the doorway.

This guide explains what a subdomain takeover is, how dangling DNS occurs, which cloud services are most affected, the real risks to an organisation, the tooling and discovery flow an offensive team uses, and the DNS hygiene required to prevent it.

Key takeaways on subdomain takeover

• It happens when a CNAME (or A/ALIAS record) points to an external service that is already deprovisioned and claimable.
• Frequent services: Amazon S3, GitHub Pages, Azure (App Service, CDN, Traffic Manager), Heroku, Fastly, Shopify, Zendesk.
• Impact goes well beyond defacement: phishing under a trusted domain, session cookie theft, CORS and CSP allowlist bypass, TLS certificate issuance.
• Discovery: subfinder, amass, dnsx, httpx and nuclei with takeover templates, plus the can-i-take-over-xyz fingerprint list.
• Prevention: delete the DNS record before deprovisioning the resource, keep an asset inventory, monitor continuously and verify domain ownership at the provider.

What a subdomain takeover is

A subdomain takeover is a configuration vulnerability, not a flaw in an application's code. That is why it is rarely assigned a CVE: it is not a defect in a specific product but an insecure state of an organisation's DNS infrastructure. The OWASP testing standard records it as WSTG-CONF-10 (Test for Subdomain Takeover) and MITRE ATT&CK maps it to technique T1584.001 (Compromise Infrastructure: Domains), because an attacker who controls payments.yourcompany.com has not compromised your network, they have compromised your identity.

The mechanism is simple. A victim's browser resolves blog.yourcompany.com, follows the CNAME to yourcompany.github.io (or yourcompany.s3.amazonaws.com, or an Azure endpoint), and the provider answers. If the resource that CNAME points to no longer exists but anyone can recreate it under the same name, the attacker claims it, and from that moment the provider serves the attacker's content under your subdomain, with your brand, your certificate and your reputation.

How dangling DNS occurs

The sequence that creates a takeover is almost always the same operational mistake:

1. A team publishes a microsite, a landing page or documentation on a managed service and creates the matching CNAME.
2. Months later the project is archived. Someone deletes the resource at the provider (removes the bucket, disables the Pages site, tears down the App Service).
3. Nobody removes the CNAME. The DNS record keeps pointing at nothing.
4. An attacker enumerating subdomains spots the dangling record, identifies the provider by its characteristic error page, and claims the free resource.

Order matters. The underlying failure is deprovisioning the resource before deleting the DNS record. Reversing that order (delete the record first, then the resource) closes the exposure window entirely.

Cloud services typically affected

Not every service is equally vulnerable. The necessary condition is that the provider lets someone claim a released resource name without verifying domain ownership. The recurring historical cases:

• Amazon S3: a deleted bucket returns NoSuchBucket. If the CNAME points to the bucket name and it becomes free, anyone re-registers it.
• GitHub Pages: the There isn't a GitHub Pages site here page is the classic fingerprint. The attacker creates a repository with a CNAME to the subdomain and captures it.
• Azure: App Service, Blob Storage, Traffic Manager and CDN have all shown claimable variants when the endpoint (*.azurewebsites.net, *.trafficmanager.net) is left orphaned.
• Heroku, Fastly, Shopify, Zendesk, Surge, Netlify, Read the Docs: all appear in public bug bounty reports (Uber, Starbucks and others) with known fingerprints.

The community reference is the can-i-take-over-xyz list (maintained by EdOverflow and contributors), which catalogues each service, its fingerprint, and whether the takeover is exploitable or already mitigated by the provider.

Real risks of a subdomain takeover

The most common mistake is treating it as a minor defacement. The real impact depends on the subdomain's context and is usually serious:

• Phishing under a trusted domain. A cloned login page on access.yourcompany.com defeats any anti-phishing training based on checking the domain. The URL is legitimate and the TLS padlock is green.
• Session cookie theft. If the application sets cookies with Domain=.yourcompany.com, the hijacked subdomain receives them. It is a direct path to session theft with no need for an XSS in the main application.
• Trust allowlist bypass. A CORS policy that trusts *.yourcompany.com, or a CSP that allows scripts from any subdomain, becomes a hole: the attacker serves JavaScript from the captured subdomain and jumps the restriction.
• TLS certificate issuance. By controlling the subdomain, the attacker passes the Let's Encrypt ACME challenge and issues a valid certificate, making the deception indistinguishable.
• OAuth and email reputation abuse. A redirect_uri that trusts the subdomain, or associated mail records, enable token theft and impersonation backed by the legitimate domain's reputation.

Discovery: tooling and flow

Finding dangling records is a reconnaissance task. It falls within the standard scope of an external infrastructure pentest and of any OSINT exercise over an organisation's public surface. The usual toolkit:

• Subdomain enumeration: subfinder, amass, assetfinder and findomain, complemented with Certificate Transparency logs via crt.sh, which reveal subdomains that never appeared in a public DNS.
• Resolution and CNAME chasing: dnsx to resolve in bulk and follow the CNAME chain to the final target.
• Probing and fingerprinting: httpx to detect which subdomains respond, and nuclei with the takeover tag (nuclei -tags takeover), which applies hundreds of fingerprints automatically.
• Dedicated detectors: subzy, subjack, tko-subs and dnsReaper (by Punk Security) specialise in confirming candidates.
• Visual evidence: aquatone produces screenshots of every live subdomain for quick review.

Step-by-step detection flow

# 1. Passively enumerate subdomains
subfinder -d yourcompany.com -all -silent -o subs.txt

# 2. Resolve and capture CNAME records
dnsx -l subs.txt -cname -resp -silent -o cnames.txt

# 3. Probe those that answer over HTTP/HTTPS
httpx -l subs.txt -silent -o live.txt

# 4. Look for takeover fingerprints
nuclei -l live.txt -tags takeover

# 5. Confirm candidates with a dedicated detector
subzy run --targets subs.txt

The decision logic is always the same: resolve the subdomain, follow the CNAME chain, and if the final target returns NXDOMAIN or responds with a known provider's claimable error page, the subdomain is a takeover candidate. Actual confirmation (claiming the resource) should only be done with written authorisation, as part of a contracted Red Team or pentest exercise.

Prevention and DNS hygiene

Defence combines operational process and monitoring. The controls a mature team applies:

• Correct decommission order. Document and enforce that the DNS record is removed before or at the same time as the cloud resource, never afterwards. This is the control that closes the window at the root.
• DNS as code. Manage zones with Terraform or equivalent tooling, so every record has an owner, a history and passes review. An orphaned CNAME shows up in the diff.
• A live asset inventory. You cannot protect what you do not know exists. An inventory of subdomains and their targets, reviewed regularly, is the foundation.
• Domain verification at the provider. GitHub, Azure and AWS offer ownership verification (asuid TXT records, verified organisation domains, using the domain name as the bucket name) that prevents a third party from claiming the resource even if the CNAME stays dangling.
• Continuous monitoring. Run nuclei -tags takeover or dnsReaper on a schedule (ideally in CI/CD) and watch Certificate Transparency logs (crt.sh, Cert Spotter) for unexpected certificates issued against your domains.
• Avoid wildcards and orphaned delegations. A wildcard CNAME to a third party widens the surface. And a more serious variant, the NS takeover, appears when a delegation (NS) points to a hosted zone you no longer control: review and remove stale delegations.

When the at-risk subdomain points to cloud infrastructure, the review fits naturally into a cloud audit for AWS, Azure or GCP, where resource inventory and DNS records are cross-checked systematically. And for the full public surface, active reconnaissance with Google Dorks and footprinting helps discover forgotten subdomains before an attacker does.

Frequently asked questions

Does a subdomain takeover have a CVE?

Usually not. It is a configuration vulnerability specific to each organisation, not a defect in a software product, so it is not assigned a CVE identifier. It is documented as a finding in pentest and bug bounty reports and referenced against the OWASP WSTG-CONF-10 standard.

Is deleting the cloud resource enough to be safe?

No, that is precisely the mistake that causes the problem. If you delete the bucket, the App Service or the Pages site but leave the CNAME pointing at it, you create the dangling record that enables the takeover. You must remove the DNS record, not only the resource.

How do I know if a subdomain is vulnerable?

Resolve the subdomain, follow its CNAME chain and check the final target. If it returns NXDOMAIN or shows a known provider's claimable error page (for example S3's NoSuchBucket or There isn't a GitHub Pages site here), it is a candidate. Tools such as nuclei, subzy or dnsReaper automate that check.

What is the difference between a subdomain takeover and an NS takeover?

A subdomain takeover hijacks a single subdomain via a dangling CNAME. An NS takeover hijacks an entire zone delegation: if an NS record points to nameservers you no longer control and are claimable, the attacker takes control of the whole delegated zone, a far larger impact.

How often should DNS be reviewed?

Continuously for large domains with many subdomains, and at minimum on every project or service decommission. Integrating takeover checks into the CI/CD pipeline and watching Certificate Transparency shrinks the exposure window to hours instead of months.

Related resources

• What is OSINT: the open source intelligence discipline where subdomain enumeration is a mandatory step.
• Google Dorks and footprinting: how to discover forgotten subdomains and assets from public sources.
• External infrastructure pentesting: the exercise where subdomain reconnaissance and takeover are part of the scope.
• Cloud pentesting for AWS, Azure and GCP: the audit that cross-checks cloud resources against their DNS records.
• What is CORS and its misconfigurations: why trusting *.yourdomain.com turns a takeover into an API compromise.

Subdomain takeover at Secra

At Secra, hunting for dangling subdomains is part of the standard reconnaissance in our Red Team engagements and infrastructure pentests. We enumerate your full subdomain surface, follow every CNAME chain, identify dangling records and claimable resources, and confirm exploitable takeovers with reproducible evidence and no impact on production. If your organisation accumulates archived projects, cloud migrations or subdomains nobody remembers, reach out through contact or take a look at our Red Team service.