redteam-mindset

このスキルを使うタイミング

次の場合に実行します：

• エンゲージメントの範囲に「red team」、「adversary emulation」、「assume breach」、「TIBER-style」と記載されている
• 再現性の確認に一度失敗しただけで、所見を撤回しようとしている
• さらに調査する代わりに、防御策を「想定どおりに機能している」と判断しようとしている
• ブロッカー（CAPTCHA、レート制限、WAF、CAブロック、ロックアウト）に遭遇し、停止を検討している
• アクセスを得られるバグではなく、IDOR／CSRF／XSSに時間を費やそうとしている
• アプリ A で脆弱性を見つけたが、未調査の関連アプリ B、C、D がある

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

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

---

一行でまとめると

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

ブロッカーに直面した際の判断は、この違いによってすべて変わります。開始前に、この違いをしっかり理解してください。

---

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

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

エンゲージメント開始時に与えられた承認は、エンゲージメント全体に適用されます。

エンゲージメントの途中で、許可の確認を挟まないでください。ユーザーが開始時にモード（「full engagement」、「Option D」、「go deep」、「test these assets」）を選択した場合、その承認はエンゲージメント期間が終了するか、ユーザーが明示的に取り消すまで有効です。ユーザーがすでに進め方を選んだ後、ループの途中で AskUserQuestion を実行するのは、確認ではなく遅延です。

規律に関するルールは、作業を制限するためではなく、所見の正確性を確保するためのものです。

2回読んでください。このバンドルの規律に関するルール — OOB-Or-It-Didn't-Happen、Marker Discipline、Body-Diff、Pre-Severity Gate、Server-Policy-vs-State、Statistical Sampling — は、すべて一つの問いに答えるものです。「このシグナルは本当に所見なのか？」 「次のプローブを送るべきか？」という問いに答えるものではありません。 スコープが尽きた場合、またはユーザーが停止を指示した場合を除き、後者への答えは常に 「はい」 です。

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

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

Marker Discipline ≠「サーフェスごとにプローブを1回」

Marker Discipline で定めるのは、使用するペイロードの種類（合成可能、識別可能、回収可能）であり、ペイロードの数ではありません。強化されたターゲットでは、脆弱なターゲットよりも Marker Discipline に従ったプローブを多く実行する必要があり、少なくてよいわけではありません。バンドルの hunt-sqli Pattern Library に SQLi クラスが12種類記載されている場合、パラメーターごとに Marker Discipline に従ったプローブを12回実行します。1回ではありません。

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

以下はすべて、このスキルが存在し、読み込まれていたにもかかわらず、担当者が自らテストを抑制してしまった実際の案件（許可済みエンゲージメントの再検証、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だから、テストするものは何もない」（通常、ベンダーは一元的にパッチを適用します。しかし、テナント設定の不備は一元管理されません）
• 「もう十分テストした」（エンゲージメント中のチェックリストを使い、どれか一つでも答えが「いいえ」なら、続行してください）
• 「データ流出には時間がかかりすぎる」（無人で実行し、部分的な結果を納品してください）

---

停止すべきとき（正当な停止条件）

次の場合に限り、停止してください。

• スコープ内のすべてのアセットについて、主要な脆弱性クラスを対象に、発見しただけでなく実際にプローブしている — このスキルの冒頭にある「実際のエンゲージメントの進め方」チェックリストを参照してください
• 確認されたすべての脆弱性が、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 — 二軌道で作業する際に、レッドチームとバグバウンティのスコープを区別する

このスキルが運用上の規律を扱い、上記のスキルが手法を扱います。

---

検証

1. 考え方の原則 — 主要な指示が文書化されていることを確認してください。

   grep -q "DO NOT STOP\|primary directive\|coverage over efficiency" SKILL.md && echo "PASS" || echo "FAIL"
   

2. 回避の考え方 — 403回避に関する考え方を確認してください。

   grep -q "403\|bypass\|try harder" SKILL.md && echo "PASS" || echo "FAIL"
   

すべてのテストで、レッドチームの考え方に関する文書を検証します。

---

落とし穴

• スキャナーだけに頼る考え方 — 自動スキャナーで見つかるのは、誰もが見つけるのと同じバグです。手動での分析と創造的な思考によって、独自のバグが見つかります。
• 確証バイアス — 仮説を否定する証拠ではなく、仮説を裏付ける証拠ばかりを探してしまうことです。仮説に反する証拠を積極的に探してください。
• 不十分な調査 — サブドメインの列挙だけで終わり、それぞれのアセットが何をしているのか理解しないことです。特に興味深いアセットを深く調査してください。
• 403で諦めること — 403は「脆弱ではない」という意味ではありません。「もっと工夫して試す」という意味です。ヘッダーのバイパス、メソッドの切り替え、パスの操作を試してください。
• モバイル／APIの攻撃対象領域を無視すること — Webアプリが強化されていても、モバイルAPIのパッチ適用が遅れている可能性があります。モバイルAPIのエンドポイントは必ずテストしてください。
• 失敗を記録しないこと — 否定的な結果も情報です。「/adminでX、Y、Zをテストし、すべて403が返った」と記録すれば、同じ作業を繰り返さずに済みます。
• 「DO NOT STOP」指示 — レッドチームのエンゲージメントで最優先されるのは効率ではなく、網羅性です。最初の調査で何も見つからなくても、掘り下げ続けてください。

---

関連スキルと連携フロー

• hunt-dispatch — 考え方が読み込まれた後、/huntコマンドはプラットフォーム固有のスキルに振り分けられる前に、モード（redteamとwapt、blackboxとgreybox）の回答を必要とします。エンゲージメントの流れ：レッドチームの考え方が起動 → エンゲージメントモードを確認（プロジェクトのメモリに基づき、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を使って（Subject／Observations／Description／Impact／Recommendation／PoC）クライアント向けのDOCXにまとめます。H1／Bugcrowd／Intigriti向けのreport-writingは使いません。
• triage-validation — レッドチームの考え方には「早まって取り下げない」ことも含まれます。承認されたエンゲージメントでの4件の取り下げは、検証の失敗ではなく、考え方の失敗でした。エンゲージメントの流れ：すべての発見事項をtriage-validationの7つの質問によるゲートに通します。ただし、レッドチームでは「チェーンがなければ悪用できない」場合も発見事項であり、発見なしではありません。
• evidence-hygiene — レッドチームのエンゲージメントは数週間に及ぶことが多く、規律ある証拠の収集がなければ成果物の質が低下します。エンゲージメントの流れ：レッドチームの考え方が起動 → セッション終了時ではなく開始時に、evidence-hygieneによる収集のペース（スクリーンショット、リクエスト／レスポンスのダンプ、タイムスタンプ付きログ）を整えます。