subdomain-takeover

A security-testing playbook for detecting and exploiting subdomain takeover, where a victim's DNS record points at a deprovisioned or unclaimed external resource that an attacker can register to serve content under the victim's domain. It emphasizes the distinction base models often miss — a CNAME merely existing does not mean takeover is possible; what matters is whether the resource behind it is unclaimed and claimable.

The core scenario is a dangling record (CNAME, NS, or A) pointing to an external service that is no longer provisioned — a deleted S3 bucket, a removed Heroku app, an unclaimed GitHub Pages site — that the attacker then claims. Documented impact includes cookie theft against parent-domain cookies, OAuth token interception, phishing under a trusted domain, and CORS or CSP bypass via a whitelisted subdomain.

Detection methodology enumerates subdomains (amass, subfinder, assetfinder, crt.sh, SecurityTrails), resolves each record, and matches provider error responses against a fingerprint table covering AWS S3 (NoSuchBucket), GitHub Pages, Heroku, Azure, Shopify, Fastly, Pantheon, Tumblr, WordPress.com, Zendesk, Ghost, Surge.sh, Fly.io, and more, noting which are claimable and how. Automated tools include subjack, nuclei takeover templates, dnsreaper, subzy, and the can-i-take-over-xyz reference, and step-by-step takeover procedures are given for S3, GitHub Pages, and Heroku. Beyond CNAME takeover it covers higher-severity variants: NS takeover, which hands the attacker control of all DNS resolution for the zone (enabling A/MX/TXT changes, DV certificate issuance, and SPF/DKIM/DMARC manipulation), and MX takeover for email interception, including expired Google Workspace or Microsoft 365 tenants. Wildcard DNS risks are flagged because a claimable wildcard exposes every undefined subdomain. A decision tree ties detection to exploitation, and the material is framed for authorized testing and defensive monitoring.