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 フィルタリストが *.target.com を信頼する場合、subdomain takeover で SSRF フィルタをバイパス可能
• cors-cross-origin-misconfiguration CORS が *.target.com を信頼する場合 — takeover で完全なクロスオリジンリード可能
• xss-cross-site-scripting takeover でターゲットオリジン下でのスクリプト実行を取得（Cookie 盗聴、OAuth リダイレクト悪用）
• http-host-header-attacks Host ルーティングが subdomain スコープのキャッシュ認証問題につながる場合
• web-cache-deception takeover された subdomain がメインドメインとキャッシュを共有する場合

---

1. CORE CONCEPT

Subdomain takeover は以下の場合に発生します：

1. sub.target.com が外部サービスを指す DNS レコード（CNAME、NS、A）を持つ
2. 外部リソースがもはやプロビジョニングされていない（削除された S3 バケット、削除された Heroku アプリなど）
3. 攻撃者がプロバイダーでその正確なリソース名を登録/要求できる
4. 攻撃者が sub.target.com 配下で提供されるコンテンツを制御

影響：Cookie 盗聴（親ドメイン Cookie）、OAuth トークンインターセプト、信頼されたドメイン下でのフィッシング、CORS バイパス、ホワイトリスト登録された subdomain を経由した CSP バイパス。

---

2. DETECTION METHODOLOGY

2.1 CNAME Enumeration

1. subdomain を収集（amass、subfinder、assetfinder、crt.sh、SecurityTrails）
2. 各 subdomain の DNS を解決：
   dig CNAME sub.target.com +short
3. 各 CNAME について → CNAME ターゲットが NXDOMAIN またはプロバイダーエラーを返すかチェック
4. エラーレスポンスをフィンガープリントテーブル（Section 3）と照合

2.2 Key Signals

Signal	意味
CNAME → xxx.s3.amazonaws.com + HTTP 404 "NoSuchBucket"	S3 バケット削除済み、要求可能
CNAME → xxx.herokuapp.com + "No such app"	Heroku アプリ削除済み
CNAME → xxx.github.io + 404 "There isn't a GitHub Pages site here"	GitHub Pages 未要求
CNAME ターゲットドメイン自体が NXDOMAIN	ターゲットドメイン期限切れまたは非存在
CNAME → プロバイダーだが HTTP 200 でデフォルトパーキングページ	要求可能の場合もあれば不可の場合もあります — 確認が必要

2.3 Automated Tools

ツール	目的
subjack	CNAME takeover 自動チェック
nuclei -t takeovers/	Nuclei takeover 検出テンプレート
can-i-take-over-xyz (GitHub)	どのサービスが脆弱かのリファレンス
dnsreaper	マルチプロバイダー takeover スキャナー
subzy	高速 subdomain takeover 検証

---

3. SERVICE PROVIDER FINGERPRINT TABLE

プロバイダー	CNAME パターン	フィンガープリント（HTTP レスポンス）	要求可能？
AWS S3	*.s3.amazonaws.com / *.s3-website-*.amazonaws.com	NoSuchBucket (404)	はい — マッチング名でバケット作成
GitHub Pages	*.github.io	There isn't a GitHub Pages site here (404)	はい — リポジトリ作成 + Pages 有効化
Heroku	*.herokuapp.com / *.herokudns.com	No such app	はい — マッチング名でアプリ作成
Azure	*.azurewebsites.net / *.cloudapp.azure.com / *.trafficmanager.net	各種デフォルトページ、NXDOMAIN	はい — マッチングリソース登録
Shopify	*.myshopify.com	Sorry, this shop is currently unavailable	はい — ストア作成、カスタムドメイン追加
Fastly	Fastly edge への CNAME	Fastly error: unknown domain	はい — Fastly サービスにドメイン追加
Pantheon	*.pantheonsite.io	404 Site Not Found with Pantheon branding	はい
Tumblr	*.tumblr.com（カスタムドメイン CNAME）	There's nothing here / Whatever you were looking for doesn't exist	はい
WordPress.com	*.wordpress.com への CNAME	Do you want to register	はい — WP.com でドメイン要求
Zendesk	*.zendesk.com	Help Center Closed / Zendesk branding on error	はい — マッチング subdomain 作成
Unbounce	*.unbouncepages.com	The requested URL was not found	はい
Ghost	*.ghost.io	404 Not Found Ghost error	はい
Surge.sh	*.surge.sh	project not found	はい
Fly.io	*.fly.dev への CNAME	Fly.io default 404	はい

---

4. TAKEOVER PROCEDURE — COMMON PROVIDERS

4.1 AWS S3

1. 確認: curl -s http://sub.target.com → "NoSuchBucket"
2. CNAME からバケット名を抽出（例：sub.target.com.s3.amazonaws.com → bucket = "sub.target.com"）
3. aws s3 mb s3://sub.target.com --region <region>
4. control を証明する index.html をアップロード
5. 静的ウェブサイトホスティングを有効化

4.2 GitHub Pages

1. 確認: curl -s https://sub.target.com → "There isn't a GitHub Pages site here"
2. GitHub リポジトリを作成（任意の名前）
3. "sub.target.com" を含む CNAME ファイルを追加
4. リポジトリ設定で GitHub Pages を有効化
5. DNS 伝播を待機（GitHub が CNAME マッチを検証）

4.3 Heroku

1. 確認: curl -s http://sub.target.com → "No such app"
2. heroku create <app-name-from-cname>
3. heroku domains:add sub.target.com
4. proof-of-concept ページをデプロイ

---

5. NS TAKEOVER — HIGH SEVERITY

NS takeover は CNAME takeover よりはるかに危険です：ゾーン全体の DNS 解決を制御できます。

How It Happens

target.com NS → ns1.expireddomain.com
                 ↓
攻撃者が expireddomain.com を登録
                 ↓
攻撃者が target.com の**すべての** DNS を制御
(A レコード、MX レコード、TXT レコード — すべて)

Detection

1. NS レコードを列挙: dig NS target.com +short
2. 各 NS ドメインをチェック: whois ns1.example.com → ドメインは期限切れまたは利用可能？
3. また以下もチェック: dig A ns1.example.com → NXDOMAIN/SERVFAIL？
4. サブデリゲートゾーン：sub.target.com の NS を具体的にチェック

Impact

• フルドメイン takeover（任意のコンテンツ提供、メール傍受、DNS-01 経由での TLS 証明書発行）
• DNS チャレンジを使用して任意の CA から DV 証明書を発行
• SPF/DKIM/DMARC を変更 → ターゲットになりすまして認証メール送信

---

6. MX TAKEOVER — EMAIL INTERCEPTION

MX レコードがプロビジョニング解除されたメールサービスを指す場合：

target.com MX → mail.deadservice.com（サービス廃止）

攻撃者が mail.deadservice.com またはメールテナントを要求できる場合：

• パスワードリセットメールを受信
• 機密通信をインターセプト
• メールベースの認証を使用するアカウントをリセットできる可能性

Common Scenario

期限切れ Google Workspace / Microsoft 365 テナント → MX が Google/Microsoft を指している → 攻撃者が新しいテナントを作成してドメインを要求。

---

7. WILDCARD DNS RISKS

*.target.com がクレーム可能なサービスへのワイルドカード CNAME を持つ場合：

• すべての未定義の subdomain が脆弱
• anything.target.com を takeover 可能
• 攻撃サーフェスが大幅に増加

検出：dig A random1234567.target.com — 解決する場合、ワイルドカードが存在します。

---

8. DETECTION & EXPLOITATION DECISION TREE

Subdomain が発見されました（sub.target.com）？
├── DNS レコードを解決
│   ├── 外部サービスを指す CNAME がありますか？
│   │   ├── HTTP レスポンスが既知のフィンガープリントと一致？（Section 3）
│   │   │   ├── はい → プロバイダーで claim を試行（Section 4）
│   │   │   │   ├── Claim 成功 → TAKEOVER CONFIRMED
│   │   │   │   └── Claim がブロック（名前予約、リージョンロック） → ドキュメント、バリエーションを試行
│   │   │   └── いいえ → サービス有効、takeover なし
│   │   └── CNAME ターゲットが NXDOMAIN？
│   │       ├── ターゲットが登録可能なドメイン？ → 登録 → 完全なコントロール
│   │       └── ターゲットがアクティブなプロバイダーの subdomain → プロバイダーの claim プロセスをチェック
│   │
│   ├── 外部ネームサーバーを指す NS レコードがありますか？
│   │   ├── NS ドメイン期限切れ/利用可能？ → 登録 → FULL ZONE TAKEOVER
│   │   └── NS ドメイン有効 → takeover なし
│   │
│   ├── 外部メールサービスを指す MX がありますか？
│   │   ├── メールサービスがプロビジョニング解除/要求可能？ → テナント要求 → EMAIL INTERCEPTION
│   │   └── アクティブなメールサービス → takeover なし
│   │
│   └── IP アドレスを指す A レコードがありますか？
│       ├── IP が elastic cloud に属する（AWS EIP、Azure、GCP）？
│       │   ├── IP が未割り当て？ → IP 要求 → コンテンツ提供
│       │   └── IP が別の顧客に割り当て → takeover なし
│       └── IP が専用サーバーに属する → takeover なし
│
└── Takeover 後の影響評価
    ├── 親ドメインと共有 Cookie？ → セッションハイジャック
    ├── CORS が *.target.com を信頼？ → クロスオリジンデータ盗聴
    ├── CSP が *.target.com をホワイトリスト？ → takeover された subdomain 経由での XSS
    ├── OAuth redirect_uri が sub.target.com を許可？ → トークン盗聴
    └── sub.target.com の TLS 証明書を発行可能？ → 完全な MITM

---

9. DEFENSE & REMEDIATION

アクション	優先度
クラウドリソースのプロビジョニング解除時に DNS レコードを削除	Critical
CNAME ターゲットの NXDOMAIN レスポンスを監視	High
DNS 監視ツールを使用（SecurityTrails、DNSHistory）	High
DNS レコードを削除する前にリソース名を要求/予約	High
NS デリゲーションを監査 — NS ドメインが所有・更新されていることを確認	Critical
第三者サービスへのワイルドカード CNAME を避ける	Medium
Certificate Transparency 監視を実装	Medium

---

10. TRICK NOTES — WHAT AI MODELS MISS

1. CNAME ≠ takeover：S3 に対する CNAME が 403 を返す（バケット存在、プライベート）場合は脆弱ではありません。NoSuchBucket（404）のみが対象です。
2. S3 ではリージョンが重要：バケット名はグローバルですが、ウェブサイトエンドポイントはリージョンが指定されます。CNAME からのリージョンマッチを試みてください。
3. GitHub Pages 検証：GitHub がドメイン検証を追加しました — 組織検証済みドメインは他者が要求することはできません。ターゲットがこれを使用しているかチェックしてください。
4. エッジケース：いくつかのプロバイダー（Cloudfront など）ではドメイン要求だけでなく特定のディストリビューション設定が必要です。
5. Second-order takeover：sub.target.com CNAME → other.target.com CNAME → dead-service.com — チェーン全体をたどる必要があります。
6. SPF subdomain takeover：SPF が include:sub.target.com を含み、sub.target.com を takeover した場合、その SPF TXT レコードを変更してメールサーバーを認可 → target.com になりすまして メールを送信できます。