bb-methodology

バグバウンティの方法論：ワークフローとマインドセット

ハンティングセッションのマスターオーケストレーターです。5つのフェーズからなる非線形ワークフローと、上位1％のハンターをその他のハンターと分ける批判的思考フレームワークを組み合わせています。

---

パート 0：モードの確認（最初に行うこと）

何を発見と見なすかを決める前に、エンゲージメントの種類を確認してください。 同じターゲットでも、どのモードが適用されるかによってレポートの形式は異なります。これを間違えることは、このワークフローで最も時間を無駄にする要因です。フェーズ 0 の前に、必ず明確に回答してください。

エンゲージメントの種類	発見と見なされるもの	却下されるもの
バグバウンティ（H1 / Bugcrowd / Intigriti / 非公開 VDP）	影響が実証されたバグのみ。攻撃者が実現可能な被害に至る完全な攻撃チェーン。	セキュリティ衛生（EoL ソフトウェアのみ、制限の緩い CSP のみ、スタックトレース、具体的な影響を伴わない情報開示、「ベストプラクティス」違反）
レッドチーム（外部クライアントとのエンゲージメント）	セキュリティ衛生に関する発見 + 偵察 + IoC + 防御状態の観察結果は、すべて成果物です	何もありません。「ここに発見はない」という内容でさえ、肯定的な防御観察として報告できます
ペンテスト（署名済み SoW / WAPT）	SoW によります。スコープを明確に確認してください。通常はセキュリティ衛生 + 影響 + 偵察を受け入れます	スコープ外の資産、署名のないテスト
内部監査	コンプライアンスに対応付けた発見（PCI / ISO / NIST / DPDPA / GDPR）	管理策との対応付けがない発見

厳守事項： フェーズ 0 を実行する前に、ハントノートの1行目にエンゲージメントの種類を記入してください。ユーザーの指示から判断できない場合は、一度だけ質問してください。推測してはいけません。この間違いは、あなたとトリアージ担当者の両方に損失をもたらします。

承認済みエンゲージメントからの教訓： このターゲットでの初回調査では、セキュリティ衛生に関する発見（SP2013 の EoL、制限の緩い CSP、スタックトレース）を5件、レッドチーム形式で提出しました。しかし、エンゲージメントはバグバウンティでした。これらの発見は「情報提供のみ、影響は未実証」として N/A にされていたでしょう。セキュリティ衛生を発見ではなく文脈として扱い、修正した調査を行った結果、同じターゲットから影響が実証されたバグが11件見つかり、そのうち3件はクリティカルでした。

---

パート 1：マインドセット（考え方）

基本原則

ハンティングとは「バグを見つける」ことではなく、「攻撃シナリオを証明する」ことです。パターンを探すスキャナーではなく、具体的な目標を持つ攻撃者のように考えてください。

日々の規律：定義、選択、実行

コマンドを実行する前に、次のことを行ってください。

1. 定義：「今日は [機能／ドメイン] を対象に、[CIA への影響] を実現する」
2. 選択：脆弱性クラスを1～2個選びます（IDOR、競合状態など）
3. 実行：選択した手法だけに集中します。脇道にそれないでください。

5つの最終目標（セッションごとに1つ選択）

1. 機密性 -- 攻撃者が見るべきではないデータを盗む
2. 完全性 -- 攻撃者が変更すべきではないデータを改ざんする
3. 可用性 -- サービスを妨害する（アプリケーションレベルの DoS のみ）
4. アカウント乗っ取り -- 別のユーザーのアカウントを掌握する
5. RCE -- サーバー上でコマンドを実行する

4つの思考領域

1. 批判的思考（深い分析）

信頼境界を疑う：

• フロントエンドの制御が無効化されている？ プロキシ経由でリクエストを直接送信する
• user_role=user の Cookie がある？ admin に変更する
• POST に price=1000 がある？ 1 に変更する
• <script> がブロックされる？ <img onerror=...> を試す

開発者の心理をリバースエンジニアリングする：

• 機能 A には認証チェックがある -> 類似の機能 B（新しく追加された機能）にはおそらくない
• 複雑なフロー（クーポン + ポイント + 返金） -> エッジケースにバグがある
• /api/v2/user が存在する -> /api/v1/user は、より弱い認証のまま動作していないか？

もしも実験：

• チェックアウトをスキップする -> /checkout/success に直接アクセスする
• 2FA をスキップする -> /dashboard に移動する
• クーポンリクエストを10回同時に送信する -> 競合状態が起きるか？
• 関連するエンドポイントで guid=f8a2... を id=100 に置き換える -> IDOR が起きるか？

2. 複数の視点（複数の角度）

視点	確認する内容
水平（同じロール）	ユーザー A のトークン＋ユーザー B の ID -> IDOR
垂直（異なるロール）	一般ユーザー -> /admin/deleteUser
データフロー（プロキシの視点）	JSON 内の非表示パラメーター：debug=false、discount_rate
時間／状態	競合状態、削除後のセッション再利用
クライアント環境	モバイル UA -> 認証が弱いレガシー API
ビジネスへの影響	「これが破られた場合、損害額はいくらか？」

3. 戦術的思考（パターン検出）

• 命名の異常：どこでも userId が使われているのに、突然 user_id が登場 -> 別の開発者が担当しており、セキュリティが弱い可能性
• エラーの差分：同じ 403 でも JSON の構造が異なる -> 異なるバックエンドシステム
• 環境の差分：本番環境と開発／ステージング環境の違い -> デバッグヘッダー、CSP が無効
• バージョンの差分：更新前後の JS ファイル -> 新しいエンドポイント、削除されたパラメーター
• サプライチェーン：フレームワーク／ライブラリのバージョンに既知の CVE がないか確認
• サードパーティ統合：Stripe／Auth0／Intercom -> Webhook の署名が欠けていないか？

4. 戦略的思考（全体像）

• 非対称性：防御側はすべての穴を塞ぐ必要があります。攻撃側は 1 つ見つければ十分です。
• 直感の活用：「何かおかしい」と感じた理由を記録します。後で検証し、メンタルデータベースを更新します。
• 未知の事柄の管理：理解できないことがあれば、「後で調査する」リストに追加します。ジャストインタイム学習です。

初心者とプロの比較：7 フェーズ

フェーズ	初心者	プロ
偵察	メインドメインのみ	シャドー IT、開発環境、すべてのアセット
発見	エラーを探す	設計上の矛盾やビジネスロジックの欠陥を探す
攻撃	ブロックされると諦める	フィルター回避ペイロードを作成する
エスカレーション	現象だけを報告する	実害（セッション窃取、ATO）につなげる
実現可能性	非現実的な条件を含める	攻撃に必要な前提条件を最小限にする
報告	事実だけを述べる	ビジネスリスクを定量化する
再テスト	古い PoC が失敗するか確認する	修正方法を分析し、不完全なパッチを見つける

2 つのアプローチ経路

• 経路 A（機能ベース）：「この機能は複雑だ」 -> 入力処理を深く調査する -> 脆弱性を見つける
• 経路 B（脆弱性ベース）：「IDOR を見つけたい」 -> 連番 ID を持つエンドポイントを見つける -> アクセス制御をテストする

アンチパターン（やめるべきこと）

• プログラムを渡り歩く：1 つのターゲットに最低 2 週間／30 時間取り組みます
• ツールだけに頼った探索：自動化で見つかるのは重複する脆弱性です。手動テストで独自のバグが見つかります。
• 深追い：パラメーターごとに最大 45 分にします。タイマーを設定しましょう。行き詰まったら、一晩寝かせましょう。
• 目標がない：「ただ見て回る」だけでは時間の無駄です。必ず最初に目標を定めましょう。

---

落とし穴

• モードの混同 — バグバウンティの取り組みをレッドチーム演習として扱うと、N/A と判定される衛生面の指摘に時間を浪費します。偵察を始める前に、取り組みの種類を確認してください（PART 0）。
• 一意でないマーカー — test、marker、javascript をテスト文字列に使うと、誤検知が発生します。必ず8文字以上のランダムな英数字マーカーを使い、ベースラインと照合してください。
• ステータスコードだけに基づくバイパスの主張 — 本文のバイト列が完全に同一の200 OKは、バイパスではありません。成功を主張する前に、必ずレスポンス本文を差分比較してください。
• 単一サンプルに基づくタイミングの結論 — 2倍の外れ値が1回あっても、ネットワークの揺らぎであり、シグナルではありません。タイミングに基づく主張には、最低10回の交互試行と2σのしきい値を適用してください。
• 5回を超える反復にシェルループを使う — zshの配列展開によって、反復が黙ってゼロ回になることがあります。リスト、ファイル、計算した範囲を反復するループには、Pythonとtry/exceptを使ってください。
• フェーズが直線的に進むという思い込み — 5フェーズの流れは非線形です。フェーズ3で新しいAPIが見つかった場合は、フェーズ2のマッピングに戻る必要があります。フェーズ4でWAFにブロックされた場合は、フェーズ1のオリジンIPの偵察が必要です。
• 20分ルールへの違反 — 単一のエンドポイントで進展がないまま20分を超えて続けると、セッションの時間を浪費します。エンドポイント → サブドメイン → 脆弱性クラス → ターゲットの順に切り替えてください。
• A→Bシグナルの無視 — バグを1つ見つけたなら、同じ開発者が近くで別のミスをしている可能性があります。発見を確認したら、関連する脆弱性を探すために必ず20分を費やしてください。
• 検証より先にレポートを作成する — バグがまだ再現することを確認する前にレポートを書くと、後で撤回することになった発見に何時間も浪費します。提出の数分前に必ず再テストしてください。
• 早まった異議申し立て — ユーザーが「もっと見つけて」と言う場合、たいていその指摘は正しいです。網羅できたと主張する前に、追加で3つのhunt-*スキルのチェックリストを最後まで確認してください。
• 見込みのない候補への45分のサンクコスト — 4時間以上経っても、2つ目のアカウントで発見内容を再現できない場合は、撤回を記録して次に進んでください。再現させるために、これ以上時間を費やしてはいけません。

---

PART 2：ワークフロー（何をするか）

5フェーズの非線形フロー

+-------------------------------------------------+
|                                                 |
|  +----------+    +----------+    +----------+   |
|  | 1. RECON |---+| 2. MAP   |---+| 3. FIND  |  |
|  +----------+    +-----+----+    +-----+-----+  |
|       ^                |               |         |
|       |                v               v         |
|       |          +----------+    +----------+    |
|       +----------| 4. PROVE |---+| 5. REPORT|   |
|                  +----------+    +----------+    |
|                                                  |
|  Non-linear: stuck at any phase -> go back       |
|  New API found at phase 3 -> return to phase 2   |
|  WAF blocks at phase 4 -> origin IP from phase 1 |
+-------------------------------------------------+

これは直線的な流れではありません。 フェーズ間を自由に行き来してください。行き詰まったら、前のフェーズに戻ってください。

フェーズ0：セッション開始（毎回）

コマンドを実行する前に、次の問いに答えてください。

1. 定義：「今日は[機能／ドメイン]を対象に、[C/I/A/ATO/RCE]を達成します」
2. 選択：脆弱性クラスを1～2個選びます（IDOR、XSS、SSRFなど）。
3. 実行：選択した手法だけに集中します。

ルートの選択――広く調べるか、深く調べるか？

シグナル	広く調べる（偵察スイープ）	深く調べる（重点的なテスト）
新しいプログラムで、初日	X
スコープがワイルドカード *.target.com	X
メインのウェブアプリで、すでに3日を超えている		X
スコープの更新（新しいドメインが追加された）	X
興味深いサブドメインを発見した		X

フェーズ1：偵察

目標：攻撃対象領域を最大化します。他の人が見逃したものを見つけます。

広く調べる方法（初回スイープ）：

Subdomain enum -> DNS resolution -> HTTP probing -> Port scan -> Tech detect

深く調べる方法（対象を絞る）：

Google Dorks -> JS file download -> Hidden param discovery -> API mapping

見つかったもの	次のアクション
技術スタックが判明している稼働中のサブドメイン	フェーズ2（マッピング）
既知のソフトウェア（WordPress、Jira）	CVEとデフォルト設定をすぐに確認
クラウドリソース（S3、Firebase）	権限をテスト（読み取り／書き込み／一覧表示）
1つのホストで5分間何も見つからない	スキップして次のホストを試す（5分ルール）

コマンド：/recon target.com

フェーズ 2：マッピングと分析

目標：開発者と同じようにアプリを理解します。

チェックリスト：

• すべてのエンドポイントをマッピングします（Burp/Caido のサイトマップと JS の分析）
• 認証モデルを特定します（Cookie、JWT、OAuth、SAML など）
• ビジネス上重要なフローを見つけます（支払い、登録、パスワードリセット、データエクスポート）
• JS ファイルをダウンロードして分析し、隠れたルート、シークレット、ロジックを探します
• ロールと権限を特定します（ユーザー、管理者、API キー）
• 「奇妙な」挙動を記録します（命名、エラー、タイミングの異常など）

見つかったもの	次のアクション
興味深いコードを含む JS ファイル	汚染解析（Sink -> Source）
OAuth/SAML 認証	OAuth/SAML チェックリスト
ID パラメーターを含む API	フェーズ 3 で IDOR を狙います
複雑なビジネスロジック（支払い、クーポン）	フェーズ 3 でビジネスロジックを狙います
postMessage リスナー	DOM 分析、postMessage-tracker

フェーズ 3：脆弱性の発見

目標：バグを見つけます。まずエラーベースを試し、次にブラインドベースを試します。

テスト対象に基づく判断フロー：

What input are you testing?
+-- ID parameter (user_id, order_id)
|   -> IDOR checklist
+-- Search/filter/sort field
|   -> SQLi, NoSQLi probing
+-- URL input / webhook / PDF gen
|   -> SSRF checklist
+-- Text field reflected in page
|   -> XSS (DOM or reflected)
+-- File upload
|   -> SVG XSS, web shell, path traversal
+-- Price/quantity/coupon
|   -> Business logic, race conditions
+-- Login / 2FA / password reset
|   -> Auth bypass
+-- Profile update API
|   -> Mass Assignment
+-- Template / wiki editor
|   -> SSTI
+-- Nothing obvious
    -> Fuzz with ffuf, try Error-based probing

エラーベースとブラインドベースの判断：

1. まずエラーベースを試します（'、"、{{7*7}}、${7*7} を送信）。500 エラーやスタックトレースを確認します。
2. エラーがありませんか？時間ベース（SLEEP(10)、; sleep 10;）を試し、応答時間を確認します。
3. 時間差がありませんか？OOB（curl attacker.com、interactsh）を試し、DNS コールバックを確認します。
4. それでも何もありませんか？ブール値（AND 1=1 と AND 1=0）を試し、コンテンツ長の差を確認します。

見つかったもの	次のアクション
影響の小さい挙動（リダイレクト、セルフ XSS、Cookie インジェクション）	チェーン化し、つなぎ役となるガジェットを探します
脆弱性を確認（XSS、IDOR、SQLi）	フェーズ 4（実証とエスカレーション）
WAF/CSP/403 によるブロック	バイパス手法を試してから再試行します
既知のソフトウェア脆弱性（CVE）	1-day スピードワークフロー
このエンドポイントで 20 分試しても何も見つからない	対象を変更します（20 分ルール）

フェーズ 4：実証とエスカレーション

目標：ビジネスへの最大の影響を実証します。低リスクを重大に引き上げます。

エスカレーションの判断：

What did you find?
+-- XSS
|   +-- Can steal cookie/token? -> Session hijack -> ATO
|   +-- Cookie is HttpOnly? -> Force email change via XHR -> ATO
|   +-- Self-XSS only? -> Find CSRF to trigger it
+-- IDOR
|   +-- Can read PII? -> Automate scraping, show scale
|   +-- Can change password/email? -> Direct ATO
|   +-- UUID only? -> Find UUID leak source, then retry
+-- SSRF
|   +-- DNS only? -> DON'T REPORT. Try cloud metadata
|   +-- Can reach [REDACTED_IP]? -> Extract keys -> RCE
|   +-- Internal port scan? -> Find Redis/K8s -> RCE
+-- SQLi
|   +-- Error-based? -> Extract data (passwords, tokens)
|   +-- Can INTO OUTFILE? -> Web shell -> RCE
|   +-- Blind? -> Boolean/Time extraction
+-- Open Redirect
|   +-- OAuth flow? -> Token theft -> ATO
|   +-- javascript: scheme? -> XSS
+-- Blocked by defense
|   -> Bypass (WAF/CSP/proxy/sanitizer/2FA)
+-- Low-impact, can't escalate alone
    -> Find connector gadget for chain

影響を実証した後に確認すること：

• 攻撃はクリック 0～1 回で成功しますか？（前提条件を最小限にします）
• すべてのユーザーに影響しますか、それとも特定のロールだけですか？
• ビジネスへの金銭的影響はいくらですか？

フェーズ 5：検証と報告

目標：報奨金を獲得します。トリアージ担当者の作業を簡単にします。

報告前の確認ゲート：

Run /validate (7-Question Gate)
+-- All 7 pass? -> Write report
+-- Any fail? -> KILL the finding. Don't waste time.
+-- Borderline? -> Run /triage for quick go/no-go

複数ツールによる再現基準（重大／高のみ）：

検出結果を重大または高と判定する前に、少なくとも2 つの独立したツール（異なるスタック、異なる HTTP ライブラリ）で再現してください。ツール間の一貫性を確認することで、コマンドライン固有のアーティファクトによる検出結果を除外できます（例：Python の requests では再現しない curl のみのタイミング差は、バグではなくアーティファクトでした）。

独立した再現の例：

• curl + Burp send_http1_request（TLS スタックが異なり、ヘッダーの正規化も異なります）
• Python requests + ssl.wrap_socket を使った raw socket（一方はライブラリが正規化し、もう一方は正規化しません）
• Burp Repeater + Python urllib（両方で同じワイヤー結果が得られるはずです）

再現コマンドは、レポート内でシェルに貼り付けてすぐ実行できる形式で必ず記載してください。トリアージ担当者がそのままコピーして実行できるようにします。curl のバージョンで特別なフラグが必要な場合や、特定のシステムで動作しない場合は、Python による代替手段を記載してください。

認可されたエンゲージメントからの教訓： 3 件すべての重大な検出結果（Authentication.asmx のブルートフォース、TE.CL スマグリング、NTLM Type-2 ディスクロージャー）は、それぞれ curl、Python raw socket、Burp のコマンドライン機能を使って独立して再現されました。ツール間の一貫性があったことで、トリアージのレポートでは検出結果がアーティファクトではないと納得してもらえました。

レポート：

Run /report
+-- Platform-specific format (H1/Bugcrowd/Intigriti/Immunefi)
+-- Title: [Bug Class] in [Endpoint] allows [role] to [impact]
+-- Impact-first summary (sentence 1 = what attacker CAN do)
+-- Exact HTTP requests in Steps to Reproduce
+-- Under 600 words
+-- CVSS 3.1 score that MATCHES actual impact

提出後：

• トリアージ待ちの間に、さらなるエスカレーションを試みます（A->B シグナル手法）
• 修正がデプロイされた場合は、バイパスを再テストします（不完全なパッチは新たなバグになります）
• /remember を使って検出結果をハントメモリーに記録します

---

パート 3：ナビゲーションとタイミング

非線形ナビゲーションのクイックリファレンス

行き詰まっている理由	参照先
サブドメインがまったく見つからない	フェーズ 1：異なる偵察情報源や Google Dorks を試す
サブドメインは見つかったが、何をテストすればよいかわからない	フェーズ 2：アプリをマッピングし、JS をダウンロードして、認証を理解する
テストしているが、何もうまくいかない	フェーズ 3：脆弱性の種類を切り替える（20 分のローテーションルール）
バグを見つけたが、影響度が低い	フェーズ 4：影響を拡大する方法、またはガジェットの連鎖
WAF/CSP/403 にペイロードをブロックされる	回避テクニックを試してから、現在のフェーズに戻る
1 つのパラメーターで 45 分間行き詰まっている	中止してください。深追いしすぎています。次のエンドポイントに移りましょう。
テスト中に新しい API エンドポイントを発見した	フェーズ 2 に戻る：攻撃する前にマッピングする
バグを 1 つ見つけた	A->B の兆候：同じ開発者がほかにもミスをしている可能性があります。同種の問題を 20 分間探しましょう。

20 分のローテーションタイマー

20 分ごとに自問してください：「進展していますか？」

• はい → 続行
• いいえ → 次に切り替える：エンドポイント → サブドメイン → 脆弱性の種類 → ターゲット
• 2 週間以上、同じターゲットで何も見つかっていませんか？ → プログラムの切り替えを検討しましょう

押し返しプロトコル（ユーザーに「もっと見つけて」と言われた場合）

ユーザーがあなたの切り上げ時点に異議を唱えた場合（例：「私は 10 件以上見つけたのだから、あなたも見つけるべきだ」「もっと詳しく調べて」「見落としている」など）：

まず、ユーザーが正しいと考えてください。あなたは早く切り上げすぎています。

「X の理由でこれで終わりだと思います」と押し返す前に、次の手順を実行してください：

1. 読み込み済みのものに加えて、hunt-* スキルをさらに 3 つ読み直します。 観測された対象に合うものを選びます（例：カスタムログイン → hunt-auth-bypass、SOAP エンドポイント → プロトコル固有のスキルを探す、URL パラメーター → hunt-ssrf）。
2. 新しいスキルのチェックリストを使って、同じ対象を再攻撃します。 重複しているように感じても、新しいスキルのすべての手順を確認します。
3. 進めながら、見つからなかったものも記録します。 「ここにはバグがない」と確認できたことも、ユーザーに示せる調査結果です（調査範囲を網羅した証拠になります）。
4. 新たに選んだ 3 つのスキルのチェックリストをすべて確認してから、具体的に何をテストしたのかを列挙したうえでのみ、押し返します。

認可されたエンゲージメントから得た教訓： 最初の調査で重要度の低い結果が 5 件見つかったあと、ユーザーが「10 件以上ある。見つけて」と言いました。読み込み済みだったものの最初から最後まで確認していなかった hunt-auth-bypass を読み込むと、すぐに /_vti_bin/Authentication.asmx というレガシー SOAP ログインが見つかり、エンゲージメントで最も影響度の高いバグとなりました。ユーザーが正しく、押し返していたら誤りでした。

フェーズ別のツールの使い分け

フェーズ	ツール	この順序にする理由
偵察：サブドメイン	subfinder -> amass -> puredns -> httpx	まずパッシブに調査（検知されない）-> DNS を解決 -> HTTP と技術スタックを調査
偵察：URL	gau + waymore -> katana -> uro	アーカイブを調査（忘れられたエンドポイント）-> アクティブにクロール（JS をレンダリング）-> 重複を除去
偵察：JS	jsluice + mantra + trufflehog --only-verified	URL／シークレットを抽出 -> API キーを検出 -> キーが実際に機能するかを検証
偵察：ポート	naabu（広範囲）-> rustscan（詳細）	上位 1,000 件を高速スキャン -> 注目すべきターゲットの全 65535 ポートをスキャン
偵察：スキャン	nuclei -tags cve -> nuclei -tags takeover	既知の CVE を先に調査 -> 次にテイクオーバーを調査（すぐに対応）
マッピング：パラメーター	arjun + paramspider + ParamMiner	隠れたパラメーターをブルートフォース + アーカイブを調査 + キャッシュヘッダーを確認
マッピング：JS コード	ダウンロード -> jsluice -> VS Code/Cursor で grep	抽出 -> 静的解析 -> AI 支援による汚染解析
マッピング：検索演算子	手動で Google Dorks を使用	ターゲットごとにカスタマイズしたクエリで、自動化では見つからない情報を発見
発見：ファジング	ffuf -ac + cewl カスタムワードリスト	フィルタリングを自動調整 + ターゲット固有の単語で汎用リストを上回る
発見：XSS	kxss -> dalfox	絞り込み（どのパラメーターが反射するか）-> スキャン（反射するパラメーターのみ）
発見：SQLi	ghauri	ID に似たパラメーターに対する、最新のブラインド SQLi
発見：SSRF	interactsh-client	ブラインド SSRF/XXE/RCE 用のセルフホスト可能な OOB リスナー
発見：WAF	wafw00f -> whatwaf	WAF ベンダーを特定 -> バイパス手法をテスト
エクスプロイト：403	byp4xx または nomore403	20 種類以上のバイパス手法を自動化
エクスプロイト：テイクオーバー	subzy	CNAME を 70 種類以上の脆弱なサービスと照合
エクスプロイト：クラウド	s3scanner + aws CLI	バケットの権限をスキャン -> メタデータの認証情報を抽出
エクスプロイト：シークレット	trufflehog --only-verified	機能することが検証されたキーのみを対象にする（誤検知なし）

セッション終了時のチェックリスト

• Burp/Caido のプロジェクトファイルをすべて保存する
• 「奇妙だが、まだ悪用可能ではない」挙動（今後使える手掛かり）を記録する
• 失敗した試行をメモに追加する（同じ手法で再テストしない）
• /remember を使って発見事項を記録する

---

PART 4: 方法論の徹底（誤検知の防止）

取り下げられる発見事項の多くは、繰り返し起きる 4 つのプロセス上のミスに起因します。それぞれに厳格なルールがあります。

重要な前提： これらの徹底事項は、取り組みを制限するためではなく、発見事項の正確性に関するものです。どのシグナルが実際の発見事項で、どれがそうでないかを示します。プローブの送信数を減らすよう求めているわけではありません。これらのルールを早めに切り上げる言い訳に使っているなら、解釈を誤っています。redteam-mindset（主要指示：絶対に止めない）を読み込み、続行してください。網羅性の徹底と発見事項の正確性の徹底は互いに独立した軸であり、どちらも完全に満たす必要があります。

マーカーの規律

リフレクション、キャッシュポイズニング、パラメーターポリューション、または OOB SSRF をテストする際に注入するマーカー文字列は、必ず一意で、他と明確に区別できるものにしてください。

ルール：

• マーカーはランダムな英数字の文字列で、8 文字以上にしてください。英単語やプロトコルのキーワードは使用しないでください。
• test、marker、evil、attacker、payload、javascript、script、AAAA、BBBB、自分のドメイン名、または対象の HTML／JS／エラーメッセージに自然に含まれている可能性のある文字列は、絶対に使用しないでください。
• 適切なマーカー： cpmark987abc、x4hd2k9pq、dlsrcurl.<collab>.oastify.com のような Collaborator サブドメインのプレフィックス、または __ZZ_MARKER_<random>_ZZ__。
• リフレクションを主張する前に、マーカー文字列がベースライン（マーカーなし）のレスポンスに含まれていないか検索してください。自然に含まれている場合は、マーカーを変更してください。この確認だけで、誤検知によるリフレクション報告の 80％を見つけられます。
• OOB テストでは、Collaborator のペイロードごとに異なるサブタグ（例：dlsrcurl.<collab>、authsrc.<collab>）を付けて、コールバックから発火したシンクを特定できるようにしてください。

認可済みエンゲージメントからの教訓： 初回のスキャンで、X-Forwarded-Proto: javascript が複数の SharePoint ページにリフレクションされていると判定されました。この「リフレクション」は、SP のヘルプリンクの href（href="javascript:HelpWindowKey(...)"）に javascript という単語が自然に含まれていたものでした。一意でないマーカーが原因の誤検知です。

ボディ差分のルール

バイパスを主張するには、ステータスコードだけでなく、レスポンスのボディに差分が必要です。

ルール：

• ベースラインとボディがバイト単位で完全に同一の 200 OK は、バイパスではありません。
• ボディに 5 バイトの差があればバイパスの可能性はありますが、何が変わったのか（相関 ID？ タイムスタンプ？ 実際のコンテンツ？）を確認してください。
• バイパスを主張する前に、必ずボディを並べて差分を確認してください：diff <(curl ... baseline) <(curl ... bypass)。
• ステータスコードだけに基づく主張（例：「Host ヘッダー X で 403 ではなく 200 が返った」）は、バグバウンティプラットフォームで最もよく却下される N/A カテゴリーです。

認可済みエンゲージメントからの教訓： Host: target.example:[email protected] は、ベースラインの 403 ではなく HTTP 200 を返しました。Host ヘッダーのバイパスに見えましたが、ボディはバイト単位で完全に同一（どちらも 8341 バイト）でした。AWS ELB が Host を target.example:80 に正規化し、@evil 部分を削除していたため、バイパスではありませんでした。

統計的サンプルのルール（タイミングに基づく主張の場合）

単発の外れ値はシグナルではありません。ネットワークのジッターによって、通常でも 2 倍の外れ値が発生します。

ユーザー列挙／ブラインド SQLi／ブラインド NoSQLi／タイミングサイドチャネルに基づく主張には、以下のルールを適用してください：

• 最小サンプルサイズ：グループごとにn ≥ 10 回の交互試行（コントロールとテストをランダムな順序で実施し、連続して実施しないこと）。
• 各グループの平均値、中央値、σ を計算してください。
• シグナルとみなすには、疑わしいグループの平均値がコントロールグループの平均値を2σ 以上上回る必要があります。
• n=1 のテストで単発の 2 倍の外れ値が出ても、それはジッターであり、シグナルではありません。

認可済みエンゲージメントからの教訓： 単発のプローブでは、Authentication.asmx Login で Administrator の処理に 1527 ms、コントロールには約 700 ms かかり、ユーザー列挙の明確なシグナルに見えました。8 グループにわたって n=80 の交互試行で再現したところ、各グループの平均値は 685～716 ms、σ は 25～74 ms に収まりました。1527 ms はネットワークのジッターでした。この発見は撤回されました。

シェルループ禁止（5回超の反復）

5回を超えて反復する場合は、シェルの for ループではなく、Python（各反復で try/except を使用）を使ってください。

理由： zsh の配列展開は、特殊なケースでエラーを出さずに失敗することがあります。for x in "${arr[@]}" のようなループでは、前のコマンドで配列が設定されていないと、エラーも出ずに反復回数が0回になる場合があります。ユーザーには出力が完全に見えても、実際にはテストがまるごとスキップされていることがあります。

ルール：

• シェルで、項目を5つ以下にハードコードしたループを使うのは問題ありません。
• リスト、ファイル、算出した範囲を反復処理する場合は、Python を使ってください。
• 結果の数は必ず数えてください。100件のプローブを想定していたのに出力が50行未満なら、ループが何かを取りこぼしています。

許可を得たエンゲージメントからの教訓： zsh の配列を使った動詞改変テストでは、20回以上の反復で curl の呼び出しが一度も行われないまま、エラーも出ずに終了しました（zsh が配列を処理できていませんでした）。出力はすべてのプローブについて「HIT [GET] /_api/web → 」と表示され、テスト結果がそろっているように見えましたが、実際のレスポンスはありませんでした。およそ50件分のプローブテストが失われました。各反復で明示的にログを出力する Python に切り替えたことで、実際の結果が明らかになりました。

---

検証

このセルフテストを実行して、手法の品質ゲートが機能していることを確認してください。

1. マーカーの一意性テスト — ベースラインチェックが誤検知を検出できることを確認します。

   echo "<a href='javascript:HelpWindowKey(1)'>Help</a>" > /tmp/test-baseline.html
   MARKER="javascript"
   grep -q "$MARKER" /tmp/test-baseline.html && echo "FAIL: marker appears in baseline — choose unique marker" || echo "PASS: marker is unique"
   rm -f /tmp/test-baseline.html
   

2. 本文差分テスト — 差分によってバイト単位で同一のレスポンスを検出できることを確認します。

   echo "identical body" > /tmp/a.txt && cp /tmp/a.txt /tmp/b.txt
   diff /tmp/a.txt /tmp/b.txt >/dev/null && echo "PASS: identical bodies detected (no bypass)" || echo "FAIL: diff broken"
   rm -f /tmp/a.txt /tmp/b.txt
   

3. 統計サンプルテスト — Python で平均値と σ を計算できることを確認します。

   python3 -c "
   import statistics
   control = [700, 710, 690, 705, 715, 698, 702, 708, 695, 712]
   mean_c = statistics.mean(control)
   stdev_c = statistics.stdev(control)
   threshold = mean_c + 2*stdev_c
   suspect = 1527
   print('PASS: signal detected' if suspect > threshold else 'PASS: no false signal (correct)')
   " 2>/dev/null || echo "FAIL: Python3 statistics module unavailable"
   

4. シェルループ禁止の検証 — Python の反復処理が確実に機能することを確認します。

   python3 -c "
   items = ['a','b','c','d','e','f','g','h','i','j']
   results = []
   for item in items:
       results.append(f'processed:{item}')
   expected = 10
   actual = len(results)
   print(f'PASS: {actual}/{expected} items processed' if actual == expected else f'FAIL: {actual}/{expected}')
   " 2>/dev/null || echo "FAIL: Python3 unavailable"
   

5. モード確認チェック — エンゲージメント種別の判断フレームワークを理解していることを確認します。

   grep -q "PART 0" SKILL.md && echo "PASS: PART 0 mode-confirmation present" || echo "FAIL: PART 0 missing"
   

5つのテストすべてに合格すれば、手法の規律に関するルールを検証できます。テスト1〜2は、実際のエンゲージメントで誤検知が最もよく発生する要因です。

---

関連スキルと連携

• hunt-dispatch — PART 0 のモード（redteam / wapt + blackbox|greybox）が確定した場合に使用します。ワークフローの基本単位：エンゲージメント種別の回答が確定したら、hunt-dispatch に引き継いで対象のフィンガープリントを取得し、対応するプラットフォームと hunt-* スキルセットを読み込みます。hunt-dispatch が分類体系を出力した時点で、このスキルはアクティブなコンテキストではなくなります。
• bug-bounty — ユーザーが一般的な「何をすればよいか」という質問をした場合や、新しい対象に取り組み始めた場合に使用します。ワークフローの基本単位：bug-bounty は、トピックに応じて読み込む hunt-* スキルを指定するオーケストレーターです。このスキル（bb-methodology）は、オーケストレーターが実行する5フェーズのワークフローを提供します。
• triage-validation — 発見事項がフェーズ4を完了し、報告書にまとめられる段階になった場合に使用します。ワークフローの基本単位：フェーズ5では /validate（7つの質問によるゲート）を明示的に呼び出します。7つの質問すべてに合格した発見事項のみが report-writing に引き継がれます。
• offensive-osint + web2-recon — フェーズ1（偵察）が進行中の場合に使用します。ワークフローの基本単位：フェーズ1の「広範なアプローチ」では、資産の包括的な調査を offensive-osint に、稼働中ホストと URL のパイプラインを web2-recon に委任します。

---

オペレーター向けメモ

ベンダー提供の基盤に、エンゲージメントで得られた知見を追加したものです。実際に許可を得て行ったエンゲージメントと、このリポジトリの31以上のスキル領域に対するライブテストでのフェーズ2検証から得られた知見です。上流の方法論が「何を」扱うのに対し、このレイヤーは「実際に機能するタイミング」と「失敗モード」を扱います。

方法論に書かれていないこと

ベンダー提供の5フェーズワークフローはチェックリストですが、実際のエンゲージメントでは臨機応変な対応が必要です。フェーズをすべて省略することもあります。クライアントから単一の URL と JWT が渡され、内部チームがすでに偵察を済ませている場合、フェーズ1は10分間のフィンガープリント取得だけで終わります。一方、対象範囲が資産200件を抱える金融サービス企業の親組織なら、エンゲージメントの80％をフェーズ1に費やすこともあります。手法が示すのは、すべてのエンゲージメントに存在する地形の地図であり、均等にたどる手順ではありません。

モード確認の実践

PART 0（このファイルの冒頭にあるバグバウンティと WAPT とレッドチームの判定ゲート）は厳守すべきルールですが、答えが常に明示されているとは限りません。スコープに関する文言を確認してください。

• 「スコープ内の資産」＋「スコープ外の資産」＋「セーフハーバー」 → バグバウンティの規律です。検証を重視し、OOB を必須とし、データの持ち出しは禁止です。
• 「キルチェーン」＋「目標」＋「フラグの取得」＋「敵対者のエミュレーション」 → レッドチームです。ステルス、永続化、ラテラルムーブメントが有効です。
• 「コンプライアンス」＋「PCI」＋「HIPAA」＋「経営陣向けレポート」＋「修正タイムライン」 → WAPT です。網羅性重視で、成果物に焦点を当て、悪用可能性にかかわらずすべての検出事項を対象とします。

文言が混在している場合（よくあることです。クライアントは WAPT 形式の SOW を作成し、それをレッドチームエンゲージメントと呼ぶことがよくあります）、確証が得られるまではバグバウンティの規律を適用します。これは最も検証に厳格なモードです。クライアントがレッドチームだと確認すれば、後から緩和できます。反対に、実際は WAPT なのにレッドチームの裁量があると想定すると、納品時に検出事項を撤回することになります。

対象の種類によるフェーズの優先度の変化

5 つのフェーズの重みは同じではありません。エンゲージメントの種類によって時間配分が決まります。

エンゲージメント	偵察	探索	検証＋レポート
SaaS のバグバウンティ（スコープ明確）	10%	70%	20%
外部レッドチーム（広いスコープ）	40%	30%	30%
WAPT（資産リスト提供済み）	0%	60%	40%
エンタープライズのオンプレミス（単一製品）	5%	50%	45%

SaaS のバグバウンティエンゲージメントで、偵察に 50% の時間を費やしているなら、探索を先延ばしにしています。外部レッドチームエンゲージメントで偵察に 10% しか費やしていないなら、すでに失敗しています。これらの案件では、攻撃対象領域のマップそのものが成果物です。

方法論を中断する場合

偵察を始めて最初の 30 分以内に Critical を見つけた場合は、偵察を中断し、Critical を徹底的に検証して報告してから、偵察に戻ります。 方法論では「次に進む前にフェーズを完了する」とされていますが、時間あたりの価値曲線はそれに反します。エンゲージメント開始から 24 時間以内に確認済みの Critical が報奨金の対象になるほうが、活用する機会のない包括的な資産リストより価値があります。

逆の場合も同様です。候補の調査に 4 時間以上費やしても、2 つ目のアカウントで再現しないなら、その候補は無効です。無効な候補を再現させるために、さらに 4 時間費やしてはいけません。候補から外し、メモに取り下げを記録して、先に進みます。

規律に関するルールは交渉の余地がありません

このファイルに記載されている規律に関するルール、すなわち OOB Gate、Marker Discipline、Body-Diff Rule、Statistical-Sample Rule、Server-Policy-vs-State、Pre-Severity Gate、Shell-Loop Ban は方法論ではありません。これらは品質ゲートです。方法論は作業の順序であり、これらは各手順における検証の保証です。

Phase 2D の強化ラボキャンペーンで検証済みです。偽のバグに見せかけた挙動（XSS に見せかけた URL のエコー、リフレクションに見せかけた単語の偶然の一致、バイト単位で同一の本文に対するステータスコードだけの「バイパス」、実際の漏えいデータがない 200 OK の漏えい主張）に対して、8 つすべての規律に関するルールが正しく機能しました。これらのルールを省略すると、検証率は急激に低下します。摩擦があること自体が機能です。ルールが邪魔だと感じるなら、それはルールが本来の役割を果たしている証拠です。ルールによって排除される検出事項は、どうせ最終的に N/A に戻されるものの半数です。

• evidence-hygiene — Phase 5 で PoC のスクリーンショット／HAR を収集するときに使います。ワークフローの基本要素です。スクリーンショットに Cookie／PII が表示される前に、秘匿処理の手順を evidence-hygiene に引き継いでください。