The subdomain you forgot, that someone else can claim
Point a subdomain at a cloud resource — an S3 bucket, a GitHub Pages site, a Heroku app — then delete the resource but leave the DNS record behind, and you’ve created a dangling pointer to nothing. Anyone can re-register that exact resource and instantly serve their own content on your subdomain: phishing pages with your name on them, cookie theft, OAuth abuse. We detect these passively — a CNAME lookup plus a single read-only request. In 2025 researchers re-registered ~150 abandoned S3 buckets that once belonged to governments and Fortune 500s.
What the radar has done so far
A subdomain is counted takeover-able only when its CNAME delegates to a known service AND that service returns its “unclaimed” fingerprint (e.g. S3’s NoSuchBucket) — the same high-precision signal subjack and nuclei use. Confirmed cases are rare and serious; most delegations are live and claimed.
Why this matters
A taken-over subdomain isn’t “just a subdomain” — it inherits your domain’s trust:
- • Phishing that looks 100% legitimate — the page really is on your domain, so links, filters, and users all trust it.
- • Cookie & session theft — cookies scoped to
*.yourdomain.comcan be read from the hijacked subdomain. - • OAuth / SSO bypass & brand damage — redirect-URI allow-lists and email/SPF trust can be abused from a subdomain you no longer control.
The fix is free: delete the dangling DNS record, or re-claim the resource you still need.
By service
- GitHub Pages128 takeover-able of 4,042 delegated
- Strikingly14 takeover-able of 143 delegated
- Fastly10 takeover-able of 191 delegated
- Smugmug5 takeover-able of 284 delegated
- Heroku1 takeover-able of 2,203 delegated
- Canny1 takeover-able of 2 delegated
- Shopify0 takeover-able of 13,339 delegated
- Webflow0 takeover-able of 385 delegated
- Big Cartel0 takeover-able of 349 delegated
- Ghost0 takeover-able of 68 delegated
- Pantheon0 takeover-able of 65 delegated
- Tumblr0 takeover-able of 62 delegated
- Help Scout0 takeover-able of 34 delegated
- Hatena0 takeover-able of 30 delegated
- Wordpress0 takeover-able of 22 delegated
Are you exposed?
Check whether any of your subdomains point at a resource you no longer control — a free, passive scan of your internet-facing surface, no signup.
Check your exposure →How it works
How do you detect a takeover without claiming anything?
We resolve the subdomain’s CNAME; if it delegates to a known service, we make a single read-only GET and look for that service’s “unclaimed” response (e.g. “There isn’t a GitHub Pages site here”, “No such app”, “NoSuchBucket”). We never register or claim the dangling resource — that would be the attack.
Why is the takeover count usually low?
Because we hold it to a high bar — both the CNAME delegation and the unclaimed fingerprint must match. Most subdomains delegate to live, claimed resources. A confirmed takeover is rare, which is exactly why it’s worth surfacing.
Why don't you list the affected subdomains?
Publishing them would be a ready-made shopping list for attackers. We keep host names private for responsible disclosure to the owners and publish only aggregate counts. Use the scanner above to check your own subdomains.
Frequently asked questions
What is a subdomain takeover?
When a subdomain's DNS record (usually a CNAME) still points at a cloud resource that has been deleted — an S3 bucket, GitHub Pages site, Heroku or Azure app — an attacker can re-create that resource and serve their own content from your subdomain.
Why is a dangling DNS record dangerous?
The attacker controls a real subdomain on your domain, which enables convincing phishing, cookie and session theft, OAuth-redirect abuse, and bypass of domain-based trust. It is hard for users to spot because the subdomain genuinely belongs to you.
How does EchelonGraph detect subdomain takeovers?
It passively resolves subdomains and flags CNAMEs that point at unclaimed or deprovisioned third-party targets — the dangling fingerprint. It is detect-only and never claims the resource; results are aggregate and host-redacted.
How do I fix a dangling subdomain?
Remove or update the DNS record the moment you decommission the resource it points to, audit your DNS for CNAMEs aimed at services you no longer own, and reclaim the target resource if it is still available before an attacker does.
EchelonGraph-<Radar>/1.0 (+echelongraph.io/responsible-disclosure; support@echelongraph.io) and a From: support@echelongraph.io header. It is a single, passive, read-only check — we never log in, exploit, write, or read your data. Who we are, how we confirm exposures read-only, and how to opt out → Genuine requests also carry a signed receipt you can validate at /verify-scan.