subdomain-takeover

スキル：サブドメインテイクオーバー — 検出と悪用の手引き

AI LOAD INSTRUCTION：CNAME／NS／MX テイクオーバー、プロバイダーごとのフィンガープリント照合、クレーム手順、防御的な監視について説明します。ベースモデルは「CNAME が存在する」ことと「テイクオーバーが可能である」ことを混同しがちです。重要なのは、CNAME の参照先リソースが未クレームで、クレーム可能かどうかです。

0. 関連するルーティング

• SSRF の許可リストが *.target.com を信頼しており、サブドメインテイクオーバーを利用して回避する場合は、ssrf-server-side-request-forgery
• CORS が *.target.com を信頼している場合は、cors-cross-origin-misconfiguration — テイクオーバーにより、クロスオリジンの内容をすべて読み取れます
• xss-cross-site-scripting：テイクオーバーにより、ターゲットのオリジン下でスクリプトを実行できます（Cookie の窃取、OAuth リダイレクトの悪用）
• Host によるルーティングがサブドメインスコープのキャッシュや認証の問題につながる場合は、http-host-header-attacks
• テイクオーバーされたサブドメインがメインドメインとキャッシュを共有している場合は、web-cache-deception

---

1. 基本概念

サブドメインテイクオーバーは、次の条件が満たされたときに発生します。

1. sub.target.com に、外部サービスを指す DNS レコード（CNAME、NS、A）がある
2. 外部リソースがすでにプロビジョニングされていない（削除済みの S3 バケット、削除済みの Heroku アプリなど）
3. 攻撃者がプロバイダー上で、そのリソース名を正確に登録／クレームできる
4. 攻撃者が sub.target.com で配信されるコンテンツを制御できるようになる

影響：Cookie の窃取（親ドメインの Cookie）、OAuth トークンの傍受、信頼されたドメイン下でのフィッシング、CORS の回避、許可リストに登録されたサブドメイン経由での CSP の回避。

---

2. 検出方法

2.1 CNAME の列挙

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 主な兆候

兆候	意味
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 自動化ツール

ツール	用途
subjack	CNAME テイクオーバーの自動チェック
nuclei -t takeovers/	Nuclei のテイクオーバー検出テンプレート
can-i-take-over-xyz (GitHub)	脆弱なサービスの参照情報
dnsreaper	複数プロバイダー対応のテイクオーバースキャナー
subzy	サブドメインテイクオーバーの高速な検証

---

3. サービスプロバイダーのフィンガープリント一覧

プロバイダー	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 への CNAME	Fastly error: unknown domain	はい — Fastly サービスにドメインを追加
Pantheon	*.pantheonsite.io	Pantheon のブランド表示を含む 404 Site Not Found	はい
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 のブランド表示	はい — 一致するサブドメインを作成
Unbounce	*.unbouncepages.com	The requested URL was not found	はい
Ghost	*.ghost.io	Ghost のエラー 404 Not Found	はい
Surge.sh	*.surge.sh	project not found	はい
Fly.io	*.fly.dev への CNAME	Fly.io のデフォルト 404	はい

---

4. テイクオーバーの手順 — 一般的なプロバイダー

4.1 AWS S3

1. Confirm: curl -s http://sub.target.com → "NoSuchBucket"
2. Extract bucket name from CNAME (e.g., sub.target.com.s3.amazonaws.com → bucket = "sub.target.com")
3. aws s3 mb s3://sub.target.com --region <region>
4. Upload index.html proving control
5. Enable static website hosting

4.2 GitHub Pages

1. Confirm: curl -s https://sub.target.com → "There isn't a GitHub Pages site here"
2. Create GitHub repo (any name)
3. Add CNAME file containing "sub.target.com"
4. Enable GitHub Pages in repo settings
5. Wait for DNS propagation (GitHub verifies CNAME match)

4.3 Heroku

1. Confirm: curl -s http://sub.target.com → "No such app"
2. heroku create <app-name-from-cname>
3. heroku domains:add sub.target.com
4. Deploy proof-of-concept page

---

5. NS テイクオーバー — 高い深刻度

NS テイクオーバーは CNAME テイクオーバーよりもはるかに危険です。ゾーンのすべての DNS 解決を制御できるためです。

発生の仕組み

target.com NS → ns1.expireddomain.com
                 ↓
attacker registers expireddomain.com
                 ↓
attacker now controls ALL DNS for target.com
(A records, MX records, TXT records — everything)

検出

1. Enumerate NS records: dig NS target.com +short
2. Check each NS domain: whois ns1.example.com → is the domain expired or available?
3. Also check: dig A ns1.example.com → NXDOMAIN/SERVFAIL?
4. Subdelegated zones: check NS for sub.target.com specifically

影響

• ドメイン全体のテイクオーバー（任意のコンテンツを配信し、メールを傍受し、DNS-01 経由で TLS 証明書を発行）
• DNS チャレンジを使用して、任意の CA から DV 証明書を発行
• SPF/DKIM/DMARC を変更 → 標的になりすまして認証済みメールを送信

---

6. MX テイクオーバー — メールの傍受

MX レコードが廃止されたメールサービスを指している場合：

target.com MX → mail.deadservice.com (service discontinued)

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

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

一般的なシナリオ

期限切れの Google Workspace / Microsoft 365 テナント → MX は引き続き Google/Microsoft を指す → 攻撃者が新しいテナントを作成してドメインを取得する。

---

7. ワイルドカード DNS のリスク

*.target.com に取得可能なサービスへのワイルドカード CNAME が設定されている場合：

• 未定義のすべてのサブドメインが脆弱です
• anything.target.com がテイクオーバーされる可能性があります
• 攻撃対象領域が大幅に拡大します

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

---

8. 検出と悪用の判断ツリー

Subdomain discovered (sub.target.com)?
├── Resolve DNS records
│   ├── Has CNAME → external service?
│   │   ├── HTTP response matches known fingerprint? (Section 3)
│   │   │   ├── YES → Attempt claim on provider (Section 4)
│   │   │   │   ├── Claim successful → TAKEOVER CONFIRMED
│   │   │   │   └── Claim blocked (name reserved, region locked) → document, try variations
│   │   │   └── NO → Service active, no takeover
│   │   └── CNAME target NXDOMAIN?
│   │       ├── Target is a registrable domain? → Register it → full control
│   │       └── Target is a subdomain of active provider → check provider claim process
│   │
│   ├── Has NS records → external nameserver?
│   │   ├── NS domain expired/available? → Register → FULL ZONE TAKEOVER
│   │   └── NS domain active → no takeover
│   │
│   ├── Has MX → external mail service?
│   │   ├── Mail service deprovisioned/claimable? → Claim tenant → EMAIL INTERCEPTION
│   │   └── Active mail service → no takeover
│   │
│   └── Has A record → IP address?
│       ├── IP belongs to elastic cloud (AWS EIP, Azure, GCP)?
│       │   ├── IP unassigned? → Claim IP → serve content
│       │   └── IP assigned to another customer → no takeover
│       └── IP belongs to dedicated server → no takeover
│
└── Post-takeover impact assessment
    ├── Shared cookies with parent domain? → Session hijacking
    ├── CORS trusts *.target.com? → Cross-origin data theft
    ├── CSP whitelists *.target.com? → XSS via taken-over subdomain
    ├── OAuth redirect_uri allows sub.target.com? → Token theft
    └── Can issue TLS cert for sub.target.com? → Full MITM

---

9. 防御と修復

対策	優先度
クラウドリソースの廃止時に DNS レコードを削除する	重大
CNAME の参照先で NXDOMAIN 応答がないか監視する	高
DNS 監視ツール（SecurityTrails、DNSHistory）を使用する	高
DNS レコードを削除する前に、リソース名を取得・予約する	高
NS 委任を監査する — NS ドメインが所有され、更新されていることを確認する	重大
サードパーティサービスへのワイルドカード CNAME を避ける	中
Certificate Transparency の監視を実装する	中

---

10. トリックに関する注意事項 — AI モデルが見落とす点

1. CNAME ≠ テイクオーバー：403 を返す S3 への CNAME（バケットは存在するが、プライベート）があっても、脆弱性はありません。該当するのは NoSuchBucket（404）の場合のみです。
2. S3 ではリージョンが重要です：バケット名はグローバルですが、ウェブサイトのエンドポイントはリージョンごとに異なります。CNAME からリージョンを特定し、一致するものを試してください。
3. GitHub Pages の検証：GitHub はドメイン検証を導入しており、組織が検証済みのドメインは第三者が取得できません。ターゲットがこれを利用しているか確認してください。
4. 例外ケース：Cloudfront など一部のプロバイダーでは、ドメインを取得するだけでなく、特定のディストリビューション設定が必要です。
5. 二段階のテイクオーバー：sub.target.com CNAME → other.target.com CNAME → dead-service.com のように、チェーンを最後までたどる必要があります。
6. SPF サブドメインのテイクオーバー：SPF に include:sub.target.com が含まれており、sub.target.com を取得できた場合、その SPF TXT レコードを変更して自分のメールサーバーを許可し、target.com を装ったメールを送信できます。