Skip to content
SysGlass
Discovery diagnostic

Subdomain Takeover Audit

Enter a hostname and SysGlass checks for a subdomain takeover: a CNAME that points at a third-party service (GitHub Pages, Heroku, AWS S3, Azure, Shopify, Fastly and ~40 more) where the backing resource has been deleted or never claimed. When that happens, an attacker can register the resource and serve their own content on your domain — phishing your users, stealing cookies, or passing your TLS. We follow the CNAME, match it against a verified fingerprint database, and confirm the unclaimed signal.

Reviewed by the SysGlass team · Updated July 21, 2026

What it checks

  • The host's CNAME chain (via DoH, so dangling records are still seen)
  • Whether the CNAME points at a known takeover-prone service
  • For HTTP services: whether the page shows the service's 'unclaimed' fingerprint
  • For DNS-level services (Azure, Elastic Beanstalk): whether the CNAME target no longer resolves (NXDOMAIN)
  • A clear vulnerable / dangling / safe verdict with the evidence

How to read the result

  • Fail (vulnerable) = the CNAME points at an unclaimed service resource — an attacker can take it over. Remove the record now.
  • Warn (dangling) = the CNAME target no longer resolves; remove or repoint it.
  • OK = no CNAME, or the CNAME points at a claimed/owned resource.
  • Run it on every subdomain you find with the Subdomain Finder.

Frequently asked questions

What is a subdomain takeover?

It happens when a subdomain's DNS (usually a CNAME) still points at a third-party service whose resource was deleted. The service will serve content for that hostname to whoever next claims the resource — so an attacker registers it and controls your subdomain.

Why is it dangerous?

An attacker serving content on your real subdomain can run convincing phishing, set cookies on your domain, bypass same-origin protections, and obtain TLS certificates for your name. It's a high-severity issue.

How do I fix it?

Remove the dangling CNAME from your DNS, or re-claim the resource at the third-party service. The rule: never delete a hosted resource while a DNS record still points at it.

Which services do you check?

About 49 services from the community can-i-take-over-xyz dataset — GitHub Pages, Bitbucket, Surge, Heroku, Pantheon, AWS S3 / Elastic Beanstalk, Azure, Shopify, Tumblr, Fastly, Zendesk, Statuspage and more — each with its verified unclaimed-resource fingerprint.

Related Discovery tools