Subdomain Takeover Checker: Dangling DNS & Service Fingerprints

Check hostnames for dangling CNAMEs and takeover-prone hosting fingerprints (GitHub Pages, Heroku, AWS S3, Azure, Shopify, Netlify, Vercel, and dozens more). The actor is passive only: DNS-over-HTTPS lookups plus a plain HTTP(S) GET of the hostname. It never registers, claims or exploits anything.

Use it to:

• Find forgotten subdomains that still point at a SaaS or cloud host you cancelled.
• Bulk-check a list of hosts after an acquisition, MSP onboarding or DNS clean-up.
• Pull candidate names from Certificate Transparency when you only know the apex domain.
• Get a clear verdict with evidence, not a vague "maybe vulnerable" score.

Why this one

• Accuracy first. Fingerprints carry the source project's status (vulnerable / edge case / not vulnerable), so the actor does not overclaim. Edge-case services (GitHub Pages, Heroku, Netlify, Shopify…) are reported as POSSIBLE, not VULNERABLE.
• Clear evidence. Every finding includes the CNAME chain, the matched fingerprint string (or NXDOMAIN), a short body snippet, and a concrete recommendation.
• Bulk-friendly input. Paste hostnames, URLs or email addresses. Optional Certificate Transparency discovery (Cert Spotter, crt.sh fallback) expands an apex into subdomains.
• Honest DNS. NXDOMAIN, empty NOERROR and SERVFAIL/timeouts are kept separate. Failed lookups are retried, then sent to a second public resolver.

Passive method (what it does and does not do)

1. Resolve the CNAME chain for each hostname over DNS-over-HTTPS (Cloudflare, Google fallback).
2. Match the CNAME target against a maintained fingerprint list of takeover-prone services.
3. Optionally GET https:// and http:// the hostname (short timeout, small body, few redirects, honest User-Agent naming this actor) and match the provider's "not found / unclaimed" page text or status.
4. Emit a verdict with evidence.

It does not register domains, claim SaaS projects, send exploit payloads, or probe anything beyond DNS and a plain GET. Only run it on domains you own or are authorised to test. Every result row repeats that disclaimer.

Fingerprint source

Fingerprints are based on the public can-i-take-over-xyz project's fingerprints.json (commit 5bd4e128, dated 2025-02-08, fetched 2026-10-16). Each service keeps that project's status. A few CNAME suffixes were added so the actor can identify the service from the target alone (for example github.io, herokuapp.com, azurewebsites.net, trafficmanager.net).

Input

{
  "hostnames": ["www.example.com", "blog.example.com", "https://docs.example.net/"],
  "discoverFromCt": false,
  "httpCheck": true,
  "onlyFindings": false
}

Field	Default	Notes
hostnames	required	Hostnames, URLs or emails. One per line, or comma/space separated; # starts a comment. Duplicates removed; invalid lines listed in SUMMARY. Up to 10,000 per run.
discoverFromCt	false	Pull extra hostnames for each apex from Certificate Transparency (Cert Spotter → crt.sh)
maxSubdomainsPerDomain	200	Cap on CT names added per apex (1–2000)
httpCheck	true	GET http/https and match body/status fingerprints
onlyFindings	false	Dataset only gets VULNERABLE / LIKELY / POSSIBLE / DANGLING rows
concurrency	20	Lookups in flight (max 100)
dnsResolver	cloudflare	cloudflare or google; the other is the fallback
timeoutSecs	5	Per DNS and HTTP request

Output

One dataset row per hostname. Views: Overview and Findings only.

{
  "host": "old.example.com",
  "verdict": "VULNERABLE",
  "service": "Microsoft Azure",
  "serviceStatus": "vulnerable",
  "cnameChain": ["dead.azurewebsites.net"],
  "finalTarget": "dead.azurewebsites.net",
  "dnsStatus": "NXDOMAIN",
  "httpStatus": null,
  "matchedFingerprint": "NXDOMAIN",
  "matchedBy": "cname-nxdomain",
  "evidence": "CNAME target dead.azurewebsites.net is NXDOMAIN (Microsoft Azure)",
  "recommendation": "Confirm the finding, then either remove the dangling DNS record…",
  "disclaimer": "Results need manual confirmation. Only act on domains you own or are authorised to test…"
}

Verdict meanings

Verdict	Meaning
VULNERABLE	Fingerprint matched on a service listed vulnerable (HTTP body/status, or dangling CNAME NXDOMAIN on an nxdomain-signal service such as Azure / Elastic Beanstalk).
LIKELY	Dangling CNAME (target NXDOMAIN) to a takeover-prone service that is vulnerable or edge-case, without a confirming HTTP fingerprint.
POSSIBLE	Edge-case service fingerprint matched (GitHub Pages, Heroku, Netlify, Shopify, Vercel…). Often not trivially claimable.
DANGLING	CNAME target is NXDOMAIN; provider unknown.
OK	Resolves and no takeover fingerprint matched (or a not-vulnerable fingerprint matched).
NO_RECORD	Hostname is NXDOMAIN or has no records.
ERROR	DNS or HTTP lookup failed after retries.

The key-value store record SUMMARY has verdict counts, a findings list, CT discovery notes, invalid inputs and DoH statistics.

Pricing

Pay per event: $2 per 1,000 hostnames (host-checked at $0.002 each). Invalid and duplicate inputs are not charged. CT discovery names that are checked are charged like any other hostname.

Limits

• Fingerprints and statuses can change; always confirm manually before removing DNS or reclaiming a resource.
• HTTP checks use a short timeout and a small body cap; a slow or huge error page may be missed.
• Certificate Transparency is not a complete inventory of every subdomain.
• Apify cloud has no IPv6 egress; hosts that only answer on IPv6 may look like errors.
• A records pointing at known cloud IP ranges (without a CNAME) are out of scope and are not flagged.

FAQ

Is a POSSIBLE finding safe to ignore? No. It means an edge-case provider page matched. Confirm with that provider's docs; many require an extra verification step before a name can be claimed.

Why is GitHub / Heroku / Netlify not VULNERABLE? The fingerprint source lists them as edge cases (extra steps or provider mitigations). This actor follows that classification.

Can I discover subdomains automatically? Yes: set discoverFromCt to true. The actor asks Cert Spotter (and crt.sh if needed) for names under each apex in your list, then checks them.

Does this claim anything? No. DNS lookups and a GET only. Claiming or registering resources is intentionally out of scope.

Related

• Bulk SPF / DMARC / MX Auditor
• Bulk DKIM Selector Finder
• Bulk SSL Certificate Expiry Monitor
• Microsoft 365 Tenant Finder