Subdomain Takeover
Run a structured playbook to find dangling DNS records and assess whether a third-party cloud or SaaS endpoint behind a subdomain can be claimed under your target domain.
Overview
Subdomain Takeover is an agent skill for the Ship phase that guides detection and exploitation analysis when DNS points at unclaimed or deprovisioned third-party resources behind a victim subdomain.
Install
npx skills add https://github.com/yaklang/hack-skills --skill subdomain-takeoverWhat is this skill?
- Playbook separates “CNAME exists” from “resource is unclaimed and claimable”
- Covers CNAME, NS, and MX takeover vectors and per-provider fingerprint matching
- Documents claim procedures for deprovisioned cloud and expired SaaS tenants
- Links related routes: SSRF allowlists, CORS on *.domain, XSS under victim origin, Host header, cache deception
- Includes defensive monitoring guidance alongside detection and exploitation steps
Adoption & trust: 1.1k installs on skills.sh; 980 GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You see subdomains and CNAMEs in recon tools but cannot tell which records are actually claimable or how takeover would affect SSRF, CORS, and session security on your domain.
Who is it for?
Indie founders and agents doing structured security review on a custom domain with many subdomains and SaaS integrations.
Skip if: Builders who only need marketing DNS setup without assessing dangling third-party endpoints, or teams prohibited from offensive security testing on targets they do not own.
When should I use this skill?
Targets have dangling CNAME/NS/MX records pointing to deprovisioned cloud resources, expired third-party services, or unclaimed SaaS tenants.
What do I get? / Deliverables
You get a provider-aware takeover assessment, linked follow-on attack paths, and monitoring-oriented fixes so dangling records are reclaimed or removed before launch.
- Takeover feasibility assessment per subdomain and provider
- Cross-linked follow-on test ideas (SSRF, CORS, XSS, cache) where applicable
Recommended Skills
Journey fit
Subdomain takeover sits in the Ship phase because it validates external attack surface and DNS hygiene before or alongside production launch, not during early idea research. Security subphase is the canonical shelf for offensive surface review and hardening checklists tied to domains, cookies, OAuth, and SSRF/CORS trust boundaries.
How it compares
Use instead of treating every discovered CNAME as a critical finding without checking whether the upstream resource is still claimable.
Common Questions / FAQ
Who is subdomain-takeover for?
Solo builders and small teams shipping SaaS or APIs on custom domains who want agent-guided takeover detection aligned with real cloud and SaaS claim behavior.
When should I use subdomain-takeover?
Use it in Ship (security) before go-live, when auditing DNS after migrating off a vendor, or when SSRF/CORS rules trust *.yourdomain and you need to validate subdomain integrity.
Is subdomain-takeover safe to install?
It is documentation-style procedural knowledge; review the Security Audits panel on this page and only run exploitation steps on systems you are authorized to test.
SKILL.md
READMESKILL.md - Subdomain Takeover
# SKILL: Subdomain Takeover — Detection & Exploitation Playbook > **AI LOAD INSTRUCTION**: Covers CNAME/NS/MX takeover, per-provider fingerprint matching, claim procedures, and defensive monitoring. Base models often confuse "CNAME exists" with "takeover possible" — the key is whether the *resource behind the CNAME is unclaimed and claimable*. ## 0. RELATED ROUTING - [ssrf-server-side-request-forgery](../ssrf-server-side-request-forgery/SKILL.md) when a subdomain takeover is used to bypass SSRF allowlists trusting `*.target.com` - [cors-cross-origin-misconfiguration](../cors-cross-origin-misconfiguration/SKILL.md) when CORS trusts `*.target.com` — takeover → full cross-origin read - [xss-cross-site-scripting](../xss-cross-site-scripting/SKILL.md) takeover gives you script execution under target origin (cookie theft, OAuth redirect abuse) - [http-host-header-attacks](../http-host-header-attacks/SKILL.md) when Host routing leads to subdomain-scoped cache or auth issues - [web-cache-deception](../web-cache-deception/SKILL.md) when a taken-over subdomain shares cache with the main domain --- ## 1. CORE CONCEPT Subdomain takeover occurs when: 1. `sub.target.com` has a DNS record (CNAME, NS, A) pointing to an external service 2. The external resource is **no longer provisioned** (deleted S3 bucket, removed Heroku app, etc.) 3. The attacker can **register/claim** that exact resource name on the provider 4. The attacker now controls content served under `sub.target.com` **Impact**: cookie theft (parent domain cookies), OAuth token interception, phishing under trusted domain, CORS bypass, CSP bypass via whitelisted subdomain. --- ## 2. DETECTION METHODOLOGY ### 2.1 CNAME Enumeration ``` 1. Collect subdomains (amass, subfinder, assetfinder, crt.sh, SecurityTrails) 2. Resolve DNS for each: dig CNAME sub.target.com +short 3. For each CNAME → check if the CNAME target returns NXDOMAIN or a provider error 4. Match error response against fingerprint table (Section 3) ``` ### 2.2 Key Signals | Signal | Meaning | |---|---| | CNAME → `xxx.s3.amazonaws.com` + HTTP 404 "NoSuchBucket" | S3 bucket deleted, claimable | | CNAME → `xxx.herokuapp.com` + "No such app" | Heroku app deleted | | CNAME → `xxx.github.io` + 404 "There isn't a GitHub Pages site here" | GitHub Pages unclaimed | | NXDOMAIN on the CNAME target domain itself | Target domain expired or never existed | | CNAME → provider but HTTP 200 with default parking page | May or may not be claimable — verify | ### 2.3 Automated Tools | Tool | Purpose | |---|---| | `subjack` | Automated CNAME takeover checking | | `nuclei -t takeovers/` | Nuclei takeover detection templates | | `can-i-take-over-xyz` (GitHub) | Reference for which services are vulnerable | | `dnsreaper` | Multi-provider takeover scanner | | `subzy` | Fast subdomain takeover verification | --- ## 3. SERVICE PROVIDER FINGERPRINT TABLE | Provider | CNAME Pattern | Fingerprint (HTTP Response) | Claimable? | |---|---|---|---| | **AWS S3** | `*.s3.amazonaws.com` / `*.s3-website-*.amazonaws.com` | `NoSuchBucket` (404) | Yes — create bucket with matching name | | **GitHub Pages** | `*.github.io` | `There isn't a GitHub Pages site here` (404) | Yes — create repo + enable Pages | | **Heroku** | `*.herokuapp.com` / `*.herokudns.com` | `No such app` | Yes — create app with matching name | | **Azure** | `*.azurewebsites.net` / `*.cloudapp.azure.com` / `*.trafficmanager.net` | Various default pages, NXDOMAIN | Yes — register matching resource | | **Shopify** | `*.myshopify.com` | `Sorry, this shop is currently unavailable` | Yes — create shop, add custom domain | | **Fastly** | CNAME to Fa