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 个部分（没有“待定”）
• 每项发现至少有一张截图或 HTTP 层面的证据
• 每个 PoC 都对客户的 PII 做了脱敏（隐藏电子邮件地址、电话号码、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 Top 10 的固定文本复制粘贴到“描述”部分
• 不要纳入没有 PoC 的发现——这会显得像是推测
• 不要忽略“建议”部分的具体性——“修补并检查”没有帮助
• 不要不加思考地混用漏洞赏金 CVSS 评分和红队严重程度——两者背景不同（例如，按 CVSS 评为中危的漏洞，如果涉及受监管的数据集，对客户而言可能是严重级别）

---

实战评估指标（authorized-engagement）

供校准参考：

• 提交 14 个发现（2 个严重、4 个高危、5 个中危、3 个低危/信息类）
• 嵌入 18 张截图
• 52,737 字节的 Markdown / 2,262,484 字节的 DOCX
• 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"
   

所有测试均用于验证报告模板是否已准备就绪。

---

注意事项

• 语言过于技术化 — 高管会阅读执行摘要。首段应聚焦影响，例如：“攻击者可以窃取所有客户个人身份信息（PII）……”
• 缺少 CVSS 评分 — 缺少 CVSS 评分的红队报告会被合规团队驳回。务必包含带有向量字符串的 CVSS 3.1 评分。
• 没有修复时间表 — 未注明“在 X 天内修复”的发现会被忽略。按严重程度映射 SLA：严重=48 小时、高危=7 天、中危=30 天、低危=90 天。
• 每个漏洞实例单独列为一个发现 — 不同主机上出现的同一漏洞类别的多个实例应合并为一个发现，并注明范围。
• 截图已编辑遮盖，但没有提供未遮盖版本 — 应私下提供未遮盖版本。分诊人员需要该版本进行验证。
• 没有 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 — 漏洞赏金平台报告采用不同结构（每次提交一个发现、使用平台专属的严重程度评分、统计 OOS 条款）。评估流程：如果根据项目记忆，评估模式为 bug-bounty → 改用 report-writing / bugcrowd-reporting。此模板仅适用于外部红队评估 / 企业客户交付内容。