红队演练：用对抗视角补充常规识别的盲区（红队设计、演练脚本、产出转化）

红队演练：用对抗视角补充常规识别的盲区（红队设计、演练脚本、产出转化）本文档提供：表2红队设计判定表；表3演练脚本要素表；式(1)检测覆盖缺口指数；式(2)修复闭环率；表4试错记录表；表5紫队交接表；表6产出转化追踪表；表7演练停摆排查表；四条决策规则和一处矛盾；表8三套场景表；完整案例一个。2026-11-03表1目录与定位表这一节的标题读完你能拿到什么这一节在全文中的功能一、常规识别停在“威胁清单”，红队从“这条路径能不能走通”开始表2红队设计判定表在演练设计前确定红队要验证哪几条威胁模型中的假设二、红队设计：范围、规则和目标资产三件事先定死表3演练脚本要素表把演练从“打哪算哪”变成有授权边界和成功标准的行动三、演练脚本不是剧本：路线假设、试错记录和转向条件表4试错记录表记录红队实际走的路径和失败点，而不是事后编一条完美路径四、紫队交接：红队每突破一个检测点，蓝队当场知道表5紫队交接表和式(1)把红队的攻击路径实时转成检测规则的验证项五、产出转化：发现、检测规则、修复动作和复核，四件事对得上表6产出转化追踪表和式(2)把演练报告里的发现变成可跟踪、可复核的修复动作六、演练做了一轮就停在报告里，先查这五处表7演练停摆排查表定位红队发现没有进入检测和修复环节的原因七、什么时候做红队、什么时候做紫队、什么时候不做：四条规则和一处矛盾四条决策规则和矛盾权衡规则处理演练成本与检测能力提升之间的取舍八、完整版、精简版、极简版按组织成熟度和监管要求选表8三套场景表按TIBER-EU/DORA要求或内部检测需求选择范围按第一列在正文找对应那节，按第二列判断这节有没有你要的东西，按第三列判断这节是否对应你当前卡住的位置。威胁模型上列了23条威胁场景，检测规则覆盖了其中17条，覆盖率看起来不低。但过去两次真实事件中，攻击者走的路径在威胁模型上找不到对应行，检测规则一条都没有触发。威胁模型回答的是“可能发生什么”，检测规则回答的是“有没有在监控”，两者之间缺一步：这条威胁场景对应的攻击路径，在实际环境中能不能走通、走到哪一步会被看见、如果没被看见是因为什么。一、常规识别停在“威胁清单”，红队从“这条路径能不能走通”开始威胁建模产出的是威胁清单和风险评分，检测工程产出的是规则和告警。两者之间的缝隙是：威胁清单上的场景没有一条被实际执行过，检测规则没有一条被实际触发过。红队的价值不在于“再找一遍漏洞”，在于用对抗视角走一遍威胁模型中的路径，验证三件事：这条路径在真实环境中是否可行、防守方在哪一步应该看见、如果没看见是缺日志、缺规则还是规则在噪音中被淹没。表2红队设计判定表判定问题答“是”时答“否”时判定示例威胁模型中是否有至少3条场景尚未被任何检测规则覆盖或验证红队优先验证这3条，不另起新场景红队从威胁模型中评分最高的3条开始，验证检测覆盖是否真实有效威胁模型23条，6条无对应规则，红队先走这6条过去12个月是否发生过“威胁模型有、检测规则有，但事件中未触发”的情况红队重点复现该路径，定位检测失效环节红队按威胁模型正常选场景一次横向移动事件中规则未触发，红队复现该路径本次演练是否需要向监管或审计方提交演练证据（TLPT、TIBER-EU等）设计必须对齐外部框架的交付物和时限按内部检测需求设计，不额外增加外部框架的交付物适用TIBER-EU框架时，紫队协作和交付物时限有强制要求防守方（蓝队）是否具备实时监控和告警能力，能在演练中观察红队动作可采用紫队实时交接，红蓝同步采用半盲或全盲模式，演练后复盘蓝队有SIEM和值守，可做实时紫队红队执行方是否具备与本次目标匹配的TTP能力（不是通用渗透测试）按威胁情报选定的对手TTP设计路径缩小范围，只验证基础攻击面，不模拟高级对手红队有凭证传递和横向移动能力，可模拟内部攻击者红队不是渗透测试的升级版。渗透测试回答“这个系统有没有已知漏洞”，红队回答“如果对手按这条路径打过来，防守方能不能看见、能不能在造成后果之前响应”。MITREATT&CK在红队中的用法是：先选一个与本组织相关的对手，提取其实际使用过的TTP，再把这些TTP映射到本组织环境中可执行的路径。红队路径的来源是威胁情报和威胁模型，不是漏洞扫描结果。二、红队设计：范围、规则和目标资产三件事先定死红队演练最常见的失败不是红队打不进去，是打进去之后不知道“这算成功还是失败”，或者打到了范围之外的目标，或者蓝队在演练中以为发生了真实事件而启动了应急响应。设计阶段的三件事——范围、交战规则（RoE）、目标资产——必须在演练开始前书面确定，演练中不修改。表3演练脚本要素表要素填什么什么算填完缺了这一项会怎样示例演练目标与成功标准本次要验证的威胁模型假设；成功标准写“到达哪一层”或“触发哪条检测”目标可观察，成功标准不写“提升安全意识”演练结束后无法判断是否达到目的目标：验证从VPN入口到客户数据库的路径是否被检测；成功标准：红队到达数据库所在网段或蓝队在任一阶段告警授权边界（RoE）书面授权链；允许的目标资产清单；禁止动作（如删除数据、拒绝服务、触碰生产真实数据）RoE由授权人签署，目标清单与资产清单可对应演练中越界，或蓝队误判为真实攻击RoE允许读取测试数据库前100行，禁止导出全量数据目标资产分级皇冠明珠（核心数据、支付系统、密钥）、次级目标（域控、堡垒机、代码仓库）、跳板资产（VPN、办公终端、第三方接口）每类资产有明确的“允许到达/允许读取/仅探测”权限红队把时间花在低价值资产上，或越权触碰核心数据皇冠明珠采用假定突破模式（从低权限起点开始），跳板资产做初始访问验证蓝队可见性模式全盲（蓝队不知情）、半盲（管理层知情，SOC不知情）、紫队实时（蓝队实时观察并同步）模式选定，且与蓝队值守能力匹配全盲模式下蓝队无实时监控，演练退化为事后复盘SOC有24小时值守，采用紫队实时模式时间窗口与中止条件演练起止时间；紧急中止（KillSwitch）的触发条件和联系人中止条件书面化，联系人可触达演练中出现意外影响时无法快速停止发现真实入侵迹象或生产受影响超过5分钟即中止目标资产的选择决定了演练的“深度”。皇冠明珠做完整攻击链的风险过高，通常采用假定突破模式：从已经获得低权限的起点开始，验证“已经进入内网的攻击者能不能到达皇冠明珠”。跳板资产做初始访问验证，检验边界防护。次级目标可以做从外部到核心的完整路径。三类资产的演练深度不同，在脚本中分开写，不混在一条路径里。三、演练脚本不是剧本：路线假设、试错记录和转向条件把红队脚本写成“第一步钓鱼、第二步上线、第三步横向、第四步拿数据”的完美剧本，是对红队实际工作的误解。真实攻击者的操作充满失败和调整：命令解析错误、权限不足、服务控制失败、工具被拦截，然后换一种写法或换一条路径才成功。红队脚本的价值不在于预先设计一条无摩擦的路径，在于记录“原本假设走哪条路、实际在哪一步失败、失败后转向哪条路、转向后是否被检测”。表4试错记录表记录项填什么什么算填完示例路线假设演练前基于威胁情报和威胁模型选定的路径假设写到可执行的动作序列假设：通过VPN入口的弱口令进入，横向到堡垒机，再从堡垒机访问数据库实际尝试与失败点每一步实际执行了什么、结果是什么、在哪一步失败记录具体错误、拦截或不可行原因VPN登录成功，但堡垒机需要多因素认证，假设中的“凭证传递”不成立转向决策失败后基于什么新信息换了哪条路新信息能推翻上一轮的哪个假设发现堡垒机不可达，转向办公终端到代码仓库的路径，因为代码仓库可能有硬编码凭据检测观察点每一步蓝队是否告警、告警时间、告警内容记录“有告警/无告警”和对应的规则或日志来源VPN登录有告警（规则VPN-003），堡垒机尝试无告警（日志未采集）成功或终止时的状态到达了哪一层、触碰了什么、是否达到脚本成功标准明确“到达/未到达”和对应的资产到达代码仓库所在网段，未触碰数据库，成功标准“到达数据库网段”未达到，但触发了新的检测缺口记录试错记录的作用不是让红队“交代失败”，是让防守方看到：哪一步本该有检测但没有，哪一步有检测但告警没有被响应，哪一步的失败是因为防守方确实做了有效的控制（例如多因素认证阻止了凭证传递），哪一步的失败是因为红队工具或环境的问题（与防守能力无关）。没有试错记录，演练报告只能写“红队是否拿到目标”，无法回答“防守方在哪一步起了作用、哪一步没有”。四、紫队交接：红队每突破一个检测点，蓝队当场知道传统红队演练中，蓝队在演练期间可能完全不知情，演练结束后拿到报告才知道“原来他们从这里进来的”。这种方式能测试蓝队的真实检测能力，但红队发现的检测缺口要等到报告交付后才开始修复，中间的延迟可能以周计。紫队模式在红队执行过程中让蓝队实时或当天同步看到攻击动作，红队每走一步，蓝队当场核对“这条路径我有没有规则、规则有没有触发、告警有没有人看”。表5紫队交接表交接项红队提供什么蓝队回什么什么算完成示例攻击动作与时间戳每一步的TTP、执行时间、源/目标对应的日志源、告警记录、规则编号每个动作有“检测到/未检测到”的结论横向移动动作在14:23执行，蓝队回“无对应告警，日志未采集该事件ID”检测缺口分类未检测到的动作属于哪类缺口：日志缺失、规则缺失、规则存在但未触发、告警被淹没蓝队确认缺口分类并提出修复方向缺口分类有红蓝双方确认缺口为“日志缺失”，蓝队确认事件ID4624未开启审核规则验证结果对已有规则，红队动作是否触发了规则；触发后告警是否到达值守蓝队确认规则有效性，或记录“规则失效”每条相关规则有“有效/失效/未测试”结论规则LSASS-001存在，但红队使用混淆变体未触发，标记“失效”实时修复动作红队是否在演练中配合蓝队做受控复测（同一动作在规则修改后重放）蓝队修改规则或补日志后，红队重放同一动作复测通过，或记录“复测仍未通过”蓝队补了事件ID审核后，红队重放横向移动，告警在90秒内到达式(1)检测覆盖缺口指数G=D未检测÷D总动作×100%变量定义：G为检测覆盖缺口指数，以百分比表示；D未检测为表5中红队执行的动作里，蓝队确认为“无对应告警”或“告警未到达值守”的动作数；D总动作为红队实际执行且蓝队有足够日志可核对的攻击动作总数，不含因环境问题失败、不产生可检测痕迹的动作。两个常见错误：D总动作把“红队工具失败、没有执行”的动作算进去，这些动作没有产生可检测行为，计入分母会人为降低G；D未检测把“规则存在但告警被淹没”和“完全没有日志”混为一类，两者的修复方向不同，在表5中应分开记录。校验方法：手里有表4的试错记录和表5的紫队交接表；逐条核对红队动作与蓝队结论；算出的G超过40%时，演练的产出重点从“路径验证”转为“补日志和补规则”；G在20%至40%之间时，优先修复“日志缺失”类缺口。示例：红队执行了15个可检测动作，其中6个无告警，G=6÷15×100%=40%。6个未检测动作中，3个属于日志缺失，2个属于规则缺失，1个属于规则存在但被噪音淹没。五、产出转化：发现、检测规则、修复动作和复核，四件事对得上红队报告交付之后最常见的结局是：报告里的发现被读了一遍，高危项被“尽快修复”，中低危项进入一个没有截止日期的清单，三个月后没有人记得哪条发现对应哪条规则、哪条规则已经修改、修改后有没有复测。产出转化的要求是：每一条红队发现都有一条对应的检测规则或控制动作，每一条规则修改都有一次复测记录，复测结果有“通过/不通过”的结论，不通过的有下一步动作。表6产出转化追踪表发现编号红队发现缺口分类检测规则/控制动作责任人关闭时限复测方式与结果状态F-01横向移动使用Pass-the-Hash未被检测规则失效修改规则LSASS-001，增加对NTLM认证异常组合的匹配检测工程甲发现确认后14天红队重放同一动作，告警在90秒内到达，通过已关闭F-02VPN登录失败次数异常无告警规则缺失新增规则VPN-009，5分钟内失败5次触发检测工程乙发现确认后7天红队重放5次失败登录，告警到达，通过已关闭F-03代码仓库访问日志未采集日志缺失开启代码仓库审计日志，接入SIEM平台工程丙发现确认后30天重放克隆动作，日志在SIEM可查，通过进行中F-04告警在值班期间被其他告警淹没告警淹没调整告警优先级，将横向移动类告警升为P2并独立通知SOC负责人丁发现确认后14天红队重放，告警在2分钟内到达值守且未被合并，通过已关闭式(2)修复闭环率C=R通过÷R总×100%变量定义：C为修复闭环率，以百分比表示；R通过为表6中“复测结果”为“通过”的发现条数；R总为表6中状态不是“接受”的发现总条数。状态为“接受”的发现不计入分子分母，但必须在表6中记录接受人和复核日期。两个常见错误：把“规则已修改”但没有复测记录的发现算作已关闭；R总把“接受”的发现算进去，导致闭环率被未计划修复的项稀释。校验方法：手里有表6和对应的复测记录；逐条核对“复测结果”是否有实际重放和告警到达时间；算出的C低于70%时，下一次演练的产出重点转向关闭已有发现，不新增演练场景。示例：表6中5条发现，4条状态非“接受”，其中3条复测通过、1条复测未通过（规则修改后告警仍未到达），C=3÷4×100%=75%。产出转化的另一项要求是检测规则的覆盖率可盘点。红队发现的缺口修复后，要回头更新威胁模型的覆盖状态：原来“无对应规则”的威胁场景，现在有规则且有复测记录，威胁模型的“已验证”字段从“否”改为“是”。这一步不完成，威胁模型和检测能力之间仍然是两张皮。六、演练做了一轮就停在报告里，先查这五处红队演练报告在管理层会议上汇报了一次，之后没有新的演练、没有规则更新、没有复测记录，按表7顺序查。第一检查点不打开红队报告，先打开检测规则库的最近修改记录。表7演练停摆排查表检查点打开什么看什么什么算正常不正常时怎么改一检测规则库的修改记录红队演练日期之后，是否有规则新增或修改记录演练后30天内有规则变更把表6中状态非“接受”的发现逐条指派，设定关闭时限二式(2)的C值发现是否在关闭C不低于70%，或上升趋势对逾期未关闭的发现，在管理层报告中列示，不留在检测团队的待办中三表6“复测结果”列关闭的发现是否有实际重放记录和告警到达时间每条关闭的发现有复测记录补做复测，不接受“规则已改”作为关闭依据四威胁模型的“已验证”字段红队验证过的威胁场景是否已标记已验证场景的字段已更新逐条更新，把红队路径、检测规则和复测结论写回威胁模型五下一次演练的触发条件是否有明确的“下一次演练在什么条件下做”触发条件写明（时间、事件或覆盖目标）补充触发条件，不把“每年一次”作为唯一依据示例：检查点一发现红队演练后60天内规则库没有新增或修改。打开表6，发现5条发现中只有1条状态“已关闭”，其余4条停留在“进行中”但没有关闭时限。补录关闭时限和责任人后，下一次检查点二发现C从20%升至75%。七、什么时候做红队、什么时候做紫队、什么时候不做：四条规则和一处矛盾决策规则：规则一：如果威胁模型中有至少3条高评分场景没有对应的检测规则，或过去12个月发生过“威胁模型有、规则有但未触发”的事件，则本次演练采用红队路径验证，目标不是“拿到数据”，是“走通路径并记录检测缺口”；如果上述条件不满足，演练的边际价值下降，资源转向检测规则的日常验证和紫队小范围复测。规则二：如果蓝队具备实时监控和告警能力，且管理层同意在演练期间让蓝队知情，则采用紫队实时交接模式，红队每执行一个可检测动作，蓝队当场回“检测到/未检测到”；如果蓝队不具备实时能力，或演练目的包含测试蓝队的真实盲态反应，则采用半盲或全盲模式，但演练后必须在两周内完成紫队交接和缺口分类，不把全盲模式当作“更真实”的唯一选择。规则三：如果本次演练需要向监管方提交证据（适用TIBER-EU或DORATLPT的场景），演练设计必须对齐外部框架的交付物和时限，紫队协作是强制项，不省略；如果不适用外部框架，演练设计以内部检测缺口为驱动，交付物不额外增加外部框架要求的文档。规则四：如果式(2)的C低于70%，下一次演练不扩大范围（不增加新的攻击路径、不提高目标资产级别），先关闭已有发现；C在70%至90%之间时，可增加一条新的攻击路径或一个次级目标；C高于90%后，可按威胁模型的新增场景正常扩大。矛盾陈述：红队演练越接近真实攻击，蓝队越可能在演练中采取真实响应（隔离主机、封锁账号、启动应急），这些响应会中断红队的路径，使演练无法走完；如果要求蓝队“只观察不响应”，演练又无法验证响应流程在真实压力下的有效性。实质分析：红队演练中蓝队的响应行为本身就是需要被测试的对象之一。红队希望走完路径，蓝队希望演练响应，两者的目标在演练期间不完全一致。TIBER-EU框架在更新中把紫队协作设为强制项，并引入“控制团队”（原白队）来管理演练节奏和冲突消解。控制团队的角色是在红队路径被蓝队响应中断时，判断是“让蓝队继续响应以测试响应流程”，还是“让蓝队暂停以让红队继续走路径”，两者不能在同一时间段内同时测试。权衡规则：按演练目标分配蓝队响应权限。如果本次演练的首要目标是“验证检测覆盖”，蓝队在演练期间的响应权限限定为“记录和通知控制团队”，不执行隔离或封锁；如果首要目标是“验证响应流程”，红队路径走到约定的检测触发点后，蓝队按真实流程响应，红队记录响应时间和效果，不要求走完全程。两个目标可以在同一次演练中分阶段执行，但不在同一阶段同时追求。退路：如果红队路径在演练中被蓝队的非计划响应（例如自动隔离规则触发）意外中断，且该响应不在演练设计范围内，控制团队记录“意外响应”的时间点和动作，演练不重新开始，把该响应作为额外的观察项纳入报告。如果意外响应导致生产受影响，按RoE的中止条件执行，演练终止，恢复生产后再评估是否需要重跑。八、完整版、精简版、极简版按组织成熟度和监管要求选适用TIBER-EU/DORATLPT或需要向监管提交演练证据的组织走完整版；有内部检测团队、威胁模型和基础日志能力的组织走精简版；首次做红队或只有渗透测试经验、检测能力薄弱的组织走极简版。三套版本的差异写在表8。表8三套场景表场景跑什么用哪个公式不能妥协的底线修复后重跑什么完整版表2五项判定、表3五要素、表4试错记录、表5紫队交接、表6产出追踪、表7五项排查式(1)、式(2)RoE书面签署；紫队交接完成；每条发现有关闭时限和复测记录；G和C有数值全量重跑：表7五项、G和C、威胁模型“已验证”字段精简版表2前四项、表3前三要素、表4路线假设和失败点、表5前两项交接、表6前五列、表7前三项式(1)红队路径覆盖威胁模型中至少3条高评分场景；蓝队知晓演练边界；发现有关闭时限只重跑表7前三项和G值极简版表2第一项、表3目标与成功标准、授权边界两项、表4试错记录简化版（只记路线假设和实际结果）、表7第一项不计算G和C，以“是否有检测缺口记录”和“是否有规则修改”替代演练有书面授权；红队至少走通一条威胁模型中的路径并记录检测结果只重跑表7第一项：演练后30天内是否有规则变更或缺口记录完整版适用于有明确监管义务或需要向董事会证明检测能力的组织。精简版去掉紫队的实时复测和式(2)的修复闭环率计算，保留从威胁模型到检测缺口的路径验证。极简版的核心不是完成一次完整红队演练，是先回答两个问题：威胁模型中的路径有没有被实际走过，走完之后有没有任何规则或日志发生变化。完整案例：某安全负责人的第一轮红队演练示例案例，细节为合理设定。起点：威胁模型23条场景，检测规则覆盖17条。过去12个月发生一次横向移动事件，规则存在但未触发。蓝队有SIEM和值守，管理层同意在演练期间让蓝队知情。本次目标不是拿数据，是验证从VPN入口到代码仓库的路径是否被检测。第一轮试错。按威胁模型选定的路径设计脚本：VPN弱口令→堡垒机→代码仓库。红队执行时，VPN登录成功，但堡垒机要求多因素认证，脚本中假设的“凭证传递”不成立。信号：路径在第二步断裂，不是防守方检测到了，是认证控制有效阻止了。当时以为需要换一条“更弱”的堡垒机入口，试了扫描其他管理端口，发现均要求多因素认证。新信息：多因素认证的覆盖范围比脚本假设的更广，凭证传递路径不可行。推翻“堡垒机是薄弱环节”的假设，换路：从办公终端到代码仓库，因为代码仓库可能有硬编码凭据。第二轮试错。转向办公终端路径后，红队通过钓鱼获取了一个办公终端权限，在终端上发现代码仓库的访问凭据。信号：从办公终端到代码仓库的横向动作执行后，蓝队没有告警。紫队交接时蓝队回“无对应规则，代码仓库访问日志未接入SIEM”。当时以为问题是“规则没写”，试了让检测工程补一条规则，补完后红队重放同一动作，告警仍然没有到达。新信息：规则依赖的日志源不存在，补规则不能解决日志缺失。推翻“规则缺失”的假设，换路：缺口分类改为“日志缺失”，先补代码仓库审计日志接入SIEM，再写规则。第三轮试错。补日志和规则后，红队重放横向移动，告警在90秒内到达值守。信号：告警到达了，但值守在演练期间同时收到大量其他告警，横向移动告警被合并到一个低优先级摘要中，没有立即被看到。当时以为“告警到达即完成”，试了不调整优先级，演练复盘时值守说“我看到了摘要，但没有意识到这是演练中的关键动作”。新信息：告警到达不等于告警被有效处理，告警淹没是独立的缺口类型。推翻“告警到达即闭环”的假设，换路：在表6中增加“告警淹没”分类，修复动作是调整优先级和独立通知，复测要求“告警在2分钟内到达值守且未被合并”。第四轮试错。调整告警优先级后，式(1)的G从40%降至20%（15个可检测动作，3个未检测）。式(2)的C在第一次统计时为50%（4条非接受发现，2条通过），主要原因是代码仓库日志接入的关闭时限设为30天，仍在进行中。信号：C低于70%，按规则四下一次演练不扩大范围。当时以为“G已经降了，可以加新路径”，试了在报告里建议下一次增加数据库路径，被管理层问“上一次的日志接入完成了吗”。新信息：检测缺口的修复进度比新增演练场景更重要，C不达标时扩大范围会分散修复资源。推翻“G降即可扩大”的假设，换路：下一次演练的触发条件设为“C达到70%且代码仓库日志接入完成”，不按日历排期。终点：演练执行了15个可检测动作，G从40%降至20%；4条非接受发现中3条复测通过、1条进行中，C=7