Subdomain Takeover: How Dangling DNS Records Get Hijacked — and How to Find Them
A subdomain takeover happens when a DNS record still points at a service you no longer own. Here's how dangling CNAMEs get hijacked, what an attacker can do with one, and how to detect and close them.
Editorial disclosure: Pyalm publishes and maintains the products and free tools discussed on this site. Regulatory statements are linked to primary sources where applicable. No independent professional review is claimed unless a reviewer is explicitly named.
A subdomain takeover is one of the quietest ways to lose control of part of your domain. Nobody breaks into a server. No password is stolen. A DNS record simply keeps pointing at a service you stopped using — and someone else claims the other end.
What a subdomain takeover actually is
Most subdomains don't resolve to your own servers. They CNAME to a third-party service: a marketing site on a SaaS host, a docs portal, a status page, a storage bucket, a support widget. The record says "for help.example.com, go ask this provider."
The problem starts when you decommission that service but leave the DNS record behind. Now help.example.com points at a hostname the provider no longer has assigned to anyone. That's a dangling CNAME. If the provider lets a new customer claim that hostname, whoever claims it now controls content served at your subdomain.
Why it matters more than it looks
A subdomain you forgot about is still your domain to a browser, a user, and often a cookie. An attacker who takes one over can:
- Phish with a real domain. A login page on
portal.example.comis far more convincing than any lookalike domain. - Steal cookies and tokens scoped to
*.example.com, depending on how yours are set. - Bypass allowlists — CSP
frame-ancestors, CORS rules, and OAuth redirect allowlists that trust your own subdomains now trust the attacker. - Damage reputation by hosting spam or malware under your brand.
How to find dangling records
Detection is really two questions asked across every subdomain you have:
- Do I even know all my subdomains? Enumerate them from certificate-transparency logs, passive DNS, and a brute-force wordlist. You can't check records you don't know exist.
- Does each CNAME still resolve to a claimed resource? For every subdomain that CNAMEs to a third party, confirm the target still exists and is still yours. A CNAME that resolves to a provider's "no such site" fingerprint is the red flag.
Doing this by hand across a real domain is tedious, which is exactly why forgotten records survive. Automated attack-surface tooling handles both halves — enumerating subdomains and flagging dangling CNAMEs before someone else finds them. For an assessment on a domain you own, our sister company Defense Net Solutions does this work.
How to prevent them
- Delete the DNS record the moment you retire a service — make it a step in your decommissioning checklist, not an afterthought.
- Enumerate on a schedule. Attack surface grows quietly; a quarterly sweep catches records that outlived their service.
- Prefer records you control for anything sensitive, and avoid wildcard CNAMEs that mask individual dangling entries.
- Claim before you cancel where a provider allows it, so there's no window between "you stopped paying" and "the hostname is free."
The fix is almost always a one-line DNS deletion. The hard part is knowing which line — and that's a discovery problem, not a security-genius problem.
Related reading
Assess your attack surface with Defense Net Solutions | Introducing Pyalm Guard | SPF, DKIM & DMARC explained | HTTP security headers guide