mcpField
O
offensive-reporting

offensive-reporting

github.com/snailsploit安全9.7k204 次安装2 周前更新
代码仓库

关于 offensive-reporting

面向安全顾问和团队的渗透测试报告方法，适用于准备客户交付物。内容涵盖报告结构、证据处理、严重性评估、建议、交付格式和复测。

主要功能

  1. 01组织执行摘要与技术章节
  2. 02使用 CVSS 或 OWASP 评估风险
  3. 03采集并脱敏证据
  4. 04说明攻击链与业务影响
  5. 05准备交付格式和复测计划

适用场景

  1. 01撰写客户渗透测试报告
  2. 02准备精简的漏洞赏金提交
  3. 03跟踪待修复发现
  4. 04复测并验证修复

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/snailsploit/claude-red --skill offensive-reporting

安装后在 Claude Code 中输入/offensive-reporting确认已加载。

详细介绍

渗透测试报告——专业方法论

优秀的发现若淹没在糟糕的报告里，就毫无价值。报告是客户付费获取的交付物，是审计人员阅读的材料，也是开发人员据此修复问题的依据。对待报告要像对待漏洞利用一样严谨。

快速工作流

  1. 利用漏洞时就采集证据——事后绝不重建
  2. 趁上下文还清晰，立即起草每项发现；一项发现对应一个编号文件
  3. 所有发现完成评分后，最后编写执行摘要
  4. 分两轮审查：先检查技术准确性，再以 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 句话）
  2. 核心发现——你发现的最严重问题，用业务语言描述（2–3 句话）
  3. 风险结论——用通俗语言说明整体安全状况（1 段）
  4. 数量统计——按严重程度统计发现数量，以小型表格呈现
  5. 排名前 3 的战略建议——提出体系化的修复措施，而非“修补 CVE-X”

执行摘要中应避免使用的词： payload、RCE、XSS、LDAP、SMB、kerberos、injection。逐一翻译这些术语。（写“攻击者可以在服务器上运行任意命令”，而不是“通过反序列化 gadget 链实现 RCE”。）

应包含的词语： 业务影响（customer data、regulatory exposure、operational disruption、financial loss）。每项发现都应关联到业务后果。

技术发现模板

## 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

每项指标都要用一句话说明选择依据：

  • AV:N——暴露于互联网（端口 443）
  • AC:L——没有特殊前置条件
  • PR:N——不需要身份验证
  • UI:N——不需要用户交互
  • S:U——不跨越安全范围
  • C:H I:H A:H——对数据库造成完整的读取、写入和可用性影响

如果两个合理的人可能给出不同评分，请记录你作出当前选择的原因。

CVSS 何时会误导

CVSS 无法体现业务背景。客户支持聊天面板中的 XSS，CVSS 评级为“中”，但已通过身份验证的客服人员会用它处理个人身份信息（PII）；其危险性高于某个不含元数据的内部服务上未经身份验证即可利用的“高危”SSRF。将 CVSS 作为最低基准，而非最高上限。

遇到这类情况时，应如实评定 CVSS，然后另加一段“业务影响调整”，说明为什么报告中的严重程度应更高。不要通过 CVSS 评分说谎。

CVSS v4.0（要求时使用）

CVSS v4.0 增加了环境和威胁指标，能够更好地反映现实世界中的风险。当客户要求使用时（PCI DSS 4.0 正朝这个方向发展），请使用它；否则，v3.1 仍是通用标准。

OWASP 风险评级（替代方案）

对于仅涉及 Web 应用的测试项目，如果 CVSS 显得牵强，OWASP 风险评级（基于多个因素计算可能性 × 影响）通常更易于传达。

证据规范

需要采集的内容

对于每项发现、每个操作，都要记录：

  1. 时间戳（UTC，ISO 8601）
  2. 源 IP（你的 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 天）
  • 仅保留报告和证据哈希清单，并可按请求删除

范围、限制与假设

这三个部分可以保护你和客户端。务必明确说明。

范围
  • 列明范围内的 IP、域名、代码库、账户，以及项目周期的起止时间
  • 排除项：客户端使用的第三方 SaaS（客户端并不拥有这些服务）
  • 应要求排除的范围：物理安全、针对员工的社会工程、DoS
限制
  • “测试仅从互联网进行；未提供内部网络访问权限”
  • “源代码审查不在范围内”
  • “根据 ROE，避免了对生产数据库的修改”
  • “未协调安排停机时间——测试时段为 22:00–06:00 UTC”
假设
  • “我们假设预发布环境与生产环境一致”
  • “我们假设 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 源文件生成以上所有格式的唯一可信来源

通过 Pandoc / 静态站点生成器，从一个 Markdown 源文件生成所有格式。切勿手动维护多个并行格式。

# 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 时间戳
混淆相同的发现按类别分组，并在表格中列出受影响项
忘记制定复测计划每项发现都要说明如何验证修复
未区分范围与限制范围 = 我们测试了什么；限制 = 哪些因素阻碍了测试
把信息性发现当作凑数内容要么删除，要么认真撰写

Bug Bounty 报告（面向不同受众）

Bug Bounty 审核人员时间紧迫，而且持怀疑态度。请作出相应调整：

  • 标题：在 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 向量示例（参考）

类别典型向量分数
未经身份验证的 RCEAV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H9.8
经过身份验证的 RCEAV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H8.8
存储型 XSSAV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N5.4
IDOR（读取 PII）AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N6.5
SSRF（云元数据）AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N9.0
开放重定向AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N4.3

请将这些作为起始参考值，并根据环境进行调整。

工具

工具用途
Pandoc + LaTeXMarkdown → 精美 PDF
Sphinx / mkdocsMarkdown → HTML 门户
DefectDojo发现跟踪、JSON 导出
Faraday汇总多个测试项目
Dradis协作撰写报告
serpico（已过时但仍在使用）渗透测试报告模板
Plextrac商业报告平台

关键参考资料

评论

支持 Markdown