redteam-report-template

适用场景

此技能适用于交付给客户的报告：

• 签署了工作说明书（SOW）的外部红队测试
• 交付给 CISO / IT 安全团队的渗透测试报告（而非交给漏洞分诊人员）
• 技术和非技术利益相关方都会审阅的发现
• 需要输出 DOCX/PDF 的报告（而非仅使用 Markdown / 平台界面）

请勿用于：

• 漏洞赏金平台提交（请改用 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 页，非技术性）

   • 测试概述（日期、范围）
   • 风险态势摘要（热力图：<X 项严重、Y 项高危、Z 项中危……>）
   • 3 项首要战略建议
   • 与行业基线对比（可选）

2. 测试详情

   • 范围（范围内、范围外、排除项）
   • 方法论（侦察 → 利用 → 报告；或遵循 PTES / OSSTMM）
   • 使用的工具
   • 时间线（开始 / 结束 / 关键里程碑）
   • 团队

3. 风险摘要表

   F#	标题	严重性	状态
   F01	...	严重	已确认
   ...

4. 发现（每项发现单独使用一个 ## 小节，按严重程度排序——严重项优先）

5. 攻击面 / 侦察附录

   • 发现的子域名
   • 开放端口 / 服务
   • 技术指纹
   • 发现的 APK
   • 泄露数据集中的凭据（仅提供数量和样例——须脱敏）
   • 身份架构图（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 个账户已被外部攻击者锁定；密码策略薄弱）— 信息性，但与利益相关方有关
• 防御方面的观察（SOC 在 30 分钟内修补了我们的 SQLi — 这是检测机制有效运行的证据）— 信息性／正面
• 关联应用的模式问题（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 级证据
• 每个 PoC 都对客户的个人身份信息进行了脱敏（屏蔽电子邮件、电话号码、ID）
• MD 中引用的每张截图都使用了可解析的相对路径
• DOCX 渲染检查 — 图片数量与 MD 引用数量一致
• 严重性排序：先列出严重发现，然后是高危发现，依此类推
• 执行摘要已更新，与最终发现保持一致（数量、主题）
• 清理说明明确写明创建了什么以及移除了什么
• IoC 部分能帮助 SOC 还原其观察到的情况
• 拼写检查（尤其是客户公司名和产品名）
• 方法论中注明了所有工具的版本
• 每项发现的状态字段均设置正确（尤其是交战期间已修补的发现）

---

与相邻技能的衔接

• report-writing — 漏洞赏金平台报告（格式不同，受众也不同）
• redteam-mindset — 用于判断哪些内容值得作为发现提交
• mid-engagement-ir-detection — 用于“交战期间已修补”状态模式
• evidence-hygiene — 用于指导截图脱敏规范
• m365-entra-attack、enterprise-vpn-attack 等 — 各自提供针对特定攻击面的发现模板

---

反模式

• 不要为 3 项发现写一份 50 页的报告 — 用页数凑篇幅会损害可信度
• 不要对所有内容都使用相同的严重性 — 应进行校准
• 不要将 OWASP 十大风险的套话复制粘贴到“描述”部分
• 不要提交没有 PoC 的发现 — 这会让内容显得像推测
• 不要忽略“建议”部分的具体性 — “修补并审查”没有帮助
• 不要不加思考地混用漏洞赏金 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 周的外部红队测试而言较为典型。短期测试应相应缩减，完整的紫队演练则应相应增加。

---

相关技能与流程链

• 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 — 漏洞赏金平台报告使用不同的结构（每次提交一项发现、平台专属严重性评分、OOS 条款计数）。参与流程：如果根据项目记忆，参与模式为 bug-bounty → 改用 report-writing / bugcrowd-reporting。此模板仅适用于外部红队 / 企业客户交付内容。