文章总结： 文章指出红队报告交付后常因缺乏翻译工序导致检测能力无法落地，建议紫队活动必须产出可执行任务而非会议纪要，通过主机网络身份三层拆解攻击路径，优先补齐日志采集与时间同步等基础，利用ATT&CK进行覆盖率盘点而非仅贴编号，并强调必须通过受控复放验证规则有效性，同时建立以平均检测时长和告警有效率为核心的考核指标与责任机制。
综合评分： 92
文章分类： 红队,紫队落地,安全运营,实战经验,应用安全
报告交出去了，然后呢：从红队发现到防守落地中间隔着什么
原创
Sink
Sink
船山信安
2026年9月26日 00:00
湖南
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
防守视角 · BLUETEAM
报告交出去了，然后呢：从红队发现到防守落地中间隔着什么
紫队落地 · 写给报告收进文件夹就没下文的团队
交付会那天气氛不错。分管负责人说收获很大，蓝队记了两页笔记，会上认领了七八条。三个月后再问，真正落地的只有两条：改了一个口令策略，关了一个临时共享。剩下那三十几条里，有一半写着”我们需要改流程”，至今没人认领。这不是不重视。是中间缺了一道工序——把攻击手法翻译成检测能力的那道工序。这篇讲的，就是那道工序怎么做。
01三个月后能被说出来的，只有”改配置”那两条
一场评估下来，四十几条发现。按落地难度分，它们其实只有三类。
第一类：改配置。口令长度、共享目录、一个不必要的端口、一个默认账号。这类东西当天就能派单，运维两天内改完，复测一次就关掉。
第二类：改架构。网络要分段，跳板机要收口，外网系统要加一层认证。这类要排期、要预算、要跟业务部门谈。它排到下个季度，不算离谱。
第三类：改流程。告警没人看、日志没人留、变更没人登记。这类最要命，也最没人动。
我跟过几次三个月后的回访，结果出奇地一致。第一类完成度最高，第二类走了一半，第三类原地不动。而第三类里，最多的就是检测相关的内容。
原因不在态度。在于那份报告里，没有一条是蓝队能直接拿走用的。
我们写过”建议提升安全监测能力”。这句话我写过不下十次，现在看它就是一句废话。蓝队拿到它，不知道该去改哪条规则、该去找哪个系统要日志、该向谁申请采集权限。它描述的是目标，不是动作。
于是分工在这里断掉：红队认为交付已经完成，报告交了、会开了；蓝队认为自己收到的是一份漏洞清单，跟自己手上的规则库对不上。中间那道翻译工序，没有任何一个岗位负责。
攻击方的价值只有在防守侧落地才成立。没落地的发现，本质是一次昂贵的演练——花了三周，买回来一份自己知道自己弱在哪的确认书。
02紫队不是开会，紫队是派活
很多单位的紫队长这样：红队讲一遍，蓝队讲一遍，两边坐一起开个复盘会，出一份纪要，合影，结束。
这不叫紫队。这叫联席会议。
区别在产出物。紫队活动的产出必须是具体的、能被点名的东西：一条检测规则上线了、一个告警字段补齐了、一次预案演练跑完了、一条采集策略被改了。写在纸上、有负责人、有验收方式，才算数。
我现在的做法是：每次紫队活动结束，产一张表，四列——技术点、动作、负责人、验收方式。格式跟红队报告里的修复清单一样，只是对象是检测侧，不是运维侧。
一条检测规则。写清楚它盯什么行为、在什么数据源上跑、命中后等级是什么。附上”验收方式：用红队提供的样本事件，两分钟内命中”。
一个告警字段的补齐。告警里只有主机名是不够的。父进程链、命令行原文、用户名、来源地址，缺一个，值班的人就要自己去翻日志。
一次预案演练。告警响了之后谁接、多久之内要做什么决定、要不要断网。这一步没有演练过，告警响得再准也没用。
会上一句”这个后面我们能看到”，是最危险的一句话。它让所有人当场感到放心，然后在三个月后被彻底遗忘。它会阻止你去追问：哪台设备上看、哪条日志里看、多久能看到。
判断一次紫队活动成不成立，标准很土：活动之后，检测平台里是不是多了一条规则，或者少了一个盲区。两个都没有，那就是开了个会。
紫队这个词被用滥了。能派出去的活，才配叫紫队。
03把每一跳拆成主机、网络、身份三层痕迹
翻译工序具体怎么做。我用的是最笨的办法：拿报告里的某一跳，把它拆成三层，逐层问两个问题。
举一跳常见的。攻击方在一台办公电脑上，用一个办公文档拉起系统自带的脚本宿主，脚本向域内一台文件服务器发起连接，用的是一个普通域用户的凭据。这一跳在报告里可能只有一句话。
拆开是三堆完全不同的东西。
| | | |
| — | — | — |
| 层 | 这一跳会留下什么 | 要逼问的两个问题 |
| 主机侧 | 进程创建与父子关系、命令行全文、脚本执行记录、服务创建、计划任务 | 这台机器开审计了吗？命令行记录开了吗？事件有没有真的上报上来？ |
| 网络侧 | 来源地址与端口、域名解析请求、内网横向连接的发起方与去向 | 这段流量经过采集点了吗？内网分段之间有没有镜像或代理日志？ |
| 身份侧 | 谁登录、从哪台机器、用了哪种认证方式、凭据或票据的申请记录 | 身份系统的日志保留多久？异常登录的阈值设了吗？谁在看？ |
两个问题必须分开问：这层现在有没有采集，采了之后有没有告警。
有日志没告警，是最常见的状态，也是最容易被误判成”已覆盖”的状态。日志躺在平台里，没人写规则，等于没有。反过来，有告警没日志更糟——值班的人看到一条提示，却没有任何东西可供他往下追。
三层全都没有，就先去补采集。别急着写规则。
这一步最容易被跳过。写规则有成就感，做完能在复盘 PPT 上写”新增检测规则十二条”；补采集是脏活，做完什么也写不出来，还要去跟运维、跟网络、跟身份系统的管理员挨个谈。所以大家默认先写规则。
结果是十二条规则里有八条跑在空数据源上。它们永远不会响，但没人知道，因为它们没响过。
补一条采集，比写十条跑在空气上的规则有用。
04三件不性感的事，写在所有壁垒前面
检测能力立不起来，八成不是因为规则写得差，是因为底下三件事没做。它们都写在壁垒前面，做完没有任何人给你鼓掌。
第一件：日志保留周期。很多环境的终端日志只留七天。而攻击方从踩点到动手，用了十九天。中间那段你永远查不到。写规则的时候你手上有样本，测一次命中一次，看起来很漂亮；真出事的时候，样本在七天前，日志已经轮转掉了。规则还在，数据没了。
保留周期不是越长越好，但至少要盖住你能接受的最大发现延迟。如果你们的现状是”平均一个月后才发现异常”，那三十天的日志就是一个必然漏光的筛子。
第二件：时间同步。时区不统一、NTP 没配、几台域控之间差几秒到几分钟。主机日志说这件事发生在九点，身份日志说八点五十二，网络侧又说九点零七。跨源关联的规则写得再精巧，时间轴对不上，命中率就是零。
这件事的麻烦之处在于：它不会报错。规则照常部署，面板照常好看，只是该响的时候不响。查起来最难，因为没人会先怀疑时间。
第三件：关键主机的审计策略。域控、跳板机、文件服务器、证书服务。这几类机器上如果审计策略还是默认配置，那么在它们之上做的所有检测都是沙上建塔。而它们恰恰是最常被忽略的——因为没人愿意在这些机器上动配置，怕影响业务。
我的习惯是把顺序倒过来：先花两到三周做采集盘点，盘清楚哪些主机有日志、保留多久、时间戳统一到什么程度，然后再动第一条规则。这个顺序不能反。反了就是先装修再打地基。
一个团队愿意花两周去对齐 NTP，比愿意买一套新平台的信号可靠得多。前者说明他们真的打算查东西，后者只说明他们有钱。
05ATT&CK 的正确用法是覆盖率盘点，不是贴编号
现在很多报告里，每条发现后面都挂一串编号。看起来专业，读完不知道下一步做什么。编号在这里是装饰。
它真正的用法是盘点：我们这几年真实遇到过的手法，映射到哪些技术；这些技术里，我们现在能看到的占多少。
盘点表三列。第一列技术编号，第二列我们有没有遇到过（真实事件、演练、公开情报都算，分开标），第三列当前可见性。
关键在第三列，而且它不能只写”有”或”没有”。要分成三档：有告警、只有日志、完全看不到。
第一列人人会填，第二列查记录就能填。第三列没人愿意填——因为它一填就把盲区摆到桌面上了。而盲区是会被拿去问责的东西。
所以我的建议是：第三列先只给自己看。等它填完一轮、看清楚全貌之后，再决定哪些拿出去讲。这不叫隐瞒，这叫先让盘点能做完。一上来就要公开，那张表一定会被填得很好看。
盘点的价值不在于算出覆盖率那个数字。在于三件具体的事：明年的预算往哪几个技术上投；哪些盲区是我们正式接受的风险、写进纪要、由负责人签字；下一次演练该挑什么手法做靶子——挑那些标着”完全看不到”的。
还有一句要提醒：别追求覆盖率好看。覆盖到九成，但九成里全是”只有日志没告警”，等于零。可见的定义是有人会因为这条数据被叫醒，不是这条数据被存下来了。
一页纸的盘点表，比一份挂满编号的报告有用。
06规则写完不算完：受控复放这一步没有替代品
规则上线了，报告里写着”已覆盖”。到这里，绝大多数团队就停了。
停在这里，等于什么都没做。因为”写了一条规则”和”这条规则会响”之间，隔着一次复放。
受控复放说起来简单：红队在同一个授权范围里，按原手法再打一遍。蓝队不看剧本，不提前被告知时间点，就看告警有没有真的弹出来。
看三个东西。
弹了没有。这是底线。没弹，说明数据源、字段、或者规则逻辑有一处是断的，回去逐层查。
多久弹的。这一条最常被忽略。两小时后才弹，跟没弹差别不大——那时候横向移动已经走完，凭据已经拿到。检测时间要按分钟算，不按天算。
弹出来的内容够不够。只有”检测到可疑脚本执行”加一个主机名，值班的人还得自己去翻父进程、翻用户、翻来源。这次翻不到，下次也翻不到。
复放失败最常见的原因只有一个：规则盯的是字符串，不是行为。写规则的时候，手里只有红队当时留下的那一个样本，于是顺手把路径、文件名、某段命令行原样写进了条件。换一个名字，规则就哑了。
下面是我在文档里用的规则结构示意，只为表达该盯哪几类条件，不是可直接运行的东西：
规则示意（伪结构，仅表达结构，不可直接运行）
当 收到 进程创建事件
且 父进程 属于 办公软件集合
且 子进程 属于 系统脚本宿主集合
且 命令行长度 > 200 或 含 编码解码特征
且 主机名 不属于 运维白名单
则 生成告警：等级 = 高
附加字段：父进程链 / 命令行原文 / 用户名 / 来源主机
关联查询：同一主机 60 分钟内 身份侧异常登录
抑制条件：该主机 24 小时内已产生同类告警
注意”父进程属于办公软件集合”这一条。它写的是关系，不是名字。办公软件拉起脚本宿主，这个关系成立的条件很窄，但它不依赖于任何一个具体的文件名。这才是能扛住复放的规则。
说实话，这一步很多团队不敢做。因为复放会打脸。规则上线报告里写着”已覆盖”，复放一次发现根本没响，那份报告就不好看了，季度汇报也不好看了。
所以我偏激地认为：没做过受控复放的检测规则，等于没有。这话不客气，但我没见过例外。
07指标要敢被打脸，组织要有人担责
先说指标。修复率是最好看、也最没用的那一个。
改配置算修复，改流程也算修复，把风险标记为”已接受”还是算修复。一个团队改了两条配置、接受了十五条风险，修复率能报到很高。数字在涨，能力原地不动。
三个更有用的。
平均检测时长。从攻击动作发生，到告警出现在值班台，中间隔多久。这个数字只能靠复放测出来，日常运营测不到——因为日常没人告诉你攻击是从哪一刻开始的。
告警有效率。一段时间内产生的告警里，真正需要人处理的占多少。这个指标的意义在于它同时约束两头：太低说明规则太松，值班的人会被淹没；太高也要警惕，可能说明规则只盯着已经被知道的那几种手法。
同一手法二次是否能拦住。上次用过的手法，改个名字再来一次，这次能不能在同样的时间点被发现。这是三个里最狠的一个，也是最少人用的一个。
为什么少人用，答案不难猜：它是唯一一个会打脸的指标。前两个你可以自己定义口径，第三个不行——打一次，结果就是结果。
很多复盘材料里的指标很漂亮：检测率提升多少、误报下降多少、规则新增多少条。但没有一次二次验证。因为一验证，数字会掉下来。
掉下来是正常的。第一次验证掉下来，第二次就上去了。怕掉下来而不做验证，那个漂亮的数字会一直挂在墙上，直到真出事那天被一次性打穿。
再说组织。这是最难写的一段，因为它没有技术方案。
红队和蓝队的考核目标天然冲突。红队被打穿丢人，所以他要证明自己打进去了；蓝队要报”已拦住”，所以他要证明防线起作用了。同一个动作，一方的成绩是另一方的失分。
在这种结构里开复盘会，双方都会本能地保护自己的数字。红队强调手法高明，蓝队强调”我们其实有日志”。会议气氛融洽，结论空白。
紫队能不能成立，取决于有没有一个人愿意为整体安全结果负责，而不是为各自的 KPI 负责。这个人通常不是技术最强的那个。是那个能在会上说”这次我们没检测到，记上”的人。
记上，才有下一次。
ONE LINE
没被复放检验过的检测能力，只是写在文档里的愿望。
参考来源
· MITRE ATT&CK 知识库（attack.mitre.org）：MITRE 自 2013 年起公开维护的对抗行为知识库，按战术、技术、子技术分层描述攻击者行为，含 Enterprise / Mobile / ICS 矩阵，持续更新
· MITRE Engage（engage.mitre.org）：MITRE 于 2021 年发布的防御侧知识库，围绕”主动防御/欺骗与对抗者交战”组织内容，用于规划防守方的对抗交战活动，与 ATT&CK 互补
· NIST Special Publication 800-115《Technical Guide to Information Security Testing and Assessment》：美国国家标准与技术研究院 2008 年发布的测试与评估技术指南，含测试后分析与报告交付阶段的流程要求
· NIST Cybersecurity Framework (CSF) 2.0：美国国家标准与技术研究院 2024 年发布的框架更新版，在原有识别、保护、检测、响应、恢复五个功能之外新增”治理”功能，其中”检测”功能与安全持续监测直接相关
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：船山信安 Sink
Sink《报告交出去了，然后呢：从红队发现到防守落地中间隔着什么》