Subdomain Takeover: How It Happens and How to Prevent It

A subdomain takeover happens when one of your DNS records points to a resource that no longer exists, and an attacker claims that resource. They then control content served on your subdomain, such as promo.example.com, with your brand and your domain's trust.

How it happens

1. Your team creates docs.example.com as a CNAME to a hosted service, for example a static site host, cloud storage bucket or SaaS helpdesk.
2. Later, the project ends and the hosted resource is deleted.
3. Nobody removes the DNS record. It now "dangles," pointing to an unclaimed name.
4. An attacker creates a resource with the same name on the same platform.
5. docs.example.com now serves the attacker's content.

Why it is serious

• Phishing on your domain: login pages hosted on a real subdomain are highly convincing.
• Cookie theft: if session cookies are scoped to .example.com, the attacker's subdomain may receive them.
• CORS and CSP bypass: if your app trusts *.example.com, the attacker's subdomain is trusted too.
• OAuth abuse: redirect URIs allowing subdomains can send tokens to the attacker.
• Reputation damage: malicious content or malware served from your brand.

Common vulnerable patterns

• CNAMEs to deleted cloud storage buckets or static website endpoints.
• CNAMEs to deprovisioned platform-as-a-service apps.
• Records pointing to SaaS tools, such as helpdesks, landing page builders or status pages, after cancellation.
• A records pointing to released cloud IP addresses, which another customer may later receive.
• NS delegations to DNS zones that were deleted.

Each platform behaves differently; some have added protections, others remain claimable. Community-maintained lists track which services are vulnerable.

How to prevent takeovers

1. Remove DNS records before deleting resources, not after. Make it part of your decommissioning checklist.
2. Inventory your DNS regularly and match every record to a live, owned resource.
3. Manage DNS as code, so records are reviewed and their purpose is documented.
4. Avoid wildcard trust of subdomains in CORS, CSP, OAuth and cookies.
5. Use platform verification features, such as domain verification records, where providers offer them.
6. Monitor continuously, because takeovers become possible the moment a resource is deleted.

Finding takeover candidates

Detection involves enumerating subdomains through DNS, certificate transparency logs and other sources, resolving each record, and checking whether the target responds with a platform's "no such resource" signature. It is a continuous problem: a subdomain safe today can dangle tomorrow.

SecurityInfinity's attack surface agents discover subdomains, resolve their targets and flag dangling records that could be claimed, before an attacker does. Start free.

Frequently asked questions

How do attackers find dangling subdomains?

They enumerate subdomains from certificate transparency logs, DNS datasets and brute forcing, then check each one for known unclaimed-resource responses.

Is a subdomain takeover a critical vulnerability?

Often high, and it can be critical if cookies, OAuth or trust relationships with the main application are affected.

What should I do if I find one?

Claim or delete the target resource immediately, remove the DNS record, and check logs for signs of misuse.