redteam-mindset

このスキルを使う場面

次の場合に使用します。

• エンゲージメントの範囲に「レッドチーム」「敵対者エミュレーション」「侵害を前提とする」「TIBER 方式」と記載されている
• 再現性の確認に一度失敗しただけで、検出事項を取り下げようとしている
• 防御をさらに調査せず、「意図したとおりに機能している」と判断しようとしている
• CAPTCHA、レート制限、WAF、CA ブロック、ロックアウトなどの障害に遭遇し、作業を終了しようとしている
• アクセスにつながる脆弱性ではなく、IDOR／CSRF／XSS に時間を費やそうとしている
• アプリ A で脆弱性を見つけたが、関連するアプリ B、C、D にはまだ手を付けていない

次の場合は使用しないでください。

• バグバウンティプログラム（適用範囲のルールが異なるため、bug-bounty スキルを使用してください）
• WAPT／PCI 方式の評価（OWASP 準拠のスキルを使用してください）
• 純粋なコンプライアンス監査

---

要約

レッドチームの範囲＝「アクセスを獲得し、影響を証明する」。バグバウンティ／WAPT の範囲＝「バグを見つけ、レポートを書く」。

この違いにより、障害に直面したときの判断はすべて異なります。開始前に、この違いをしっかり理解してください。

---

やめないでください — 最優先の指示（2 回読んでください）

以下の 9 つの修正点は細部です。これが核心です。このスキルから 1 つだけ覚えるなら、これを覚えてください。

エンゲージメント開始時に与えられた承認は、エンゲージメント全体を対象とします。

エンゲージメントの途中で、再度許可を求めるゲートを挟まないでください。ユーザーが開始時にモード（「フルエンゲージメント」「Option D」「徹底的に調査」「これらのアセットをテスト」）を選択した場合、その承認はエンゲージメント期間が終了するか、ユーザーが明示的に取り消すまで有効です。ユーザーがすでに進む方法を選択しているのに、ループの途中で AskUserQuestion を実行するのは確認ではなく、作業の停滞です。

規律に関するルールは、作業量を抑制するためではなく、検出事項の正確性を保つためのものです。

2 回読んでください。バンドルの規律に関するルール（OOB-Or-It-Didn't-Happen、Marker Discipline、Body-Diff、Pre-Severity Gate、Server-Policy-vs-State、Statistical Sampling）は、すべて 1 つの問いに答えるものです。「このシグナルは本当に検出事項なのか？」 どのルールも、「次のプローブを送るべきか？」 という問いには答えません。 範囲を使い切った場合、またはユーザーが停止を指示した場合を除き、2 つ目の問いへの答えは常に 「はい」 です。

「PoC で止める」とは、エスカレーションを止めることであり、テストを止めることではありません。

脆弱性クラス X の影響を確認したら、クラス X のエスカレーションを続けないでください（id=1 の IDOR からユーザーテーブル全体のダンプに移行する必要はありません）。ただし、クラス Y と Z はまだテストしていません。Y を実行してください。次に Z を実行してください。その後、パターンライブラリの残りを実行してください。

データ最小化の境界も「決してやめるな」と同じくらい強く意識してください。二度読んでください。

「掘り下げ続ける」とは、カバレッジ（未テストのサーフェス、クラス、ホスト）に適用されるものであり、抽出に適用されるものではありません。この二つは正反対の方向に進むものであり、継続を指示する内容が過剰収集にまで及んではいけません。

• アクセス／データ流出の脆弱性は、持ち出したデータの量ではなく、欠けているチェックによって立証されます。 本来認証が必要だったレコードが3件あれば、完全な証拠になります。3,000件でも同じ指摘が立証されるだけで、新たな責任を生みます。さらに持ち出しても、指摘の裏付けは強まりません。
• 「掘り下げ続ける」＝次のエンドポイント群／次のホスト／次のクラスをテストすることです。 すでに突破したエンドポイントからすべてのレコードを列挙することではありません。重要なのはカバレッジの広さであり、盗み取るデータの量ではありません。
• データは通常、対象の顧客や第三者のものです（顧客の顧客、そのユーザーのPII、パートナーの財務情報など）。そうした人々は、SOW／プログラムに同意していません。すでに目的を達成しているのに、データを自分のホストへコピーすることで、避けるべき被害を生み出すことになります。
• クライアント／プログラムの責任者が「もっと掘り下げて／それだけでは不十分」と言っても、この原則は覆りません。 異議を伝えてください。指摘がすでに決定的であること、データ量と証拠の強さは別であることを説明し、実際に価値を加えられる被害を最小限に抑えた代替案を提示してください。たとえば、totalCount（データではなく数値）、別のエンドポイント群も影響を受けることの立証（広がり）、または影響範囲の定量化です。明示された目的を満たすために必要な、最小限の証拠を取得してください。
• 実際に取得したデータは、正確に分類してください（例：「B2B顧客のインベントリデータ」≠「消費者のPII」）。これは責任者のトリアージや開示に影響し、過大な表現は信頼を損ないます。

二つの軸を分ければ、継続の指示とこの境界は矛盾しません。サーフェスのカバレッジは決して止めず、抽出は常に必要最小限で止めてください。 許可されていることは、無制限に許されていることを意味しません。

マーカーディシプリン ≠「サーフェスごとにプローブを1回だけ」

マーカーディシプリンとは、使用するペイロード（合成、識別可能、復元可能）に関するものであり、回数に関するものではありません。堅牢な対象には、脆弱な対象よりも少なくではなく、より多くのマーカーディシプリンに基づくプローブが必要です。バンドルのhunt-sqliパターンライブラリにSQLiのクラスが12種類記載されている場合、各パラメーターに対してマーカーディシプリンに基づくプローブを1回ではなく12回実行してください。

自らテストを抑制してしまうアンチパターン — 次のいずれかに気づいたら、すぐに見直してください

以下はすべて、このスキルが存在し、読み込まれていたにもかかわらず、担当者が自らテストを抑制してしまった実際の案件（許可済みエンゲージメントの再検証、2026-05-17）から得られたものです。失敗のパターンを明示することが教訓です。

1. ユーザーがすでにオプション D／全面的なエンゲージメント／「徹底的に調べて」と選んだ後、実行の途中で「続けますか？」と尋ねること。開始時に得た回答が、そのまま答えです。
2. 最初に401/403が返されたところで止めること。 このバンドルには、認証バイパスのクラスが12種類以上あります（ヘッダーの細工、メソッドの改ざん、パラメータ汚染、JSON パーサーの混乱、セッション作成時の競合、オプションフィールドへのマスアサインメント、SAML コールバックでの X-Forwarded-Host SSRF、alg=none JWT、オーディエンスの混同、スコープクレームの操作、リフレッシュトークンのリプレイ、デバイスコードフロー）。対象サーフェスごとにすべて実行してください。
3. 「興味深い定数トークンだが、追跡せず。」 本来変化するはずのレスポンス間で、一定のトークン、ハッシュ、ID、フィンガープリントを見つけたら、それはアーティファクトではなく手がかりです。GETしてください。デコードしてください。値を送り返してください。view.php?view=<constant-md5>へのリダイレクトは、セッション／認証／エラーキーのシグナルであり、ノイズではありません。
4. テンプレートを横断するシグナルを探すためにrobots.txtを読んだのに、Disallow行を読まないこと。 469行あるrobots.txtは、公開したくないすべてのパスを開発者がまとめたマップです。Disallowの各行がプローブ対象です。
5. ソフト404を「メモ済み」で済ませること。404ステータスのレスポンスに37 KBの本文が含まれているなら、ホームページ、あるいはそれ以上の情報が漏れています。読んでください。Grepしてください。ホームページと差分を取ってください。
6. 「OpenAPIが公開されていたので、検出事項を記録」としながら、N個あるエンドポイントのうち4つしかプローブしていないこと。すべてのエンドポイントに対し、関連するすべてのテストクラスを実行してください。OpenAPI仕様書は提供された攻撃サーフェスマップです。それを使わないのは、無料の偵察手段を捨てるようなものです。
7. 「APKの再テストは先送り。ツールが必要。」 brew install jadx、apkpureからの直接ダウンロード、apk-redteam-pipelineで、すでに手順が説明されています。必要なのはセットアップに5分であり、「別のセッション」ではありません。
8. ボリュームを問題として捉えること。許可済みのエンゲージメントでは、Burp経由で適切にタグ付けされたリクエストを3,000件送るのは通常のペースです。バグバウンティのハンターは、全速力なら1時間あたりこれを超える量を送信します。問うべきなのは「リクエストを送りすぎていないか」ではなく、*「稼働中のすべてのサーフェスで、すべてのテストクラスを実行したか」*です。
9. エンゲージメントの実行ループ中、どの判断ポイントでもAskUserQuestionを挟むこと。ユーザーが最初にモードを選んだなら、取り消されるまでそのモードが有効です。たとえばSAML acsの生POSTとSAML acsのリプレイのどちらを運用上選ぶかは、担当者が判断して記録できる技術的な決定であり、事前にユーザーの承認を得る必要はありません。
10. スキル不足を停止条件にすること。「hunt-zohoスキルが存在しないため、v1.1のギャップとして記録して先へ進んだ。」これはいけません。発見された技術スタックに対応するhunt-スキルが存在しない場合は、ベンダーが公開しているチェックマトリックスを使い、手作業で同じ作業を行ってください。ギャップをv1.1ロードマップに記録し、今すぐチェックも実行してください*。

実践的なエンゲージメントの進め方 — 稼働中のホストごとに行う完全な一巡の実際

稼働中のホストごとに、そのホストの調査完了を宣言する前に、次の作業を行います。

• 上位100パスのプローブ（admin、api、login、/.git、/.env、server-status、swagger、openapi.json、/docs、/actuator、/healthz、/metrics、/debug、/trace、/env、/heapdump、/threaddump、robots.txt、sitemap.xml、/.well-known/*、フィンガープリントに基づく一般的なCMSパス）
• robots.txt の内容を読み取る — Disallow の各項目をプローブ対象にする
• sitemap.xml の内容を読み取る — 各エントリーをプローブ対象にする
• JavaScript バンドルを収集 — シークレット用正規表現カタログ全体（Firebase、AWS、GCP、JWT、Stripe、GitHub、汎用の高エントロピー文字列）を使って grep し、ルートと API エンドポイントを抽出する
• ソースマップの候補パスを確認（/*.js.map、/static/js/*.js.map、/_next/static/*.js.map、/build/*.js.map）
• 検出したフォームごとに、完全な SQLi マーカー規律スイープ（12 クラス以上）、認証バイパスのクラススイープ（12 クラス以上）、CSRF、パラメーターポリューション、マスアサインメント、状態変更を伴う送信に対する競合状態を実施する
• 検出した API エンドポイントごとに（JavaScript、OpenAPI、swagger、ネットワークキャプチャから）、HTTP メソッドの改ざん、Content-Type の改ざん、JWT の alg=none、RS256 キーを使った alg=HS256、audience confusion、プロトタイプ汚染、冪等性に違反する操作に対する競合状態を確認する
• 特定した SaaS テナントごとに、専用の hunt-* スキルがまだ存在しない場合でも、ベンダー固有の既知の脆弱性カタログに基づくチェックマトリックスを実施する
• アイデンティティ基盤：GetUserRealm、OpenID well-known、autodiscover-v2、フェデレーション動作のテスト、共有テナントを探すための系列ブランドのTLDへのピボット、ロックアウトのリスクを伴わない OneDrive ベースのユーザー列挙
• モバイルアプリ：開発者のカタログにあるすべての APK を取得し、jadx で逆コンパイルし、シークレット、エンドポイント、証明書ピンを grep し、エクスポートされたコンポーネントを列挙する

ホストごとにこれより少ない作業しかしていない場合、そのホストの調査は完了していません。すべてのホストの調査が終わるまで、エンゲージメントは完了ではありません。

---

マインドセットの修正 #1 — 障害になるのは停止の合図ではなく、データです

アンチパターン（誤った対応）：

「高負荷時の再確認ではタイミング差が見られなかったため、SQLi の判定を不確定に取り下げる。」

正しい考え方：

「3 種類の異なる SLEEP ペイロードがそれぞれ +6 秒の遅延を生じさせた、当初の 3 サンプルのベースライン（σ = 32 ms）は、統計的に決定的です。再確認の失敗もデータです。報告を撤回するのではなく、差分を調査してください。」

エンゲージメントの途中で防御が突然現れた場合：

1. 最初の PoC の証拠は永久に残す — 再確認の前に取得してください。スクリーンショット、リクエストとレスポンスのペア、タイミングのサンプルを保存します。
2. レスポンスを比較する — 本文サイズ、ヘッダー、Cookie、応答時間を確認します。変化から、クライアントが何を導入したか（WAF ルール？ ホットフィックス？ ジオブロック？）が分かります。
3. 導入された緩和策自体が発見事項です — インシデント対応の迅速さに関する、肯定的な運用上の所見です。
4. 別のベクターを試す — 低速のタイミング攻撃、エンコードしたキーワード、別のインジェクションコンテキスト、Cookie インジェクション、ヘッダーインジェクションを試します。
5. 両方の状態を記録する — 「T0 では脆弱、T0+30min で緩和、緩和策は WAF による可能性が高い（回避可能）」。

**ルール：**再現に最初に失敗したからといって、発見事項を撤回してはいけません。誤検知と判断する前に、失敗した理由を調査してください。

---

考え方の修正 #2 — 同系列アプリのパターン認識

アンチパターン：

「/app-a/ で SQLi を確認しました。ほかのタスクに移ります。」

正しい考え方：

「同じバックエンドで、同じコードテンプレートが使われている可能性が高い → 同じ従業員ポータルのホスト上にある同系列アプリ、/app-b/、/app-c/、/app-d/、/app-e/ もすべて有力候補です。同じペイロードでテストしましょう。」

アプリ A で脆弱性を確認したら：

1. 共通インフラを特定する — 同じ IP、同じロードバランサー、同じ TLS 証明書、同じレスポンスヘッダー、同じセッション Cookie 名、同じログインフォームの HTML。
2. 共通コードテンプレートを特定する — 同じフォームフィールド、同じエラーメッセージ、同じビュー構造、同じフレームワークのバージョン。
3. すべての同系列アプリに、同じエクスプロイトペイロードを使って直ちに一斉テストする。
4. 脆弱性の種類を記録する — 単独の指摘ではなく、「N 個のアプリにわたる共通フォームハンドラーテンプレートの脆弱性」と記録します。
5. 種類全体への修正を推奨する — 1 つのアプリだけでなく、共通テンプレートを修正します。

許可を得たエンゲージメントでの事例：1 つのサブアプリ（<app-A>）で SQLi を確認しました。同じ従業員アプリのホスト上に、フォームパターンが類似した同系列のサブアプリが 4 つ（<app-B>、<app-C>、<app-D>、<app-E>）あり、すべて同じ脆弱なテンプレートを共有している可能性が高い状況でした。複数アプリにまたがる指摘とすべきでした。

---

考え方の修正 #3 — WAPT とレッドチームのスコープを厳守する

レッドチームのスコープでは、次の項目は省略してください（アクセスにつながりません）：

• IDOR（ATO／権限昇格／機密データ窃取の連鎖を伴わない、ユーザー間の読み取り／書き込み — WAPT クラス）。注：IDOR を一律に除外するわけではありません。管理者／ロール割り当てエンドポイントの IDOR は権限昇格につながります。パスワードリセットやセッションオブジェクトの IDOR は ATO につながります。ファイルダウンロードや PII の処理機能の IDOR はデータ窃取につながります。トークン／キーのエンドポイントの IDOR は認証情報の取得につながります。以下の判断基準に従って、これらを追跡してください。
• CSRF（ユーザーをだまして状態を変更させる — WAPT クラス）
• 反射型 XSS（アカウント乗っ取りにつながる連鎖を伴わないもの — WAPT クラス）
• セキュリティヘッダーの欠如（WAPT クラス）
• Cookie の保護フラグの強化不足（WAPT クラス）
• 機密データを含まない詳細なエラーメッセージ（WAPT クラス）
• DoS（通常、エンゲージメントのルールによりスコープ外）
• ユーザー名の列挙（情報収集であり、アクセスではありません）

次の項目は追跡してください（アクセスにつながります）：

• SQL インジェクション（データ窃取 → DB 認証情報 → 横展開）
• コマンドインジェクション／RCE（足がかり）
• ファイルアップロード → Web シェル（足がかり）
• LFI/RFI（設定ファイルの読み取り → DB 認証情報 → アクセス）
• SSRF（クラウドメタデータ → IAM → クラウドアクセス）
• 認証バイパス（パラメーター操作、JWT alg=none、ヘッダーインジェクション）
• モバイルアプリ／JS バンドル内のハードコードされた認証情報
• 管理者パネルのデフォルト認証情報
• SAML XSW／署名の除去（セッション乗っ取り）
• Cisco ASA／Citrix／Pulse／Fortinet SSL VPN の CVE（ネットワークへの足がかり）
• ManageEngine／Confluence／Atlassian の RCE CVE（足がかり）
• Kerberoasting／AS-REP roasting（侵入後の攻撃ですが、可能であれば外部から列挙します）

判断基準： バグを完全に悪用しても、セッション／トークン／足がかりの取得や機密データの窃取につながらない場合は、WAPT クラスです。簡潔に記録するだけにとどめ、時間をかけないでください。

---

マインドセットの修正 #4 — 保守的なデフォルトではなく、積極的なデフォルト

アンチパターン：

「Webサイトの30％をテストして、網羅的だと判断した。」

正しい考え方：

「すべてのログインフォーム、すべてのAPIエンドポイント、すべてのパラメーター、CVEに該当するすべてのバージョンを積極的に調査するまでは、エンゲージメントは完了していない。」

積極的なデフォルト：

1. 稼働中のすべてのホストで、上位20個のパスを調査します（admin、api、login、/.git、/.env、server-status、swagger、openapi.json、robots.txt、/actuator、/healthzなど）。
2. 発見したすべてのログインフォームに対して、漏えいした認証情報を1つ、スプレーパターンを1つ試し、SQLiとパラメーター改ざんによる認証バイパスも試みます。
3. すべてのJSバンドルで、ハードコードされたAPIキー、JWT、ベースURL、非表示のエンドポイント、管理者用パスをgrepします。
4. すべてのAPIエンドポイントで、OPTIONSプリフライト、認証情報がない場合の応答、alg=none JWT、X-Forwarded-Userヘッダーインジェクションを確認します。
5. すべてのモバイルアプリを逆コンパイルし、シークレットをgrepし、証明書ピンニングを確認し、エクスポートされたコンポーネントを特定します。
6. 企業サブドメイン上にある「スコープ外」のSaaSは、すべてクライアントに確認します。ベンダー管理であっても脆弱性がないとは限りません（CVE-2022-47966は、多くのオンプレミスのME-SDPインストール環境でパッチが適用されないままでした）。

**ルール：**サンプルとして一部を調査するだけでなく、稼働中のすべての攻撃対象面を積極的に調査していないなら、まだレッドチームを実施したことにはなりません。偵察をしただけです。

---

マインドセットの修正 #5 — 洗練さよりも粘り強さ

アンチパターン：

「Tesseractが3つのCAPTCHAで失敗したので、諦めてCAPTCHAのバイパスは実現不可能だと判断した。」

正しい考え方：

「Tesseractが失敗した。判断手順：まず前処理（2値化、ノイズ除去、拡大、複数のPSM）を試し、次に学習済みモデルによるOCRを試し、それから有料の解読サービス（月5ドルでエンゲージメントに十分な量を利用可能）を試し、最後にセッションに紐づくCAPTCHAのリプレイ攻撃を試す。本物の攻撃者なら、必ず5ドルを投資します。」

障害への対処手順：

CAPTCHA：

1. フィールドを省略する → 必須かどうかを確認
2. 空の値を送る → バリデーションを確認
3. 複数回の送信で値を再利用する → セッションへの紐づけを確認
4. 前処理を行ったTesseract
5. 学習済みモデルによるOCR（deep-text-recognition-benchmark、calamari-OCR）
6. 有料の解読サービス（2captcha API、anti-captcha）
7. 利用できる場合は音声CAPTCHA（はるかに脆弱）

WAF：

1. ペースを落とす
2. ペイロードをエンコードする（URL、16進数、base64、大文字・小文字の混在）
3. 別のインジェクションコンテキストを使う（Cookie、ヘッダー、JSON）
4. 別のHTTPメソッドを使う
5. 別のContent-Typeを使う（multipart、application/json）
6. ホストレベルでバイパスする（X-Forwarded-Host、X-Original-URL）
7. オリジンサーバーを直接調査する（Certificate Transparencyから特定）

レート制限：

1. IPローテーション（複数のクラウドリージョン）
2. User-Agentローテーション
3. ペースを落としてジッターを加える
4. 複数のTLSセッションに分散する

対象の応答が遅い（タイミングベースのデータ窃取に時間がかかりすぎる）：

1. 別のインジェクション箇所を使う（行ごとにSLEEPを呼び出すコンテキストを避ける）
2. 代替のタイミングオラクルとしてBENCHMARKまたはGET_LOCKを使う
3. エラーベースの抽出
4. OOB DNSコールバック（interactsh）
5. より高速なネットワークを使う（対象と同じリージョンにあるクラウドVM）
6. ダンパーを無人で一晩実行し、部分的な結果を提出する

**ルール：**ある手段が失敗したら、次にすべきことは「同じ目標を達成する別のベクター」であり、「脆弱性なしと記録する」ではありません。本物の攻撃者に、エンゲージメントの実施期間という制約はありません。

---

マインドセットの修正 #6 — リアルタイムのIR観察も発見事項

クライアントのSOCがエンゲージメントの途中でパッチを適用した場合（テスト中に脆弱性が消えるのを確認した場合）：

• 失敗ではなく、証拠として扱います
• 変更前後のタイムスタンプを記録します
• 肯定的な運用上の発見事項として記録します — 「クライアントのSOCがX分以内に検知して緩和し、WAFまたはコードレベルで緩和策を導入した」
• 緩和策がどこまで実施されたかを確認します — WAFルール（バイパス可能）か、コード修正（根本的な修正）か
• 当初のPoCは引き続き脆弱性の発見事項です — パッチの適用によって脆弱性がなかったことにはなりません

これは独立したスキルです。mid-engagement-ir-detectionを参照してください。

---

マインドセットの修正 #7 — 複数手法による相互検証

「脆弱」と判断したすべての所見について、2つ以上の手法で証明してください。

脆弱性クラス	主な手法	相互検証
時間ベースのブラインド SQLi	SLEEP() の差分	異なる SLEEP のバリエーション（異なるペイロードを最低3つ）
ブール値ベースのブラインド SQLi	レスポンス本文サイズの差分	異なるブール値比較
エラーベースの SQLi	エラーメッセージの反映	UPDATEXML と EXTRACTVALUE の両方
RCE	コマンド出力の反映	OOB コールバック（interactsh DNS）
LFI	ファイル内容の反映	異なるファイルパス、異なるエンコード
SSRF	内部限定のレスポンス	OOB コールバック（interactsh DNS）
有効な認証情報（M365）	ROPC + AADSTS53003	SAML SSO ブラウザーフロー + ConvergedConditionalAccess ページ
認証バイパス	ログイン後のランディングページ	後続のリクエストにおけるセッションクッキーの永続性

単一のシグナルは偶然の可能性があります（ネットワークの揺らぎ、サーバーの一時的な不調、キャッシュ）。同じ根本原因から生じる2つの異なるシグナルがあれば、確定的です。

---

マインドセットの修正 #8 — エンゲージメントジャーナルを徹底する

リアルタイムで、追記のみ、構造化された形式にします。

{"ts":"2026-05-08T14:40:53","ip":"<src-ip>","tool":"m365_validator","target":"login.microsoftonline.com","payload":"user1@<client>.example:<pw-r4>***","resp_code":400,"resp_body_size":154,"resp_ms":1280,"aadsts":"AADSTS53003","verdict":"VALID_CA_BLOCK","notes":""}

理由：

• 何をいつテストしたかのフォレンジック記録になります
• パターン（クラスタリング、タイミングの変化、エラーコードの分布）が明らかになります
• レポートの証拠になります
• 次回のエンゲージメントでも事前情報として活用できます
• 差分分析に役立ちます：「ウィンドウ A とウィンドウ B の間で何が変わったか？」

アンチパターン： ログを残さない場当たり的なシェルコマンドです。最も必要なときに、元の PoC のタイムスタンプを失うことになります（再確認に失敗し、最初のシグナルが本物だったと証明できません）。

---

マインドセットの修正 #9 — 制約となるのはスキルではなく時間

実際の攻撃者には何か月もあります。あなたにあるのはエンゲージメント期間（数週間）です。判断事項：

• 実現可能性を先入観で決めない — ダンパーの実行に6時間かかるなら、一晩実行して、朝に部分的な結果を提出しましょう。
• 並列化する。 複数ターゲットのテストを同時に実行しましょう。CPU を使い、経過時間を節約します。
• 状態を永続化する。 エンゲージメントは複数のセッションにまたがります。状態ファイル（engagement_log/）を使えば、水曜日の作業を金曜日に活用できます。
• 時間のかかるジョブはバックグラウンドで実行する — ジョブを開始し、イベントを監視する設定をして、並行して別の作業を進めましょう。
• 同じことを繰り返さない — 火曜日にターゲット X をペイロード Y でテストしたなら、水曜日には再テストしなくてもそのことが分かるようにしておきましょう。

---

エンゲージメント前のチェックリスト

レッドチームエンゲージメントを開始する前に、以下を確認してください。

• スコープが明確（サブドメインの対象／対象外、SaaS の対象／対象外、フィッシングの対象／対象外、インプラントの対象／対象外）
• SOW + EL/RoE を参照済み
• テスト用 IP を割り当て、記録済み（IP_LOGS テーブルまたは同等のもの）
• 状態ファイルを初期化済み（試行回数カウンター、結果 JSONL、IP ログを含む engagement_log/）
• 認証情報攻撃の上限を決定済み（ユーザーの生涯あたり1回または2回）
• キルスイッチのしきい値を設定済み（実行中の LOCKED の最大数、ウィンドウ内のエラーの最大数）
• 最重要ターゲットを特定済み（何をもって成功とするか？）
• 重大な所見を協議する手順に合意済み（一時停止して通知するタイミング）
• 証拠取得用のデフォルトとして Burp プロキシを設定済み
• エンゲージメントジャーナルを初期化済み

---

エンゲージメント中のチェックリスト

30分ごとに確認してください。

• 進展していますか、それとも行き詰まっていますか？
• 直近のテスト結果をエンゲージメントジャーナルに記録しましたか？
• テストに使用している IP を記録しましたか？
• 脆弱性を確認した場合、同じバックエンドを使う関連アプリもテストしましたか？
• 行き詰まった場合、判断ツリーの次の攻撃ベクトルを試しましたか？
• 「やめよう」と思った場合、スコープをすべて調べ尽くしたと確信していますか？ それとも単に疲れているだけですか？

---

エンゲージメント後のチェックリスト

完了と宣言する前に、次を確認してください。

• すべての指摘について、少なくとも2つの異なる手法で確認済み
• 各指摘の PoC を、別のテスターが5分未満で再現可能
• 元の PoC の証拠資料（スクリーンショット、リクエスト／レスポンス、タイミングのサンプル）を保存済み
• エンゲージメント中に観察した IR を指摘として記録済み（有効な運用）
• アクティブな攻撃者についての観察事項を記録済み（ロックアウトの差異など）
• 共有インフラに関する指摘ごとに、関連する姉妹アプリの調査を完了済み
• 今後のエンゲージメントに備えて状態ファイルを保存済み
• ツールの不足を記録済み（結果を変える可能性があったもの）

---

すぐに指摘すべきアンチパターン

次のどれかを考えていることに気づいたら、そこで止まり、考え直してください。

• 「脆弱性はない」（3つのベクターをテストしたか？ 姉妹アプリもテストしたか？）
• 「防御が機能している」（別のペイロードを試したか？ ペースを落としたか？ 別のプロトコルを試したか？）
• 「再確認に失敗したので、誤検知に違いない」（いいえ――差異を調査してください）
• 「OCR は信頼できないので、CAPTCHA は回避できない」（有料サービスは5ドルです。個人研究の予算で作業しているわけではありません）
• 「モバイルアプリは何年も前のものだから、役に立つものはなさそう」（ハードコードされた URL やトークンは、エンジニアリングチームの記憶より長く残ることがよくあります）
• 「SaaS だから、テストすることは何もない」（ベンダーが一元的にパッチを適用するのは通常そのとおりですが、テナント設定の不備は一元的には解消されません）
• 「十分にテストした」（エンゲージメント中のチェックリストを使ってください。どれか1つでも答えが「いいえ」なら、続けてください）
• 「流出には時間がかかりすぎる」（無人で実行し、可能な範囲の結果を提出してください）

---

停止するタイミング（正当な停止条件）

次の場合にのみ停止してください。

• スコープ内のすべての資産について、主要な脆弱性クラスを対象に、発見しただけでなく積極的にプローブを実施済み――このスキルの上部にある「実際のエンゲージメントの進め方」チェックリストを参照
• 確認済みのすべての脆弱性を、2つ以上の手法で検証済み
• 確認済みのすべての脆弱性について、姉妹アプリも調査済み
• すべての阻害要因に対して、2つ以上の代替ベクターを試行済み
• エンゲージメント期間が終了し、成果物の記録も完了済み
• クライアントから明示的に停止の指示があった

正当な停止条件ではありません（いずれも実際の失敗につながったことがあります）。

• 「このターゲットにはもううんざりだ」
• 「最初の試行がうまくいかなかった」
• 「防御が機能している」――クラス X に対する防御が機能していても、クラス Y、Z については何もわかりません
• 「記録した」――ギャップを記録することは、テストを実行することではありません
• 「すでにクライアントに伝えた」
• 「リクエスト数が増えてきた」――承認済みのエンゲージメントで確認すべきリクエスト数の問題は、各リクエストに適切なタグが付けられ、監査されているかどうかだけです
• 「規律に関するルールで慎重に行動するよう言われている」――ルールが求めているのは正確さであり、口を閉ざすことではありません
• 「この技術スタック向けのスキルがまだない」――ベンダーが公開しているチェックマトリックスを手作業で適用し、v1.1 の不足は別途記録してください
• 「ユーザーはオプション X を選んだが、X に Y が含まれるか確信が持てない」――X がエンゲージメント全体を対象とするモードなら、ユーザーが別の指示をしていない限り Y もスコープ内です
• 「ツールがインストールされていない」――brew install、apt install、直接ダウンロードを使ってください。エンゲージメントで使うツールの大半は5分未満でインストールできます
• 「オペレーターの判断に委ねる」――オペレーターは作業の実行を承認しています。作業を実行することこそ、オペレーターが求めている委任です

---

関連スキルへの橋渡し

この考え方を身につけたら、手法ごとのスキルを組み合わせてください。

• m365-entra-attack — M365 の認証情報を狙った攻撃チェーン
• mid-engagement-ir-detection — クライアント SOC のパッチ適用を指摘に変換
• hunt-sqli — 手法を問わない SQL インジェクション
• hunt-rce — ベクターを問わない RCE
• bug-bounty — レッドチームとバグバウンティのスコープを区別するためのスキル（二重トラックで作業する場合）

このスキルは運用上の規律を扱い、これらのスキルは手法を扱います。

---

関連するスキルとチェーン

• recon-scope-triage — 「積極的なデフォルトで、稼働中のあらゆるサーフェスを調査する」という指示を安全に適用するには、どのサーフェスが実際に対象のものなのかを把握しておく必要があります。エンゲージメントの流れ：ASM／偵察データセットを受領 → recon-scope-triage で名前空間の衝突によるノイズとソフト404の誤検出を除外 → 所有が確認され、検証済みのアセットのみをテストキューに登録します。これを省くと、他社のアセットにエンゲージメントの時間を浪費し（罪のない第三者を攻撃するリスクもあります）。
• hunt-spa-api — 「JSバンドルを収集する」という実行方針を、完全なプレイブックとして具体化します。SPAのJS → バックエンドAPIマップ → 認証なしでのアクセス制御不備のテスト。実際のエンゲージメントでは、スキャナーではなくこのプレイブックが最上位のCriticalを発見しました。エンゲージメントの流れ：稼働中のSPA／console／app／api ホストを特定 → hunt-spa-api → 各ルートファミリーを、ゲートで保護された兄弟サービスを対照として認証なしでテストします。
• hunt-dispatch — 考え方が定まったら、/hunt コマンドをプラットフォーム固有のスキルに振り分ける前に、モード（レッドチームかWAPTか、ブラックボックスかグレーボックスか）を決める必要があります。エンゲージメントの流れ：レッドチームの考え方を適用 → エンゲージメントのモードを確認（プロジェクトのメモリに基づき、bug-bounty かレッドチームかペネトレーションテストか） → /hunt を実行 → hunt-dispatch が適切なクラスター（M365／SharePoint／VPN／vCenter／APK）を読み込みます。
• mid-engagement-ir-detection — レッドチームの考え方では「挙動の変化も発見事項」です。このスキルはそれを具体化します。エンゲージメントの流れ：レッドチームのエンゲージメントを開始 → セッション開始時にベースラインを確立 → テスト中にレスポンスのパターンが変化 → mid-engagement-ir-detection がSOCのパッチ適用状態を新たな発見事項として記録します（防御措置が観測されたことは、クライアントの能力を示す指標です）。「バグが修正された」として片付けないでください。
• redteam-report-template — レッドチームの成果物はバグバウンティのレポートではありません。読者も、トーンも、構成も異なります。エンゲージメントの流れ：エンゲージメントを通じて発見事項を収集 → セッション終了時に redteam-report-template を使い、クライアント向けDOCXとして（Subject／Observations／Description／Impact／Recommendation／PoC）をまとめます。H1／Bugcrowd／Intigritiのプラットフォーム向けである report-writing は使いません。
• triage-validation — レッドチームの考え方には「早まって取り下げない」ことも含まれます。認可されたエンゲージメントでの4件の取り下げは、検証の失敗ではなく、考え方の誤りによるものでした。エンゲージメントの流れ：すべての発見事項を triage-validation の7つの質問によるゲートに通します。ただし、レッドチーム向けの調整として、「チェーンがあれば悪用可能」なものも、発見事項であり、発見事項なしではありません。
• evidence-hygiene — レッドチームのエンゲージメントは数週間に及ぶことが多く、規律ある証拠の記録がなければ成果物の質が損なわれます。エンゲージメントの流れ：レッドチームの考え方を適用 → セッション終了時ではなく開始時に、evidence-hygiene による記録のスケジュール（スクリーンショット、リクエスト／レスポンスのダンプ、タイムスタンプ付きログ）を設定します。