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 のデバッグツールバーによるルートの漏えい、アプライアンスのバージョン表示など）— 中
• ユーザー列挙（Microsoft OneDrive の 302 と 404 の応答差異）— 中
• 以前から存在するセキュリティ状態の観察結果（外部の攻撃者によってすでにロックされていた 247 個のアカウント、脆弱なパスワードポリシーなど）— ステークホルダーに関連する情報
• 防御に関する観察結果（当社の SQLi を SOC が 30 分以内に修正 — 検知機能が機能している証拠）— 情報提供／肯定的
• 姉妹アプリに共通するパターンの問題（7 つのアプリで同じコードテンプレートを使用）— 中（影響範囲が拡大）

バグバウンティでは、これらのほとんどが却下されるでしょう。レッドチームの成果物では、クライアントが評価を依頼した目的が情報を得ることなので、こうした内容も扱います。

---

エンゲージメント中に記録すべき出来事

所見そのものに加えて、成果物には次の内容を含めてください。

• 検知された 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」がない）
• すべての所見に、スクリーンショットまたは HTTP レベルの証拠が少なくとも 1 つある
• すべての PoC でクライアントの個人識別情報がマスキングされている（メールアドレス、電話番号、ID など）
• すべてのスクリーンショットが、解決可能な相対パスで MD 内から参照されている
• DOCX のレンダリングを確認し、画像数が MD の参照数と一致している
• 重大度の順序：最初にクリティカルな所見、次に高など
• エグゼクティブサマリーが最終的な所見（件数、テーマ）に合わせて更新されている
• クリーンアップに関する記述に、作成したものと削除したものが明記されている
• IoC セクションにより、SOC が観測した内容を再構成できる
• スペルチェックを実施している（特にクライアントの会社名、製品名）
• すべてのコマンドラインのバージョンが方法論に記載されている
• すべての所見でステータス欄が正しく設定されている（特にエンゲージメント中に修正されたもの）

---

関連スキルとの連携

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

---

アンチパターン

• 50 ページのレポートに所見が 3 件しかないものを書かないでください — ページ数を水増しすると信頼性が損なわれます
• すべてに同じ重大度を割り当てないでください — 適切に調整してください
• OWASP トップ 10 の定型文を Description セクションにコピー＆ペーストしないでください
• PoC のない所見を含めないでください — 推測に基づくものに見えます
• Recommendation セクションで具体性を省かないでください — 「パッチを適用して確認する」だけでは役に立ちません
• バグバウンティの CVSS スコアリングとレッドチームの重大度を考えずに混同しないでください — 文脈が異なります（例：CVSS に基づけば中程度の所見でも、規制対象のデータセットに関わる場合、クライアントにとってはクリティカルになり得ます）

---

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

目安：

• 14件の指摘事項を納品（重大 2件、高 4件、中 5件、低／情報 3件）
• スクリーンショットを18枚埋め込み
• Markdown 52,737バイト／DOCX 2,262,484バイト
• DOCX 内の段落 414件、見出し 123件
• インライン画像 16点（うち2点はMDのみの特殊ケースでインラインに配置）
• 納品までの時間：エンゲージメント終了から初稿まで約6時間

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

---

検証

1. CVSS 計算ツール — CVSS 3.1 の認識を確認します：

   grep -q "CVSS\|cvss\|3.1" SKILL.md && echo "PASS: CVSS scoring documented" || echo "FAIL"
   

2. テンプレート構造 — レポートの各セクションが文書化されていることを確認します：

   grep -q "Executive Summary\|Findings\|Remediation" SKILL.md && echo "PASS: report structure present" || echo "FAIL"
   

すべてのテストで、レポートテンプレートの準備状況を検証します。

---

注意点

• 技術的すぎる表現 — 経営陣はエグゼクティブサマリーを読みます。最初の段落では影響を重視してください：「攻撃者はすべての顧客の個人情報を窃取できます……」
• CVSS スコアの欠落 — CVSS スコアのないレッドチームレポートは、コンプライアンスチームに却下されます。必ず CVSS 3.1 とベクトル文字列を含めてください。
• 修正期限がない — 「X日以内に修正」と記載されていない指摘事項は無視されます。重大度を SLA に対応付けてください：重大＝48時間、高＝7日、中＝30日、低＝90日。
• 脆弱性の発生箇所ごとに指摘を分ける — 同じ脆弱性クラスが異なるホストで複数確認された場合は、範囲を明記したうえで1件の指摘にまとめてください。
• 非公開版を利用できないスクリーンショットのマスキング — マスキングしていないバージョンを非公開で提供してください。トリアージ担当者は検証にそれを必要とします。
• CVE との相互参照がない — 指摘事項が CVE に該当する場合は、引用してください。信頼性が高まり、クライアントがリスクを理解しやすくなります。

---

関連スキルと連携

• triage-validation — このテンプレートには、7つの質問によるゲートをすでに通過した指摘事項を取り込みます。エンゲージメントの流れ：すべての指摘事項をまず triage-validation に通す → 検証済みの指摘事項のみを使用 → redteam-report-template でパッケージ化します。トリアージを省くと、情報ノイズで水増しされた納品物になり、クライアントの信頼を損ないます。
• evidence-hygiene — スクリーンショットを16枚埋め込んだ DOCX が機能するのは、エンゲージメント全体を通じて証拠が体系的に記録されている場合のみです。エンゲージメントの流れ：セッション開始時に evidence-hygiene の規律を徹底 → タイムスタンプ付きの整理されたスクリーンショットフォルダーを作成 → redteam-report-template がそのフォルダーを取り込み、証拠ブロックに反映します。
• 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 を使用してください。このテンプレートは、外部レッドチーム／企業クライアント向けの納品物専用です。