Subdomain Takeover: Hunting Dangling DNS

Subdomain takeover happens when a DNS record points at a third-party service that no longer hosts anything for you — a "dangling" CNAME to a deleted bucket, app platform, or CDN endpoint that anyone can now claim. Claim it and you serve content from the victim's own domain. This is the recon-to-takeover workflow.

Finding it

The lifecycle is mundane: a team points status.example.com at a SaaS via CNAME, later deletes the SaaS account, and nobody removes the DNS record. The subdomain now resolves to a provider endpoint that is free to claim. The signal you hunt for is a recognizable "no site here" fingerprint from the provider.

The recon pipeline is a volume game across the whole subdomain inventory:

1. Enumerate subdomains from certificate transparency, passive DNS, and brute force.
2. Resolve each and capture the CNAME target.
3. Flag targets that return a known unclaimed-resource fingerprint.
4. Confirm the referenced resource can actually be registered.

# Enumerate, resolve, and check for dangling-target fingerprints
subfinder -d example.com -silent \
  | dnsx -cname -resp -silent \
  | tee resolved.txt
# Then scan the live hosts for known takeover fingerprints
subzy run --targets resolved.txt
nuclei -l resolved.txt -t http/takeovers/

A quick certificate-transparency pull seeds the inventory before you even resolve anything:

# Harvest historical subdomains from CT logs, then feed into the resolver above
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | sed 's/\*\.//' | sort -u

The dig tell on a single host:

$ dig +short status.example.com
example-status.hosted-provider.io.
# Fetching it returns the provider's "there's no site here / repo not found" page

That error page is exactly what subjack, subzy, and the nuclei takeover templates key on.

Proof of concept

Confirming a takeover means claiming the dangling resource and serving your own content. The steps, generically:

1. Identify the provider from the CNAME target (e.g. a static-site host, a pages service, a CDN).
2. Register an account with that provider and create a resource using the exact name the CNAME points to.
3. Publish a unique marker page that proves control.

# After claiming the resource on the provider, verify you now serve the subdomain
curl -s https://status.example.com/ | grep "poc-takeover-$(whoami)"
# Your unique marker returned over the VICTIM's hostname == confirmed takeover

Keep the proof minimal and non-malicious: a single HTML file containing a unique token tied to your researcher handle, served at the victim's subdomain. That is unambiguous evidence without hosting anything harmful.

<!-- Served from status.example.com after claiming the dangling resource -->
<h1>Subdomain takeover PoC — poc-takeover-researcher123</h1>

Going further

A claimed subdomain is the victim's domain to a browser, which is what makes it dangerous. Escalations you can demonstrate (in writing, without actually attacking users):

• Convincing phishing hosted on a trusted hostname.
• Reading or setting cookies scoped to the parent domain (.example.com).
• Subverting same-site assumptions, CORS allow-lists, and CSP *.example.com rules — chain the takeover into another finding for higher impact.

Not every provider is exploitable; some require domain verification before serving content, so part of recon is knowing which services currently permit unverified claims. The sprawl of ephemeral preview deploys, marketing microsites, and decommissioned demos is where dangling records accumulate, so enumerate broadly. Capture the CNAME, the provider fingerprint, and your marker served over the victim hostname. Only claim resources on domains you are authorized to test, and tear down your PoC afterward.