Subdomain Takeover Auditor — Find Claimable DNS Records

A team decommissions a service — an S3 bucket, a Heroku app, a GitHub Pages site — and forgets the DNS record pointing at it. That record now dangles: it resolves, but to a third-party resource nobody at the company owns anymore. Whoever claims that resource on the other service now controls a subdomain of a trusted brand.

That is used for credential phishing, cookie theft, and bypassing domain allowlists — and it happens constantly, because nobody owns stale DNS. AWS has published a threat spotlight on exactly this pattern.

Entirely passive. No scanning, no login, no port probing.

How it works — three legal steps

1. Enumerate subdomains from certificate transparency (crt.sh). Public logs, not a scan — every subdomain that ever got a TLS certificate shows up here.
2. Resolve CNAMEs over DNS-over-HTTPS. A lookup, not a probe.
3. Match against a public takeover-fingerprint database (EdOverflow's can-i-take-over-xyz, 76 catalogued services). Only when a CNAME matches a known-vulnerable pattern is the already-public page fetched once, to confirm the exact string that means "unclaimed."

The three verdicts

Risk	Meaning
claimable	The fingerprint is confirmed on the live page (or DNS returns NXDOMAIN for a service known to signal that way). High confidence — fix this.
suspicious	The CNAME matches a vulnerable service's pattern, but the page couldn't confirm it. Needs a human look — not claimed as a finding.
ok	No match, or the resource is clearly still in use.

Confidence is never claimed without evidence. A pattern match with an inconclusive page fetch is suspicious, not claimable — this actor will not tell you something is exploitable unless it actually confirmed it.

Input

{ "domains": ["yourcompany.com"] }

That's it. You do not list subdomains — they are discovered automatically.

Sample output

[
  {
    "subdomain": "old-blog.yourcompany.com",
    "apexDomain": "yourcompany.com",
    "cname": "yourcompany.github.io",
    "matchedService": "GitHub Pages",
    "risk": "claimable",
    "verdict": "CNAME points at GitHub Pages (yourcompany.github.io), and the page confirms the \"not claimed\" fingerprint (\"There isn't a GitHub Pages site here.\"). This subdomain can very likely be claimed by anyone right now. Delete the DNS record, or claim the resource yourself.",
    "confidence": "high"
  }
]

Typical uses

• Attack-surface hygiene — the classic use. Run it monthly; services get decommissioned continuously and this never stops finding new ones.
• Pre-acquisition / vendor due diligence — audit a company's subdomains before you inherit their DNS debt.
• Agency deliverable — a "3 claimable subdomains on your own domain" finding is a concrete, demonstrable result that sells security or DevOps engagement work far better than a generic pitch.
• Bug bounty recon — this is the same technique bounty hunters use, done for your own domains.

Pricing

$2.50 / 1,000 subdomains checked ($0.0025 per result), plus a near-zero start fee. A typical domain with a few hundred subdomains costs well under a dollar. Never charged beyond maxItems.

⚠️ Read before you act

• This is detection, not proof of active exploitation. A claimable finding means the resource can very likely be claimed — it does not mean anyone already has. Investigate before publicly disclosing or escalating.
• Only audit domains you own or are authorized to test. Certificate transparency and DNS are public, so no permission is needed to look — but acting on what you find on a domain you don't control is a different matter entirely.
• The fingerprint database is community-maintained and does not cover every service. A clean result reduces risk; it does not guarantee zero exposure.
• suspicious rows need a human. They exist so the actor never inflates a maybe into a confirmed finding.

FAQ

• Does this scan ports or bypass authentication? No. Every step reads public certificate logs, resolves DNS, or fetches a page that anyone's browser could load.
• Will this get me blocked or flagged? No — there is no scanning behavior to trigger a WAF or IDS. It behaves like a normal browser visiting a public page.
• Why is confirmWithPageCheck optional? Turning it off is faster (no page fetches) but every match is then reported as suspicious rather than claimable, since nothing confirmed it.
• What if my domain has thousands of subdomains? Raise maxSubdomainsPerDomain and maxItems. Certificate transparency logs can be large for big companies.

Related actors

• Typosquat Monitor — the same idea from the other direction: lookalike domains registered to impersonate you, rather than your own DNS pointing at nothing.
• SSL Certificate Checker — expiry and validity for certificates you do control.
• Broken Link Resurrector — dead links on your own site, with the archived fix.