wiredepth
Run a check

Free tool · Subdomain hygiene

Subdomain takeover checker

A subdomain takeover happens when DNS for foo.example.com still points (via CNAME) at a third-party service hostname, but the resource at that service has been deleted or never claimed. Anyone can then re-register the identifier on that service and serve content under your subdomain - phishing, malware, cookie theft via the parent domain. Paste a subdomain, we walk the CNAME chain and pattern-match against 20+ known-vulnerable services.

What this tool checks

Takeovers are an artifact of the way SaaS custom-domain mappings work. You add a CNAME from blog.example.com to example.zendesk.com so your Zendesk shows up on your domain. Years later the Zendesk account is closed but nobody pulls the CNAME. Anyone who notices can register a fresh Zendesk account using the same subdomain identifier + serve content at blog.example.com. The browser shows a valid TLS chain (your subdomain) and the site loads cleanly: a perfect phishing surface.

Detection has two parts. First, the CNAME chain itself - is the target hostname pattern one of the known-vulnerable services? Second, does the chain resolve to live A records, or does it dangle? A dangling chain plus a known-vulnerable pattern is a near-certain takeover. A live chain plus a vulnerable pattern is a future-risk surface to track.

We ship 20+ service fingerprints curated from can-i-take-over-xyz + 2024-2026 bug-bounty disclosures: GitHub Pages, AWS S3, Azure App Service / CloudApp / CDN / Traffic Manager, Zendesk, Help Scout, Intercom, Atlassian Statuspage, Tumblr, Shopify, WordPress.com, Netlify, Vercel, Surge, Bitbucket Pages, Read the Docs, Fly.io, Firebase Hosting, Pantheon, and UserVoice. We intentionally exclude services that have patched the underlying takeover vector upstream.

How to read the results

Verdict tiers:

  • Likely vulnerable: CNAME points at a known-vulnerable service AND the chain dangles (no final A record). Browse to the host - if you see the service's "no such site" page, this is exploitable today.
  • Worth verifying: known-vulnerable service in the chain, but the chain still resolves to live IPs. Future-risk: if the underlying resource is ever deleted without removing the CNAME, this becomes exploitable.
  • Clean: CNAME chain resolves and no hop matches a known-vulnerable service pattern.
  • No CNAME: name resolves directly to A records (or doesn't resolve at all). Takeover- via-dangling-CNAME isn't the relevant risk for this name.

How to remediate a flagged takeover: pick one - either remove the CNAME from DNS, or re-claim the resource at the third-party service so the identifier points back at content you control. Doing nothing means the exploit window stays open.

Frequently asked questions

Why only subdomains - can example.com itself be taken over?

The apex (example.com) is rarely vulnerable in this way because apex CNAMEs are forbidden by DNS (ALIAS / ANAME records are the usual workaround and they resolve to A records dynamically). Subdomains are the surface because they freely allow CNAME records, and SaaS custom-domain mappings universally use CNAMEs.

How is this different from a CT-log subdomain enumeration?

Enumeration finds the list of subdomains; takeover checking tells you which of those subdomains have dangling CNAMEs. Both useful together: enumerate to build the inventory, then takeover-check each candidate. The full Wiredepth platform combines these for Pro+ tiers.

My subdomain is flagged but I still control the underlying resource - false positive?

If the resource is still claimed in your third-party account and the service is actively serving your content, the CNAME chain should resolve to live A records and the verdict should be 'Worth verifying' (not 'Likely vulnerable'). 'Likely vulnerable' = chain dangles. If you see the live verdict but you've confirmed the resource is yours, no action needed; the entry is informational so you can monitor for future change.

What does "high / medium / low confidence" mean in the fingerprint match?

High = the service has a well-documented historical takeover vector AND no upstream protection. Medium = takeover vector exists but service vendor has partial protection (e.g., requires SSO verification before claiming). Low = the pattern matches a service that has historically been vulnerable but the vendor has substantially mitigated the issue; included for awareness but unlikely to be actively exploitable.

Can attackers find dangling subdomains automatically?

Yes. Public CT-log mining + nightly DNS sweeps + the same fingerprint patterns we use are commodity tooling now. Mature bug-bounty programs and red-team operators run continuous scans. Assume any dangling CNAME on your domain will be found within 24-48 hours.

Related free tools

Subdomain enumeration

Pulls the historical CT-log inventory so you can scan each subdomain in turn.

DNS health

Full DNS posture: SOA, NS, MX, CAA, registrar expiry, mail blocklists.

CAA records

Restricts which CAs can issue certs for your domain - companion control against cert misissuance after takeover.

DNSSEC

Validates your DNS chain so CNAME records cannot be tampered with in transit.