📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
Have you looked for subdomain takeovers in bug bounty?
No — never heard of this before Heard of it, never actively looked Tried, never found one Yes — found and reported one
How Hackers Find Subdomain Takeovers in 2026 :— A researcher runs three terminal commands on a Sunday afternoon. She finds that staging.company.com points to a GitHub Pages repository that no longer exists. She registers that repository, places a placeholder page on it, and submits a report. The bounty: $1,200. Total time: ten minutes. Subdomain takeover is one of the highest-effort-to-payout vulnerability classes in bug bounty because the check is fast, the vulnerability is widespread, and large companies routinely leave forgotten DNS records pointing to decommissioned cloud services. This article teaches the exact 15-second DNS check, which services to look for, how to automate across hundreds of subdomains, and how to write the report.
🎯 What You’ll Learn
Why subdomain takeovers happen — the dangling CNAME lifecycle
The 3-command, 15-second manual check that confirms any takeover
Which cloud services are vulnerable and how to verify with can-i-take-over-xyz
Automation with subfinder and subjack for large-scope programmes
Severity assessment and bug bounty reporting
⏱️ 30 min read · 3 exercises ### 📋 Subdomain Takeover 2026 1. How Subdomain Takeovers Happen — The Dangling CNAME 2. The 15-Second Check — 3 Commands 3. Vulnerable Cloud Services in 2026 4. Automation with subfinder and subjack 5. Impact, Severity and Bug Bounty Payouts 6. Reporting to Bug Bounty Programmes ## How Subdomain Takeovers Happen — The Dangling CNAME Every subdomain takeover follows the same lifecycle. A company creates a staging environment on Heroku, a documentation site on GitHub Pages, or a landing page on an AWS S3 static website. Their DNS admin creates a CNAME: staging.company.com CNAME acme-staging.herokuapp.com. Six months later, the project ends. A developer deletes the Heroku app. The DNS record is never removed — because removing a DNS record requires a separate ops ticket that nobody creates, and DNS record cleanup is nobody’s specific job.
The vulnerability persists silently. Visitors to staging.company.com follow the CNAME to acme-staging.herokuapp.com and receive Heroku’s “No such app” page. Anyone can create a new Heroku app named acme-staging and claim that subdomain name. Once they do, every visitor to staging.company.com receives whatever content they put there — served under the company’s legitimate domain, trusted by browsers, included in the company’s TLS certificate scope.
securityelites.com
Subdomain Takeover — Lifecycle from Deployment to Vulnerability
① DEPLOY:
staging.company.com CNAME acme.herokuapp.com → running app ✓
② DECOMMISSION:
Developer deletes app → DNS record forgotten (nobody’s job to remove)
③ DANGLING:
staging.company.com CNAME acme.herokuapp.com → NXDOMAIN
④ TAKEOVER:
Attacker registers “acme” on Heroku → staging.company.com now serves attacker content
⑤ IMPACT:
Phishing from trusted domain · cookie theft · OAuth abuse · all via company’s own subdomain
📸 The subdomain takeover lifecycle. The critical gap is between ② and ③ — the resource is gone but the DNS record persists, sometimes for years. The attacker’s action at ④ requires no exploitation of any code vulnerability: just registering a cloud resource whose name matches the orphaned CNAME target.
The 15-Second Check — 3 Commands
The manual subdomain takeover check is three commands run in sequence. Each gives definitive information. Together they take 15 seconds and produce the exact evidence needed for a bug bounty report.
THE 15-SECOND SUBDOMAIN TAKEOVER CHECKCopy
COMMAND 1: Find the CNAME record
dig staging.target.com CNAME
;; ANSWER SECTION:
staging.target.com. 300 IN CNAME acme-staging.herokuapp.com.
Found a CNAME pointing to Heroku → check if that app exists
COMMAND 2: Check if the CNAME target exists
dig acme-staging.herokuapp.com
;; status: NXDOMAIN
← NXDOMAIN = Heroku app does not exist = potentially vulnerable
COMMAND 3: Confirm with HTTP fingerprint
curl -s https://staging.target.com | head -3
No such app
“No such app” = Heroku confirmed the resource doesn’t exist
VERIFY: cross-reference with can-i-take-over-xyz
github.com/EdOverflow/can-i-take-over-xyz → search “heroku”
Result: VULNERABLE — fingerprint “No such app” confirmed
CONCLUSION: confirmed subdomain takeover opportunity — document and report
🛠️ EXERCISE 1 — BROWSER (15 MIN · NO INSTALL)
Run the 15-Second Check Against a Real Bug Bounty Target
⏱️ 15 minutes · Browser + terminal
Step 1: Find a programme with wildcard subdomain scope
Go to hackerone.com/programs or bugcrowd.com
Find any programme with “*.company.com” in scope.
Step 2: Enumerate subdomains passively via crt.sh Go to: crt.sh Search: %.company.com This shows all SSL certificates issued for the domain. List 5-10 interesting subdomains (staging, dev, docs, beta, test).
Step 3: Run the 3-command check on each dig [subdomain].company.com CNAME If a CNAME is found → dig [cname_target] If NXDOMAIN → check HTTP fingerprint with curl
Step 4: Cross-reference with can-i-take-over-xyz github.com/EdOverflow/can-i-take-over-xyz Is the service listed as VULNERABLE? What is the exact fingerprint string?
Step 5: Document any NXDOMAIN findings Even if not on a live programme — record the subdomain, CNAME target, NXDOMAIN confirmation, and HTTP response. This is exactly the evidence a bug bounty report requires.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)