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
- AWS/S30 takeover-able of 3 delegated
- Heroku0 takeover-able of 1 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.
EchelonGraph-<Radar>/1.0 (+echelongraph.io/responsible-disclosure; security@echelongraph.io) and a From: security@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.