Subdomain Takeover Risk Explained
How subdomain takeovers happen, why dangling DNS records enable them, and how to catch the risk early.
Core Concept
A subdomain takeover happens when a DNS record still points to a third-party resource — such as a cloud storage bucket or hosting platform — that has since been deleted or deprovisioned.
Because the record is never removed, an attacker can register the same resource on the third-party platform and effectively serve their own content under the legitimate domain's name.
How a Takeover Typically Unfolds
- A team points a subdomain's CNAME record at a third-party service, such as a static site host or CDN endpoint
- The service is later cancelled, deleted, or the project is abandoned
- The DNS record pointing at that now-unclaimed resource is never cleaned up
- An attacker registers the same resource name on the third-party platform
- Traffic to the subdomain now resolves to content the attacker controls
Why It's Common
DNS cleanup is rarely part of a formal offboarding checklist, so dangling records accumulate quietly over years of infrastructure change.
Why This Poses a Real Risk
Content served under a legitimate domain name inherits an unusual amount of implicit trust, making a taken-over subdomain a convincing platform for phishing, credential harvesting or malware distribution.
The subdomain also inherits the parent domain's reputation with browsers and security tools, which can make the malicious content harder to detect through conventional filtering.
Spotting Takeover-Prone Subdomains
Subdomains flagged as dead in an enumeration scan are the natural starting point for takeover review, particularly ones whose DNS records still point to a third-party CNAME target.
- A dead subdomain with a CNAME pointing at a cloud or SaaS platform
- A resource name that suggests a decommissioned project or campaign
- Subdomains that haven't returned a valid response in scan history
Common Platforms Affected
Many popular hosting, storage and SaaS platforms have historically been associated with takeover risk when a resource name becomes available for re-registration after deletion.
The specific platforms and their exact takeover conditions change over time as providers patch the underlying issue, so any takeover review should verify current behavior rather than relying on outdated assumptions.
Real-World Implementation
Takeover-focused subdomain review is now a standard step in many bug bounty programs, internal red team engagements, and continuous attack-surface monitoring pipelines.
Organizations with mature security programs often maintain an internal inventory of every DNS record tied to a third-party service, so decommissioning includes a DNS cleanup step by default.
Common Mistakes to Avoid
- Deleting a third-party resource without removing the DNS record pointing at it.
- Assuming a dead subdomain is harmless simply because it doesn't resolve.
- Overlooking CNAME records when reviewing subdomain scan results.
- Treating takeover review as a one-time task rather than a recurring check.
- Failing to track which subdomains point to which third-party services internally.
- Assuming takeover risk only applies to obscure or unknown platforms.
- Not verifying current platform behavior before ruling a subdomain safe.
- Ignoring subdomains left over from marketing campaigns or short-lived projects.
- Skipping DNS cleanup during vendor or service migrations.
- Assuming a low subdomain count means low takeover risk.
Best Practices Checklist
- Make DNS record cleanup a required step when decommissioning any service.
- Review dead subdomains from every scan for lingering third-party CNAMEs.
- Maintain an internal inventory of subdomains mapped to external services.
- Re-scan periodically to catch newly dangling records early.
- Verify current takeover conditions for the specific platform in question.
- Prioritize cleanup for subdomains with brand-relevant or trusted-sounding names.
- Include takeover checks in routine attack-surface monitoring, not just one-off audits.
- Assign clear ownership for DNS hygiene during project offboarding.
Frequently Asked Questions
Is subdomain takeover always exploitable?
Not automatically — it depends on the specific platform's current handling of unclaimed resource names, which changes as providers patch known issues.
How do I know if my subdomain is vulnerable?
Check whether a dead subdomain's DNS record still points to a third-party resource that no longer exists on that platform.
Does deleting the DNS record fix the risk?
Yes — removing the dangling record eliminates the takeover path entirely.
Can A records be vulnerable, not just CNAMEs?
Takeover risk is most commonly associated with CNAME records pointing to third-party services, though similar dynamics can apply to other record types depending on the provider.
Is this only a risk for large organizations?
No — any domain using third-party hosting or SaaS platforms can accumulate dangling records over time, regardless of size.
How often are subdomain takeovers found in the wild?
They remain a regularly reported finding in bug bounty programs, which reflects how easily DNS cleanup gets missed during routine operations.
Can a subdomain scan detect takeover risk directly?
A scan can flag dead subdomains and their record types as a starting point, but confirming exploitability requires checking the specific platform's current state.
What's the fastest fix once a dangling record is found?
Remove or repoint the DNS record immediately, since that closes the takeover path regardless of the platform involved.
Check for Dead Subdomains
Scan a domain and review dead hosts for potential takeover risk.
Launch Tool →