Subdomain takeover
When it applies
A subdomain's DNS still points (CNAME/A) to a third-party service that no longer has the resource provisioned, so you can register it and serve content on the victim's subdomain.
Why it works
The org deleted the S3 bucket / GitHub Pages / Heroku app but left the DNS record. The provider now serves that hostname to whoever claims the resource next — you. You control content on a trusted subdomain (phishing, cookie theft on the parent domain, OAuth redirect_uri allowlist).
Method
- Find candidates: from subdomain enum, resolve CNAMEs (
dig CNAME sub.target.com) and look for third-party targets with a "not claimed" fingerprint (nuclei -t takeovers,subjack). - Confirm the fingerprint: the provider's specific unclaimed-resource error (e.g. S3
NoSuchBucket, GitHub Pages 404, Heroku "no such app"). - Claim it: register the exact resource name on that provider (bucket/app/pages repo) and serve a proof file — do NOT phish; a harmless proof page is the report.
- Assess chained impact: cookie scope on parent domain, OAuth
redirect_uriallowlist, CSPscript-srcincluding the subdomain, SPF/email.
Gotchas
- Only some providers are claimable and only with the right fingerprint — a generic 404 isn't takeover.
- Prove with a benign marker page; don't collect data or run phishing.
- Note the chained impact (why it matters) — a bare takeover of an unused subdomain may be low without it.
Verify success
You serve attacker-controlled content at the victim's subdomain (proof file loads at
sub.target.com), captured with the DNS record + your claimed resource.
References
can-i-take-over-xyz; subjack/nuclei takeover templates; HackerOne takeover reports.