文章总结： 本文批判传统红队报告仅罗列漏洞列表的低效模式，主张交付物应聚焦攻击路径叙事，将多个中低危漏洞串联成完整攻击链以体现真实风险。建议按受众分册：决策层关注业务影响与优先级，运维层获取可执行修复清单，蓝队获得检测规则建议。强调风险评级需结合攻击成本与业务影响而非仅CVSS分数，证据链必须包含时间戳与主机标识，建议需明确责任人、验收标准及排期，汇报时应先同步关键路径以引导建设性讨论。
综合评分： 92
文章分类： 红队,实战经验,安全运营,安全建设,WEB安全

写完就被拖进文件夹：一份真正有用的红队评估报告长什么样

原创

Sink
Sink

船山信安

2026年10月2日 00:00
湖南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

安全复盘 · REDTEAM

写完就被拖进文件夹：一份真正有用的红队评估报告长什么样

红队评估 · 写给只会写漏洞列表的攻方

一份三万字的报告，甲方读完第一章就放下了。不是他不负责。是他翻到第三页发现，后面两百页他上个月在漏扫平台上看过一遍。这篇不谈模板怎么填，谈一个更难的问题：人花三周时间，到底该交付什么。

01漏洞列表不是交付物，是扫描器的副产品

驻场三周，交付一份报告。目录通常是这样的：执行摘要、漏洞详情、附录。漏洞详情占两百页，每条一个固定模板：描述、危害、CVSS 分数、修复建议。

这种报告的产能很高。换个客户名，往下填就行。

厚不等于有用。我见过尴尬的一次：报告两百八十页，对方安全负责人在会上翻着翻着抬头问了一句，所以最要紧的是哪一条？我们翻回摘要页，那页按分数排了十九条高危。

十九条并列，就是没有优先级。

漏洞列表还有个隐蔽的坏处：它把读者的注意力平均分配。十九条高危排在一起，看起来一样重。而决定成败的，往往是其中两三条能串起来的组合。列表越长，这个组合越难被看见。

问题在于：这份东西里，有多少是只有人能写出来的？

把那两百页拿掉，剩下的东西通常只有三页。三页里面还有一页是项目范围声明，一页是风险等级说明。

扫描器一夜能出一千条，误报率你心里有数。人花三周，值钱的地方不在”再找一遍同样的东西”，在于判断这一千条里，哪三条能连成一条路。

我早年写过的报告，现在回头看全是废话。不是因为写得浅，是因为我把力气全花在”把每一条写得更规范”上。编号规范、截图规范、风险等级规范。规范救不了没有判断的报告。

甲方付钱买的不是”再扫一遍”，是”你告诉我先动哪三件事，以及为什么”。前半句机器能做，后半句不能。

02真正稀缺的产出，是攻击路径叙事

举一个在很多单位都见过的组合。

一个”中危”的配置文件可读，一个”低危”的内网共享可写，一个”高危”但标的着”利用条件苛刻”的老服务远程代码执行。三个单看都不紧急，运维排期能排到明年。

放在一起是另一回事：从公网一个目录遍历读到配置文件里的数据库口令，这个口令能登进内网某台机器的共享，那台机器上跑着一个没人认领的老服务，那个服务就是 RCE。

这条链的价值不在三个漏洞本身。在于它回答了一个扫描器永远答不了的问题：这几个东西为什么会同时出现。

所以要把”刚好成立”那几步写穿。比如：那个共享之所以还开着，是三年前为了排障临时开的，事后没人关；那个老服务之所以还在跑，是它挂在一个没人认领的域名下，拆掉它会牵扯一个已经没人维护的接口；而 RCE 之所以能落地，是因为那台机器的补丁停在两年前。

三个因素叠加，路径才成立。缺一个，路径就断。这句话才是报告里最值钱的一句。

对比一下两种写法。

模糊的写法：”攻击者可利用上述漏洞进一步渗透内网。”这句中每一个字都对，也每一个字都没用。运维看完不知道先关哪个口子。

清楚的写法：”从公网 443 端口出发，经过三跳，第五天早上我们拿到域控的 DCSync 权限。全程唯一拦住我们的是一台终端防护，它的告警在第三天才被处理，那时我们已经移动完了。”

后者能被讨论，能被反驳，也能被指派。前者只能被跳过。

写路径叙事有个笨办法：按时间线写，一跳一段，每段只回答三个问题 —— 我们从哪来、靠什么过去的、下一跳凭什么成立。写得像流水账也没关系。流水账能被核对，形容词不能。

还有一件常被漏掉的事：把走不通的路径也写进去。我们试过另外两条，一条卡在双因素上，一条因为那台机器上的终端防护真的响了。这些”没走通”的信息对防守方价值极高，它说明哪些投入是真起了作用。只报成功的路径，会让对方以为所有防线都没用。

报告的核心动作只有一个：把”三个中危”翻译成”一条通往域控的路”。

03三拨人关心三件事，一份通吃的结果是没人看

报告交出去，实际会落在三种人手里。他们翻报告的目的完全不同。

| | | |
| — | — | — |
| 谁在读 | 他真正要的答案 | 给他的篇幅 |
| 分管安全的负责人 | 最坏能坏到什么程度，下季度先干哪三件事，这笔预算花得值不值 | 一到两页，超了就不看 |
| IT 运维 / 系统管理员 | 哪台机器、哪个配置项、改成什么值、改完怎么验证、会不会影响业务 | 一张能直接导进工单系统的清单 |
| 蓝队 / 检测团队 | 你们进来时留了什么痕迹，我们的日志里有没有，没有的话要补哪条规则 | 检测改进建议 + 原始时间线附录 |

最常见的失败，是把这三份内容按顺序摞进同一个文档，让每个人自己翻。负责人翻到第四十页就回去找摘要，运维要到第二百页才找到跟他有关的那三行。

解决办法不复杂：一开始就分册。

第一册给决策层。两条以内写完整路径，三行写优先级，不出现任何 CVE 编号。控制在两页。

第二册是修复清单。一行一条，字段固定：资产、动作、指派岗位、验收标准、复测时间。能直接粘贴进工单。

第三册给检测团队。每一跳对应的 ATT&CK 技术编号、你们留下的日志特征、现有告警为什么没响、建议补哪条规则。原始时间线放附录。

给负责人的那一页里，最常见的错误是塞技术细节。写”通过票据派生攻击拿到服务账号凭据”，他不知道这有多严重；写”我们用一台普通办公电脑，在没人察觉的情况下拿到了能导出全部员工数据的权限”，他立刻知道该批预算。

第一册里可以牺牲术语的准确性，不能牺牲可理解性。术语留给第二册和第三册。

有人会觉得分册是讨好甲方。不是。分册是在替对方省时间，而省下来的时间，才是你的结论被读完的概率。

04风险等级别照抄分数，落到成本和影响

CVSS 是给单个漏洞打分的，不是给”这条路径”打分的。

一个 7.5 分的洞，如果它躺在一台没人路由过去的内网机器上，实际威胁可能低于一个 5.3 分、但直接暴露在公网、且已经被自动化工具反复扫的洞。分数不会告诉你这件事，位置会。

我的做法是给每条路径补两个字段：攻击成本和业务影响。两个都要写成能核对的具体句子。

| | | |
| — | — | — |
| 维度 | 抽象写法（别写这个） | 具体写法（写这个） |
| 攻击成本 | 利用难度中等，需要一定技术能力 | 无需前置凭据，公网可达，两小时内完成，全程未触发告警 |
| 业务影响 | 可能造成敏感数据泄露，影响业务连续性 | 可读取生产库全量客户手机号，约四十万条；恢复需从三天前的备份回滚 |
| 依赖条件 | 在特定环境下可被利用 | 依赖三年前为排障临时开启的文件共享，该共享关闭后本路径中断 |

还有一层更根本的问题：CVSS 的基础分算的是漏洞本身的性质，不含环境。它本来就留了时间分和环境分给人填，但很多人只用基础分。于是同一条漏洞，暴露在公网和躺在内网隔离区，拿到的是同一个数字。数字一样，决策就不可能不一样 —— 这才是照抄分数真正害人的地方。

“依赖条件”这一栏是我后来才加的。它有个意外好处：复测的时候可以直接照着检查。当初让它成立的那个条件还在不在，一测就知道，不用重新走一遍完整路径。

风险等级可以继续保留，但把它降级成附注。正文里说话的应该是成本和影响，因为它们才是能拿去做决策的东西。

05证据链：报告能不能站住脚，全看这里

一个真实发生的场面：报告里写”已成功获取服务器权限”，配图是一张命令行窗口。对方运维问”哪台服务器”，答不上来，因为截图裁掉了主机名。这条发现当场降级成扯皮。

三条硬规矩，缺一条都不算证据。

截图要带时间戳和主机标识。一张只有命令输出的黑底窗口，三个月后没人知道它是在哪台机器、哪个时刻跑出来的。把时间、主机名、来源地址一并截进去。

复现步骤要能被第三个人照着跑通。写”使用某工具获取权限”等于没写。要写清楚命令、参数、返回了什么、哪一行输出是成功标志。

敏感证据要脱敏，但保留可核对性。客户名、真实手机号、身份证号一律打码；资产编号、内网地址段、服务版本号留着 —— 对方要靠这些字段认出这是自己的机器。

我习惯在每次动手前先跑一遍固定动作，让证据自带上下文。都是只读命令，不改变目标任何状态。

每一步操作都留一份可核对的时间戳（UTC，避免时区扯皮）

date -u +”%Y-%m-%dT%H:%M:%SZ” | tee -a engagement.log

记录当前主机与来源地址，截图时一并入镜

hostname; whoami; hostname -I

只读地确认目标可达与响应状态，不改变任何数据

curl -s -o /dev/null -w “%{http_code} %{time_total}\n” https://example.com/

还有一条容易被忽略：报告里的时间线要跟对方的日志时间线对齐。我们习惯记 UTC，运维看的是本地时间，两边差八小时的时候，蓝队会以为你的发现和他手上的告警根本对不上。时间统一标注时区，是最省事的一件事。

附录里的原始日志也别堆。按路径分段，每段前面写一行”这一段要证明什么”。三个月后有人回来看，他先看到结论，再看到证据，而不是在几百行日志里自己找。

证据链的用处不只在交付那一刻。半年后出了真事，这份报告会被翻出来当基准；到那时，一条时间戳完整的发现能替你挡掉很多不必要的争论。

06建议要能指派到一个岗位、一个验收标准

报告里写”建议加强密码复杂度策略”，运维看完不知道该去改组策略，还是该去买个密码管理器。

写”建议加强员工安全意识培训”，我年轻时写过不下二十次。它唯一的用处是：将来出事的时候，报告里有一行字证明我们提醒过。

| | |
| — | — |
| 正确的废话 | 能派活的写法 |
| 加强口令安全管理 | 由域管理员在默认域策略中把最小口令长度设为 12，并开启过期前 14 天提醒；三十天后抽查十个账号验证 |
| 定期清理不必要的共享 | 由 IT 运维关闭文件服务器上的临时共享目录，并在变更单中登记；验收标准为外部扫描无法列出该共享 |
| 提升安全监测能力 | 由检测团队在 SIEM 中新增一条规则，覆盖特定进程创建行为；验收标准为我们提供的样本事件能在两分钟内命中 |

判断一条建议合不合格，有个很土的办法：念一遍，看能不能答出四个问题 —— 谁做、做什么、怎么算做完、什么时候验收。

答不出”谁做”的，通常是因为你也不确定该找谁。这时候别写”相关部门”，去问清楚岗位名称。多花二十分钟，这条建议才可能被真正执行。

答不出”怎么算做完”的，说明这条建议本身没想清楚。验收标准写不出来，多半是因为修复动作本身就是模糊的。

再补一个字段：排期。每条建议后面写一个建议完成时间，分三档 —— 两周内、本季度内、下一个预算周期。这不是替对方做决定，是给对方一个可以反驳的起点。对方说”两周做不完”，讨论就开始了；不写时间，讨论永远不会开始。

复测命令也一并写进建议里，让对方自己就能验。比如口令策略那条，给一条只读的核查命令：

抽查域账号口令最近一次设置时间（只读，用于验证策略是否已应用）

Get-ADUser -Filter * -Properties PasswordLastSet |

  Select-Object -First 10 Name, PasswordLastSet

一条写不出验收标准的建议，不是建议，是免责声明。这条我用了很久才敢这么讲，因为我自己写过太多。

07汇报会：别让人第一次在会上看到失败路径

最重要的一条放在这里：会前，把最关键的那条路径单独发给分管安全的负责人，让他先消化一次。

会上第一次听到”我们已经拿到域控”，任何人的第一反应都是防御。防御一旦起来，后面两小时你说的每一句都会被当成攻击，而不是分析。

顺序也有讲究。

开场两分钟讲边界。这次假定攻击者已经能接触到什么，哪些系统不在授权范围内。边界讲清楚，后面的每一步都不会被理解成”你们是不是违规进来的”。

直接给结论。几条完整路径、每条的终点是什么、各自的攻击成本。不要铺垫，前面的铺垫每多一分钟，结论被听进去的概率就少一分。

挑一条讲透。只讲最有代表性的那条，把每一跳的依赖条件说清楚。一条讲透，比五条讲一半有用。

修复清单放到末尾。清单是给执行的人看的，不是给会议看的。会上一页页念清单，等于把决策时间换成念稿时间。

措辞上有个小改动，效果差很多：把”你们”换成”这台机器”。

讲”你们的内网横向管控等于没有”，对方听见的是指控。讲”这台跳板机上没有装终端防护，所以我们的横向移动没有触发任何告警”，对方听见的是事实。同一件事，前者让人想辩解，后者让人想改配置。

还有一条关于分寸：不要在会上讲”我们本来还能做什么”。拿下域控之后还能动什么、还能碰哪些业务系统，这些写进附录，单独讲给技术负责人听。放到大会上，它就变成了炫技，而炫技会把听众从”我要改什么”推回”这帮人太厉害了，我们改不动”。

会后二十四小时内补一份纪要，只写三样：达成了什么共识、谁认领了哪一条、下一次对齐是什么时候。会上没人认领的那条，等于没有结论。

这份纪要比正式报告更常被翻出来，因为它短。

ONE LINE
报告写完的那一刻只是交付开始；有人照着它改了一行配置，才算交付完成。

参考来源

· NIST Special Publication 800-115《Technical Guide to Information Security Testing and Assessment》，美国国家标准与技术研究院，2008 年发布；其中对测试流程与报告交付阶段有专门章节

· MITRE ATT&CK 知识库（attack.mitre.org）：攻击者战术、技术与规程的分类框架，含 Enterprise / Mobile / ICS 矩阵，持续更新；红队报告常用其技术编号标注每一跳

· OWASP Web Security Testing Guide（WSTG）：OWASP 官方 Web 安全测试指南，4.x 系列持续更新，含测试报告与风险评级章节

· Penetration Testing Execution Standard（PTES，渗透测试执行标准）：公开社区标准，分前期交互、情报收集、威胁建模、漏洞分析、利用、后渗透、报告七个阶段

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：船山信安 Sink
Sink《写完就被拖进文件夹：一份真正有用的红队评估报告长什么样》