Post cover image

August 23, 2026

The Bug You Exploit by Clicking “Create”

What’s up everyone! Nitin here 👋

By Nitin yadav

2 min read

Subdomain takeover is one of the most satisfying bugs to find because the exploit is basically "click a button and claim it." It happens when a company points a subdomain (via DNS CNAME) at a third-party service — an S3 bucket, a GitHub Pages site, a Heroku app — then later deletes that service but forgets to remove the DNS record. The pointer now dangles at nothing. And if you can register that nothing, you control something.target.com. Let's automate the hunt.

Why it happens

Companies spin up cloud resources and wire subdomains to them: shop.target.com → CNAME → target-shop.s3.amazonaws.com. Later they decommission the shop and delete the bucket — but the DNS CNAME stays. Now shop.target.com still resolves toward S3, S3 says "that bucket doesn't exist," and anyone can create a bucket with that exact name and start serving content on the company's trusted subdomain. Same story for dozens of services.

Step 1: Enumerate every subdomain

You can't find a dangling CNAME on a subdomain you don't know about. Go wide:

subfinder -d target.com -all | anew subs.txt
amass enum -passive -d target.com | anew subs.txt
curl -s "<https://crt.sh/?q=%25.target.com&output=json>" | jq -r '.[].name_value' | anew subs.txt
dnsx -l subs.txt -cname -resp -o resolved.txt

dnsx -cname is the key — it shows you the CNAME each subdomain points to, which is exactly what you're auditing.

Step 2: Find the dangling CNAMEs

Scan the CNAME targets for ones pointing at third-party services that return an "unclaimed" state. Look for CNAMEs pointing to:

*.s3.amazonaws.com        GitHub Pages (*.github.io)
*.herokuapp.com           Azure (*.azurewebsites.net, *.cloudapp.net)
*.fastly.net              Shopify, Netlify, Surge, Unbounce
*.zendesk.com             Fastly, Pantheon, Tumblr, Bitbucket

The reference list at can-i-take-over-xyz tells you which services are takeoverable and how.

Step 3: Fingerprint the claimable error

Visit the subdomain and look for the tell-tale "nothing here" response:

"NoSuchBucket"                              → S3, claimable
"There isn't a GitHub Pages site here."     → GitHub Pages, claimable
"No such app"                               → Heroku, claimable
"Domain not found" / "Do you want to register" → various

Automate the whole scan:

nuclei -l resolved.txt -t http/takeovers/
subzy run --targets subs.txt

nuclei's takeover templates and subzy match the fingerprints for you — point them at your resolved list and let them flag candidates.

Step 4: Claim it (as proof)

When you find a claimable one, register the exact resource the CNAME points to — create the S3 bucket with that name, the GitHub Pages repo with that domain, the Heroku app. Once claimed, the subdomain serves your content. For the PoC, host a harmless proof file:

<https://shop.target.com/nitin-poc.txt>  →  "subdomain takeover PoC by <handle>, date"

That single file proves control without doing anything malicious. Then report immediately.

Why it matters (impact)

Controlling a trusted subdomain is dangerous:

  • Phishing on the real brand's domain (users trust *.target.com)
  • Cookie theft — cookies scoped to .target.com may be sent to your subdomain
  • OAuth / CSP / redirect bypasses that allow-list *.target.com
  • Bypassing SSO or CORS trust of the parent domain

Takeover of an unused marketing subdomain → medium.

Takeover where the parent sets domain-wide cookies or trusts the subdomain for auth/OAuth → high.

Conclusion — the takeover playbook

  • Enumerate all subdomains (subfinder/amass/crt.sh), resolve CNAMEs with dnsx.
  • Find CNAMEs pointing to deprovisioned third-party services.
  • Fingerprint the claimable error; automate with nuclei -t takeovers/ / subzy.
  • Claim the resource, host a harmless proof file, report fast.
  • Impact scales with how much the parent domain trusts the subdomain.

If you Love reading my blogs. Check my Youtube Channel too.