redteam-report-template

使用する場面

クライアントに納品するレポートには、このスキルを使用してください。

• 署名済みの作業範囲記述書（SOW）に基づく外部レッドチームのエンゲージメント
• CISO／IT セキュリティチームに提出するペンテストレポート（トリアージ担当者向けではない）
• 技術系と非技術系の両方の関係者が確認する所見
• DOCX／PDF での出力が必要なレポート（Markdown／プラットフォームの UI だけではない）

以下には使用しないでください。

• バグバウンティプラットフォームへの提出（代わりに report-writing ／ bugcrowd-reporting を使用してください）
• 簡易的な概念実証メモ
• 社内チーム向けの報告書

---

各所見の6セクション形式

各所見で使用する標準的な構成は次のとおりです。

## Finding F##: <descriptive title>

**Severity:** Critical / High / Medium / Low / Informational
**Status:** Confirmed / Patched mid-engagement / Suspected (1 signal)
**CVSS 3.1:** <score> (<vector>)
**Affected Asset:** <URL / IP / app name>

### 1. Subject
<One-line statement of the issue. Plain English, no jargon.>

### 2. Observations
<Bulleted list of what was observed during testing. Concrete facts only — no interpretation yet.>
- <Observation 1>
- <Observation 2>
- ...

### 3. Description
<Technical explanation of the vulnerability. 2-4 paragraphs. Reader should understand WHY the observations indicate a vulnerability, what the underlying flaw is.>

### 4. Impact
<What an attacker could achieve. Concrete attacker outcomes, NOT generic CIA triad statements. Tie to the client's business — money, data, reputation, regulatory exposure.>

### 5. Recommendation
<Specific, actionable remediation. Vendor patch, configuration change, code-level fix. Avoid "implement security best practices" — say what specifically.>

### 6. Proof of Concept (PoC)
<Steps to reproduce, numbered. Include the exact HTTP requests, payloads, tools used.>

**Step 1:** <action>
```http
<full HTTP request or curl one-liner>

手順2：

<response excerpt>

スクリーンショット：

---

## Severity & status disciplines

### Severity table (client-facing — different from CVSS-only)

| Severity | Business definition | CVSS rough range |
|---|---|---|
| Critical | Direct revenue/data loss without prerequisites | 9.0-10.0 |
| High | Full account/system takeover with limited prerequisites | 7.0-8.9 |
| Medium | Significant data exposure or partial compromise | 4.0-6.9 |
| Low | Information disclosure with limited exploitation path | 0.1-3.9 |
| Informational | Hygiene finding, no immediate exploit | N/A |

### Status field (red-team-specific)

This is the field that distinguishes red-team deliverables from bug-bounty reports. Use one of:

- **Confirmed** — reproduced multiple times, with full PoC
- **Confirmed; patched mid-engagement** — was reproducible, client patched during the test window (still ship the finding — see `mid-engagement-ir-detection`)
- **Confirmed; partially reproducible** — works but needs specific conditions
- **Suspected (1 signal)** — single indicator, not confirmed (rare — usually drop)
- **Out-of-band** — finding from passive recon, not actively tested

---

## Mistakes to avoid (from authorized-engagement)

### 1. Don't retract findings that stopped reproducing
If a finding was confirmed and then stopped working, that is almost always a CLIENT PATCH, not a finding-was-false. The correct response is "Confirmed; patched mid-engagement" with timestamps showing when it broke. See `mid-engagement-ir-detection`.

### 2. Don't hedge in the Impact section
Bad: "An attacker could potentially be able to access user data, which may lead to..."
Good: "An attacker reads any user's profile data. Demonstrated on test user `[email protected]` at 14:22 IST."

### 3. Don't generic-CIA the impact
Bad: "Loss of confidentiality and integrity of customer data"
Good: "Read access to 247,000 customer records including PAN cards, addresses, GST numbers. India DPDPA Section 33 mandates 72-hour breach disclosure to DPB."

### 4. Don't list every recon finding as a finding
Recon notes (subdomains found, ports open, technologies fingerprinted) belong in a separate **Recon / Attack Surface** appendix, not the findings list. A finding must have an attacker-attainable outcome.

### 5. Don't bury the PoC
Each finding MUST have reproducible steps. The PoC section is what proves the finding to a skeptical reader. If you can't write the PoC clearly, the finding probably isn't ready to ship.

---

## Document-level structure

1. エグゼクティブサマリー（1ページ、非技術者向け）

   • エンゲージメントの概要（日程、範囲）
   • リスク態勢の概要（ヒートマップ：<重大度「Critical」X件、高「High」Y件、中「Medium」Z件...>）
   • 戦略上の主な推奨事項3点
   • 業界のベースラインとの比較（任意）

2. エンゲージメントの詳細

   • 範囲（対象範囲、対象外、除外事項）
   • 手法（偵察 → 悪用 → 報告、または PTES／OSSTMM に準拠）
   • 使用したツール
   • タイムライン（開始／終了／主なマイルストーン）
   • チーム

3. リスクサマリーテーブル

   F#	タイトル	重大度	ステータス
   F01	...	Critical	Confirmed
   ...

4. 所見（重大度の高い順に、各 ## セクションに1件ずつ記載。重大度「Critical」を最初にする）

5. 攻撃対象領域／偵察の付録

   • 発見したサブドメイン
   • 開放ポート／サービス
   • 技術フィンガープリント
   • 発見した APK
   • 漏えい情報のデータセットに含まれる認証情報（件数とサンプルのみ。マスキングする）
   • ID 基盤マップ（IdP、MFA の状況）

6. 侵害の痕跡（IoC）

   • テスト中に使用した送信元 IP（SOC が相関分析できるようにするため）
   • User-Agent 文字列
   • 作成したテストアカウント
   • アップロードしたファイル（削除状況を含む）

7. クリーンアップの説明

   • すべてのテスト用アーティファクト（アカウント、アップロード、永続化設定）を削除したことの確認
   • クライアント側の対応が必要な未完了のクリーンアップ項目

8. 付録（生の出力、スクリーンショット一覧、対象の完全なリスト）

---

## DOCX generation pipeline (markdown → docx with embedded images)

```bash
# Prerequisite: pandoc installed
brew install pandoc

# Convert
pandoc REPORT_FINAL.md \
  -o REPORT_FINAL.docx \
  --resource-path=engagement_log/poc \
  --reference-doc=~/.claude/skills/redteam-report-template/templates/reference.docx \
  --toc \
  --toc-depth=2 \
  --highlight-style=tango

# Verify image count
python3 -c "
from docx import Document
d = Document('REPORT_FINAL.docx')
imgs = [r for r in d.part.rels.values() if 'image' in r.target_ref]
print(f'Embedded images: {len(imgs)}')
print(f'Paragraphs: {len(d.paragraphs)}')
print(f'Headings: {sum(1 for p in d.paragraphs if p.style.name.startswith(\"Heading\"))}')
"

画像ファイル名の規則

screenshots/F<NN>_<descriptive>.png

Examples:
F01_locked_accounts.png
F02a_saml_landing.png
F02b_saml_ca_block_page.png
F03_sqli_timing_chart.png
F15_saml_metadata.png

バリエーションには文字の接尾辞（F02a、F02b）を付けます。所見番号には必ずゼロ埋めを行ってください。

---

文体 — クライアント納品物向け

セクション	文体
件名	平易な英語、専門用語を使わず、1行で記載
観察事項	箇条書きの事実、過去形（「...を確認した」）
説明	技術的でありながら分かりやすく記述。読者はCISOと想定
影響	ビジネス上の影響に置き換え、収益／規制に結び付ける
推奨事項	命令形で、具体的かつ実行可能に記述
PoC	オペレーター向けの技術的な内容。コピーして実行できる形式

必ず守ること：

• 観察事項には過去形を使用します（「エンドポイントはステータスコード200を返しました」）
• 脆弱性の説明には現在形を使用します（「アプリケーションは...を検証しません」）
• 推奨事項には命令形を使用します（「...までにパッチを適用してください」）
• 再現手順には番号を付けます。「まず...次に...さらに...」とは書きません

禁止事項：

• 「潜在的に可能性がある」— 実証するか、記述を削除します
• 「可能性があるかもしれない」— 同様です
• 「セキュリティのベストプラクティスを実装することを推奨します」— 具体的な対策を明記します
• 具体的な内容を示さずに「アプリケーションには脆弱性があります」と書くこと

---

読者に応じた表現 — 同じ所見でも伝え方を変える

例：APK にハードコードされた JWT

セクション	技術者向けの表現	CISO 向けの表現	取締役会向けの表現
影響	「APK から JWT 署名鍵を抽出すると、管理者トークンを偽造できます」	「顧客向けモバイルアプリを利用できる人なら、どの顧客の請求書でも閲覧できます」	「モバイルアプリから秘密情報が漏えいすると、攻撃者がユーザーになりすませます」

同じ所見の「影響」段落では、ビジネス上の結果から説明を始め、その後に技術的な詳細へと掘り下げます。

---

誤って除外されることがある発見事項

レッドチームの成果物には、バグバウンティで報奨金の対象となる脆弱性だけでなく、次の事項も含める必要があります。

• 攻撃対象のマッピングに役立つ情報漏えい（CodeIgniter のデバッグツールバーによるルートの漏えい、アプライアンスのバージョンバナーなど） — Medium
• ユーザー列挙（Microsoft OneDrive における 302 と 404 の応答差） — Medium
• 既存のセキュリティ状態に関する観察事項（外部攻撃者によってすでにロックされていた 247 個のアカウント、脆弱なパスワードポリシー） — ステークホルダーにとって重要な情報
• 防御に関する観察事項（SOC が SQLi を 30 分以内に修正 — 検知が機能している証拠） — 情報提供／肯定的な所見
• 関連アプリ間で共通するパターンの問題（7 つのアプリで同じコードテンプレートを使用） — Medium（影響範囲が拡大）

バグバウンティでは、これらの大半は却下されます。レッドチームの成果物では、クライアントは評価によってこれらを把握するために費用を支払っているため、積極的に取り上げます。

---

エンゲージメント中に記録すべきイベント

発見事項そのものに加えて、成果物には次の内容を含める必要があります。

• 検知した SOC の対応（防御が作動した時刻）
• 外部攻撃者による同時進行の活動（観察された場合）
• エンゲージメント中にクライアントが修正した発見事項（修正前の PoC を証拠として添付）
• ツールの不具合（MCP のタイムアウト、CAPTCHA を解決できなかった場合など） — これらはテスト可能だった内容と、できなかった内容に影響します

どの項目も、実環境での検知能力を理解するための背景情報をクライアントに提供します。多くの場合、その重要性は発見事項そのものを上回ります。

---

テンプレートライブラリ（定型文の保存場所）

再利用可能な定型文は、次の場所で管理します。

~/.claude/skills/redteam-report-template/templates/
    executive_summary.md      # Reusable exec summary skeleton
    methodology.md            # Standard methodology section
    cleanup_statement.md      # Standard cleanup language
    reference.docx            # Pandoc style template (fonts, headings, colors)
    cover.docx                # Cover page template

エンゲージメントごとに一から書かず、複製してカスタマイズしてください。

---

納品前の品質チェック

納品前チェックリスト：

• すべての発見事項に 6 つのセクションがすべて記入されている（「TBD」がない）
• すべての発見事項に、少なくとも 1 つのスクリーンショットまたは HTTP レベルの証拠がある
• すべての PoC でクライアントの PII がマスキングされている（メールアドレス、電話番号、ID など）
• すべてのスクリーンショットが、解決可能な相対パスを使って MD 内で参照されている
• DOCX のレンダリングを確認済み — 画像数が MD 内の参照数と一致している
• 重大度の順に並んでいる：Critical の発見事項が最初で、次に High など
• エグゼクティブサマリーが最終的な発見事項に合わせて更新されている（件数、テーマ）
• クリーンアップに関する記述に、作成したものと削除したものが明記されている
• IoC セクションにより、SOC が観察した内容を再構成できる
• スペルチェックを実施済み（特にクライアントの会社名、製品名）
• 手法のセクションにすべてのツールのバージョンが記載されている
• すべての発見事項でステータス欄が正しく設定されている（特にエンゲージメント中に修正されたもの）

---

隣接するスキルとの関連

• report-writing — バグバウンティプラットフォーム向けレポート（形式も対象読者も異なります）
• redteam-mindset — 提出に値する発見事項とは何かを判断する際の参考になります
• mid-engagement-ir-detection — 「エンゲージメント中に修正」のステータスパターンを理解する際の参考になります
• evidence-hygiene — スクリーンショットのマスキング規律を理解する際の参考になります
• m365-entra-attack、enterprise-vpn-attack など — それぞれの攻撃対象領域に特化した発見事項のテンプレートを提供します

---

アンチパターン

• 50 ページのレポートに発見事項が 3 件しかない、という構成にしないでください — ページ数を水増しすると信頼性が損なわれます
• すべてに同じ重大度を適用しないでください — 適切に調整してください
• OWASP Top 10 の定型文を Description セクションにコピー＆ペーストしないでください
• PoC のない発見事項を含めないでください — 推測に基づく内容に見えてしまいます
• Recommendation セクションを具体的に記述してください — 「修正して確認する」だけでは役に立ちません
• バグバウンティの CVSS スコアリングとレッドチームの重大度を考えずに混同しないでください — 背景が異なります（たとえば、CVSS では Medium でも、規制対象のデータセットに触れる場合、クライアントにとっては Critical となることがあります）

---

実際のエンゲージメント指標（authorized-engagement）

目安：

• 提出した指摘事項：14件（Critical 2件、High 4件、Medium 5件、Low／Info 3件）
• 埋め込んだスクリーンショット：18枚
• Markdown：52,737バイト／DOCX：2,262,484バイト
• DOCX：414段落、123個の見出し
• インライン画像：16枚（うち2枚はMDのみの特殊ケースでインラインに配置）
• 成果物の納品までの時間：エンゲージメント終了後、初稿まで約6時間

これらの数値は、中規模企業に対する1週間の外部レッドチームエンゲージメントで一般的なものです。短期テストでは規模を縮小し、フルのパープルチーム演習では拡大してください。

---

関連スキルと連携

• triage-validation — このテンプレートが取り込むのは、7つの質問からなるゲートをすでに通過した指摘事項です。エンゲージメントの流れ：すべての指摘事項をまず triage-validation に通す → 検証済みの指摘事項のみを redteam-report-template でパッケージ化します。トリアージを省くと、情報価値の低いノイズで水増しされた成果物になり、クライアントの信頼を損ないます。
• evidence-hygiene — 16枚のスクリーンショットを埋め込んだDOCXが機能するのは、エンゲージメント全体を通して証拠が体系的に収集されている場合に限ります。エンゲージメントの流れ：セッション開始時に evidence-hygiene の手順を徹底 → タイムスタンプ付きの整理されたスクリーンショットフォルダー → redteam-report-template がそのフォルダーを読み込み、Evidenceブロックに反映します。
• redteam-mindset — Subject／Observations／Description／Impact／Recommendation／PoCの構成は、担当者がすでにレッドチームの視点（影響を優先し、被害範囲を明確にする視点）で考えていることを前提としています。エンゲージメントの流れ：開始時に redteam-mindset を読み込む → レッドチームの視点を組み込んで指摘事項を収集 → redteam-report-template がImpactセクションを書き直すことなく成果物を作成します。
• mid-engagement-ir-detection — 防御側の対応に関する指摘事項（テスト中のSOCによるパッチ適用、新たなIPSルールの導入、外部攻撃者を原因とするアカウントロックアウト）は、レッドチームの成果物における正式な指摘事項です。エンゲージメントの流れ：mid-engagement-ir-detection で挙動の変化を記録 → 各事象を成果物の独立したSubjectとして、「見逃したバグ」ではなく「クライアントの能力に関する観察事項」として記述します。
• report-writing ＋ bugcrowd-reporting — バグバウンティプラットフォームへのレポートは、構成（提出ごとに指摘事項1件、プラットフォーム固有の深刻度評価、OOS条項のカウンター）が異なります。エンゲージメントの流れ：プロジェクトメモリ上のエンゲージメントモードが bug-bounty の場合は、代わりに report-writing／bugcrowd-reporting を使用してください。このテンプレートは、外部レッドチーム向け／企業クライアント向けの成果物にのみ使用します。