offensive-reporting

ペネトレーションテストレポート — プロフェッショナルな方法論

優れた発見事項も、レポートが悪ければ価値を失います。レポートは、クライアントが対価を払い、監査人が読み、開発者が修正の参考にする成果物です。エクスプロイトと同じ厳密さでレポートを作成してください。

クイックワークフロー

1. エクスプロイトを実行しながら証拠を記録します。事後に再構成してはいけません
2. 状況が新鮮なうちに各発見事項の草案を作成します。発見事項ごとに番号付きのファイルを1つ作成します
3. すべての発見事項を評価した後、最後にエグゼクティブサマリーを作成します
4. 2段階でレビューします。まず技術的な正確さを確認し、次に CISO の視点でストーリーを読み直します
5. 再テスト計画と、クライアントの追跡システム用の JSON/CSV インデックスを添えて引き渡します

---

レポートの構成（標準）

1. Executive Summary             ← Last to write, first read
2. Engagement Overview
   2.1 Scope
   2.2 Methodology
   2.3 Limitations / Assumptions
   2.4 Timeline
   2.5 Team
3. Risk Summary                  ← Heatmap, finding count by severity
4. Technical Findings            ← One per finding, sorted by severity
5. Attack Narratives / Chains    ← Critical chains called out separately
6. Strategic Recommendations     ← Programmatic, not finding-by-finding
7. Appendices
   A. Tools Used
   B. Indicators of Compromise (for blue team)
   C. Raw Evidence Pointers
   D. Glossary

---

エグゼクティブサマリー — 90秒で読める要約

エグゼクティブサマリーの読者は、CISO、GRC 担当者、取締役です。この部分だけを読み、それ以外は読みません。

構成（最大1ページ）：

1. エンゲージメントの概要 — 何を、いつ、誰がテストしたか（1文）
2. 最も重大な発見事項 — 発見した最悪の問題を、ビジネス上の言葉で説明します（2～3文）
3. リスク評価 — 全体的なセキュリティ状況を平易な言葉で説明します（1段落）
4. 件数 — 重大度別の発見事項の件数を、小さな表にまとめます
5. 戦略的な推奨事項トップ3 — 「CVE-X にパッチを適用する」のような個別対処ではなく、プログラム全体に関わる改善策

エグゼクティブサマリーで避ける言葉： payload、RCE、XSS、LDAP、SMB、kerberos、injection。すべて言い換えてください。（「シリアライズ解除ガジェットチェーン経由の RCE」ではなく、「攻撃者がサーバー上で任意のコマンドを実行できる可能性があります」とします。）

含める言葉： ビジネスへの影響（顧客データ、規制上のリスク、業務の中断、金銭的損失）。すべての発見事項をビジネス上の結果に結び付けてください。

---

技術的な発見事項のテンプレート

## Finding ID — Short Descriptive Title

**Severity:** Critical (CVSS 9.8 — vector below)
**Affected Scope:** <hosts/URLs/components, with version where relevant>
**Status:** Open / Fixed in retest / Accepted Risk
**CWE:** CWE-89 (SQL Injection)
**OWASP:** A03:2021 — Injection

### Summary
One paragraph. What is the finding, why does it matter, what's the worst case.

### Background
What technology is involved and why this class of bug exists. Two paragraphs max.
Skip if obvious (e.g. don't explain XSS to an XSS shop).

### Description
Detailed walkthrough of the issue. The root cause, not just the symptom.

### Reproduction Steps
1. Numbered, copy-paste ready.
2. Include the exact request/response, redacted.
3. A reader with no engagement context should reproduce in <15 minutes.

### Evidence
- `screenshots/finding-007/01-payload.png`
- `requests/finding-007/initial-poc.http`
- `evidence-log.csv` line 142 (timestamp 2025-04-12 14:33:07Z)

### Impact
Concrete. Quantified where possible.
- "Read access to the entire customer table (~2.3M records)"
- "Authenticate as any user; verified for sample ID 1, 2, 999, 1000000"
- "Cross-tenant access — verified by reading data from acquired-tenant ABC"

### Remediation
Specific, actionable, ordered by precedence:
1. **Fix the bug** — exact code change or config flag
2. **Defense in depth** — secondary control (WAF rule, input validation)
3. **Detection** — log line / SIEM rule that would have caught the exploit

### References
- CWE / OWASP / CAPEC
- Vendor advisory if known CVE
- Blog posts only if directly relevant

### Notes for Retest
What you'd do to verify the fix. Specific request, specific expected response.

---

重大度の評価

CVSS v3.1 の適用方針

CVSS は判断のためのツールであり、最終判断そのものではありません。スコアを付けた後、ビジネスへの影響と照らし合わせて妥当性を確認してください。

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 Critical

すべての指標について、選択理由を1文で説明してください。

• AV:N — インターネットに公開されている（ポート443）
• AC:L — 特別な前提条件がない
• PR:N — 認証が不要
• UI:N — ユーザー操作が不要
• S:U — セキュリティスコープを越えない
• C:H I:H A:H — データベースに対する完全な読み取り／書き込み／可用性への影響

合理的なスコアが人によって異なる可能性がある場合は、選択した理由を記録してください。

CVSS が実態を反映しない場合

CVSS はビジネス上の状況を反映しません。顧客サポート用チャットパネルにおける「中」程度の CVSS の XSS は、PII を扱う認証済みエージェントが使用するものであれば、メタデータを持たない内部サービスに対する未認証の「高」重大度の SSRF より危険です。CVSS は最低基準として使い、上限とは見なさないでください。

このような場合は、CVSS を正直に評価したうえで、**「ビジネス影響の調整」**の段落を追加し、レポート上の重大度を引き上げる根拠を説明してください。CVSS を偽ってはいけません。

CVSS v4.0（必要な場合）

CVSS v4.0 では、現実世界のリスクをより適切に捉える環境指標と脅威指標が追加されています。クライアントから必須とされている場合（PCI DSS 4.0 ではこの方式が広がっています）に使用してください。それ以外の場合は、引き続き v3.1 が共通語です。

OWASP リスク評価（代替手法）

CVSS の適用が無理に感じられる Web アプリケーションのみのエンゲージメントでは、OWASP のリスク評価（複数の要因に基づく可能性 × 影響）の方が伝わりやすい場合があります。

---

証拠の記録

記録する内容

各発見事項について、すべての操作を記録します。

1. タイムスタンプ（UTC、ISO 8601）
2. 送信元 IP アドレス（ピボットを含む、自分のもの）
3. ターゲット（ホスト、URL、RPC インターフェース）
4. 操作（送信したリクエスト）
5. 結果（応答と取得した内容）
6. 抽出したデータのハッシュ（確認した内容を証明できるようにします）

timestamp,operator,src_ip,target,action,result_hash,notes
2025-04-12T14:33:07Z,KA,10.10.10.5,app.client.com,SQLi probe ' OR 1=1--,sha256:abc...,initial detection

これは監査証跡です。セキュリティ体制が成熟したクライアントからは提出を求められます。

編集ルール

成果物をセキュアな環境から持ち出す前に、必ず次の処理を行ってください。

• 認証情報を <REDACTED-PASSWORD>、<TOKEN-A1> などのプレースホルダーに置き換えます
• 抽出した個人を特定できる情報（PII）をハッシュ化します。スクリーンショットに実在する氏名、メールアドレス、SSN を含めないでください
• スクリーンショットを該当箇所に合わせてトリミングします。ブラウザーのタブに情報が漏れていないか確認してください（ほかのタブが表示されていないか）
• 画像の EXIF 情報を削除します。exiftool -all= *.png で自動的に情報を伏せます
• クライアントのインフラストラクチャのパスが明らかになるデバッグ用ツールバーをスクリーンショットから削除します
• スクリーンショット内の URL にセッショントークンが含まれていないことを確認します

ストレージと証拠保全の連鎖

• エンゲージメント期間中は暗号化されたボリュームを使用します（LUKS、FileVault、BitLocker）
• エンゲージメントごとに専用の鍵を使用します。オペレーター共通のマスターキーは使用しません
• エンゲージメント終了時にクライアントの仕様に従って消去します（通常、納品後 30～90 日）
• 保管するのはレポートと証拠のハッシュマニフェストのみとし、依頼があれば削除できるようにします

---

対象範囲、制限事項、前提条件

この 3 つのセクションは、あなたとクライアントの双方を守ります。明確に記載してください。

対象範囲

• 対象となる IP、ドメイン、リポジトリ、アカウントと、エンゲージメント期間の開始日および終了日
• 対象外：クライアントが利用するサードパーティの SaaS（クライアントが所有していないため）
• 要望により対象外とする項目：物理的な侵入、スタッフに対するソーシャルエンジニアリング、DoS

制限事項

• 「テストはインターネット経由のみで実施しました。内部ネットワークへのアクセスは提供されていません」
• 「ソースコードレビューは対象外でした」
• 「ROE に従い、本番データベースの変更は避けました」
• 「調整されたダウンタイムはありません。テスト時間帯は UTC 22:00～06:00 でした」

前提条件

• 「ステージング環境は本番環境を再現しているものと仮定しました」
• 「app.client.com の前段にある WAF は本番環境と同じものと仮定しました」
• 「管理者権限を持つサービスアカウントは既存のものと仮定しました」

---

リスク概要とヒートマップ

説明するだけでなく、見て分かるようにします。すべての役員が 5 秒で読み取れる視覚的な概要を用意してください。

Severity   Count   Top Example
Critical     3     RCE via deserialization (Finding #2)
High         7     ADCS ESC1 → Domain Admin (Finding #11)
Medium      14     Stored XSS in customer support panel (Finding #4)
Low         22     TLS 1.0 still enabled on api.client.com (Finding #29)
Info        11     —

シンプルな棒グラフや信号機式のグリッドを使えば、一目で分かる概要になります。2 ページ目（エグゼクティブサマリーの後）に配置してください。

---

攻撃チェーン／シナリオ

重大な所見は、単独では重要でないことがほとんどです。チェーンこそがストーリーです。

1. Phishing email → user runs HTA payload (Finding #1, Medium)
2. Local UAC bypass via Token Manipulation (Finding #5, Low)
3. Kerberoast service account (Finding #11, High)
4. Crack TGS offline → service account password (Finding #11)
5. ACL abuse: service account has WriteDacl on Domain Users (Finding #14, High)
6. Grant DCSync, dump krbtgt → Golden Ticket → Domain Admin (Finding #15, Critical)

Total time: 4 hours. Detection points missed: 3 (see Appendix B).

各チェーンは個別に強調してください。組み合わせることで、個々の所見よりも高い重大度に相当することがよくあるためです。

---

戦略的な推奨事項

所見ごとの修正策に加え、3～5 件のプログラムレベルの推奨事項を記載してください。

• 「Java サービスの CI に SAST を導入する」（12 件の所見に対応）
• 「AD に tier-0 管理者モデルを導入する」（AD 攻撃チェーン全体に対応）
• 「シークレットを HashiCorp Vault に一元化し、ハードコードされた認証情報をローテーションする」（9 件の所見に対応）

CISO が取締役会に提示する内容です。印象に残るものにしてください。

---

納品形式

形式	用途
PDF	役員向けの閲覧、正式な記録、契約上の納品物
DOCX	クライアントが情報を伏せたり、内容を追加したりする場合
HTML	内部ポータルへのアップロード、grep による検索
JSON	SIEM／GRC ツールへの取り込み（DefectDojo、Faraday、ServiceNow）
CSV	Jira／Asana への迅速な取り込みと追跡
Markdown source	上記すべてを生成する唯一の信頼できる情報源

すべての形式を、1 つの Markdown ソースから Pandoc／静的サイトジェネレーターを使って生成してください。複数の形式を手作業で並行して管理しないでください。

# Markdown → polished PDF via Pandoc + LaTeX template
pandoc report.md -o report.pdf \
  --template=client-template.tex \
  --pdf-engine=xelatex \
  --metadata=title:"Penetration Test Report — Client Co." \
  --toc --number-sections

---

よくあるレポートの誤り

誤り	修正方法
すべての指摘に CVSS 9.0 を付ける（「CVSS の過大評価」）	正直にスコアを付けます。すべてが重大だと、クライアントの信頼を失います
宣伝文句のような表現（「革命的な攻撃」など）	簡潔でプロフェッショナルなトーンにします
ツールの出力をそのまま証拠として掲載する	関連する 5 行を選んで提示します
一般的すぎる修正案（「入力を検証する」など）	具体的なコードや設定の変更を示します
再現手順がない	再現できなければ、修正もできません
時刻のない証拠	すべての操作に UTC タイムスタンプを付けます
同一の指摘が区別できない	クラスごとにまとめ、影響を受ける項目を表に記載します
再テスト計画がない	各指摘に、修正を確認する方法を記載します
スコープと制限事項を分けていない	スコープ＝テストした内容、制限事項＝テストを妨げた要因です
情報提供レベルの指摘を埋め草として扱う	削除するか、丁寧に記述します

---

バグバウンティ向けのレポート（対象読者が異なります）

バグバウンティのトリアージ担当者は時間に追われており、懐疑的です。次のように調整してください。

• タイトル：80 文字以内で、バグのクラス、エンドポイント、影響を含めます
• 再現方法：可能であれば、単一の curl コマンドと、期待されるレスポンスと実際のレスポンスを示します
• 影響：プログラムの脅威モデルに沿って説明します（PII を読み取れるか、認証を回避できるか、別アカウントに影響するか）
• 避けること：長文、リクエストログのないスクリーンショット、再現手順のない主張

優れたバグバウンティレポートは 2 分で読めて、5 分で再現できます。質の低いレポートは「詳細情報をください」と差し戻されます。

---

再テストとクローズアウト

### Retest Summary

| Finding | Original Severity | Retest Status | Verification Date |
|---------|-------------------|---------------|-------------------|
| #1 | Critical | ✓ Fixed (verified) | 2025-05-10 |
| #2 | High | ✓ Fixed | 2025-05-10 |
| #5 | Medium | ⚠ Partially fixed — see notes | 2025-05-10 |
| #11 | High | ✗ Not fixed — finding stands | 2025-05-10 |
| #14 | Low | • Accepted Risk (client decision) | 2025-05-10 |

各指摘には、修正を示す正確な検証リクエストとレスポンスを記載してください。証拠がなければ、「修正済み」というのは伝聞にすぎません。

---

CVSS ベクターのサンプル（参考）

クラス	典型的なベクター	スコア
未認証 RCE	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H	9.8
認証済み RCE	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H	8.8
格納型 XSS	AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N	5.4
IDOR（PII の読み取り）	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N	6.5
SSRF（クラウドメタデータ）	AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N	9.0
オープンリダイレクト	AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N	4.3

これらを出発点として、環境に応じて調整してください。

---

ツール

ツール	用途
Pandoc + LaTeX	Markdown → 体裁の整った PDF
Sphinx / mkdocs	Markdown → HTML ポータル
DefectDojo	指摘の追跡、JSON エクスポート
Faraday	複数のエンゲージメントの集約
Dradis	レポートの共同作成
serpico（旧式ですが、現在も使われています）	ペネトレーションテストレポートのテンプレート
Plextrac	商用レポートプラットフォーム

---

主な参考資料

• NIST SP 800-115（技術的なセキュリティテストのレポート作成）
• PTES — Penetration Testing Execution Standard、レポート作成のセクション
• OWASP Testing Guide — レポート作成の章
• FIRST CVSS v3.1 / v4.0 仕様
• CREST Cyber Security Incident Response and Penetration Testing のレポート作成基準
• 出典：https://github.com/SnailSploit/offensive-checklist/blob/main/reporting.md