bb-methodology

バグバウンティの方法論：ワークフローと考え方

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

---

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

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

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

絶対ルール： フェーズ 0 を実行する前に、ハンティングノートの最初の行にエンゲージメントの種類を記載してください。ユーザーの指示から判断できない場合は、一度だけ質問してください。決めつけてはいけません。この誤りは、あなたとトリアージ担当者の両方に損失をもたらします。

認可されたエンゲージメントからの教訓： このターゲットの初回調査では、レッドチーム形式で提出できるハイジーンの発見事項が 5 件ありました（SP2013 の EoL、制限の緩い CSP、スタックトレース）。エンゲージメントはバグバウンティでした。発見事項は「情報提供のみ、影響の実証なし」として N/A 扱いになるところでした。ハイジーンを発見事項ではなくコンテキストとして扱い、修正した調査を行った結果、同じターゲットから、Critical 3 件を含む、影響が実証されたバグが 11 件見つかりました。

---

パート 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 構造が違う -> 異なるバックエンドシステム
• 環境の差分: 本番 vs 開発/ステージング -> デバッグヘッダー、CSP 無効化
• バージョンの差分: 更新前後の JS ファイル -> 新しいエンドポイント、削除されたパラメータ
• サプライチェーン: フレームワーク/ライブラリのバージョンに既知の CVE がないか確認
• サードパーティ連携: Stripe/Auth0/Intercom -> Webhook 署名が欠落していないか?

4. 戦略的思考 (全体像)

• 非対称性: 防御側はすべての穴を塞がなければならない。あなたは 1 つ見つければよい。
• 直感のエンジニアリング: 何かが「おかしい」と感じたらその理由を記録する。後で検証する。メンタル DB を更新する。
• 未知の管理: 理解できないものは? 「後で調査」リストに追加する。ジャストインタイム学習。

アマチュア vs プロ: 7 フェーズ比較

フェーズ	アマチュア	プロ
偵察	メインドメインのみ	シャドー IT、開発環境、すべての資産
発見	エラーを探す	設計上の矛盾、ビジネスロジックの欠陥を探す
悪用	ブロックされたら諦める	フィルターバイパス用ペイロードを構築する
昇格	現象のみを報告する	実際の被害 (セッション窃取、ATO) まで連鎖させる
実現可能性	非現実的な条件を含める	攻撃の前提条件を最小化する
報告	事実のみを述べる	ビジネスリスクを定量化する
再テスト	古い PoC が失敗するか確認する	修正方法を分析し、不完全なパッチを見つける

2 つのアプローチ経路

• 経路 A (機能ベース): 「この機能は複雑だ」-> その入力処理を深掘りする -> 脆弱性を発見
• 経路 B (脆弱性ベース): 「IDOR が欲しい」-> 連番 ID を持つエンドポイントを探す -> アクセス制御をテスト

アンチパターン (これらはやめる)

• プログラムの渡り歩き: 1 つのターゲットに最低 2 週間 / 30 時間は取り組む
• ツールだけの狩り: 自動化が見つけるのは重複。手動テストがユニークなバグを見つける。
• ラビットホール: パラメータごとに最大 45 分。タイマーを設定する。行き詰まったら、一晩置く。
• 目標がない: 「ただ見て回る」= 時間の無駄。常に最初に定義する。

---

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
メイン Web アプリ、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)	権限をテスト (読み取り/書き込み/一覧)
ホストで 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 で BizLogic を調査
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）を試す -- content-length の差を確認する

見つかったもの	次のアクション
影響の小さい挙動（リダイレクト、セルフ 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 169.254.169.254? -> 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 ライブラリ）を使って再現してください。複数ツールで結果が一致すれば、ツール固有のアーティファクトによる発見（例：curl でのみ発生し、Python の requests では消えるタイミング差はアーティファクトであり、バグではありません）を除外できます。

独立した再現の例：

• 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[@]}" のようなループでは、前のコマンドで配列に値が設定されていないと、エラーなしに反復回数がゼロになることがあります。出力は完全に見えても、実際にはテストが丸ごとスキップされています。

ルール：

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

認可を受けたエンゲージメントから得た教訓： zsh の配列を使った動詞改ざんテストで、20回以上の反復にわたって curl が一度も実行されないまま、黙って終了しました（zsh が配列を処理できませんでした）。出力には、すべてのプローブで「HIT [GET] /_api/web → 」が繰り返し表示されていましたが、実際のレスポンスは含まれていませんでした。約50件分のプローブが失われました。反復ごとに明示的にログを記録する Python に切り替えたことで、実際の結果が明らかになりました。

---

関連スキルと連携

• hunt-dispatch — PART 0 のモードが確認された場合（redteam / wapt + blackbox|greybox）。ワークフローの基本処理：エンゲージメントの種類に関する回答が確定したら、hunt-dispatch に引き継ぎます。対象をフィンガープリントし、対応するプラットフォームと hunt-* スキルのセットを読み込みます。ディスパッチによって分類体系が表示された時点で、このスキルはアクティブなコンテキストではなくなります。
• 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 に委任します。

---

オペレーターノート（Claude-BugHunter）

ベンダー提供の基盤に、エンゲージメントから得た知見を追加したものです。実際に認可を受けて行ったエンゲージメントと、このリポジトリの31以上のスキル領域の実環境テストで行ったフェーズ2の検証から得た知見です。上流の方法論が WHAT（何をするか）を扱うのに対し、このレイヤーでは WHEN-IT-ACTUALLY-WORKS（実際に機能する条件）と FAILURE-MODES（失敗パターン）を扱います。

この方法論で説明されていないこと

ベンダー提供の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 に引き継いでください。