红蓝对抗不是零和博弈：技能互通与攻防一体闭环落地指南

开头先讲一个我印象特别深的场景。前年一次年度实战攻防演练结束后的复盘会上，红队负责人一脸笃定地说：“我们从边界打入内网只花了四小时，中间用了三个你们完全没有覆盖的手法。”蓝队负责人脸色不太好看，回了一句：“你们只管打，打完了拍拍屁股走人，留下的烂摊子和日志排查全是我们的事。”两边话赶话，会议室里火药味十足。

那次复盘我全程在场，心里很清楚两边其实都不算错，但问题恰恰出在这个“不算错”上。红队的目标是把攻击链打完整，证明系统存在漏洞；蓝队的目标是把所有异常都拦住、拦不住也要快速发现。目标被定义成了“你赢我输”的对立关系，红蓝对抗自然就被架到了零和博弈的位置上。但做安全做得越久我越确认一件事：红队和蓝队根本不是天然对立的两个阵营，他们的技能、思路、工具往往只是同一枚硬币的两面。真正高效的团队，早就开始把红蓝技能互通当作核心能力来建设，最终形成一个攻防一体的安全闭环，而不是年年重复“你攻我守、打完拉倒”的循环。

这篇文章我想把我这几年的实际经验和思考完整展开，聊清楚红蓝对抗为什么不是零和博弈、红蓝技能具体怎么互通、攻防一体闭环应该怎么搭。不搞虚的，全是我在项目中摔打过的结论。

1. 红蓝对抗为何总被当成零和博弈：三种典型误解的根源

红蓝对抗被误读成零和博弈，不是一天两天形成的。从我的观察来看，根源基本可以归结为三类结构性误解。不把这些根源挖干净，后面谈技能互通、攻防闭环都是空中楼阁。

1.1 考核指标先天对立，导致组织动作变形

绝大多数企业的红蓝对抗演练，评价维度就那么几项：红队看的是“有没有突破进去”“横向移动了多少台机器”“拿到什么级别的权限”；蓝队看的是“有没有发现”“有没有阻断”“响应时间多长”。这两个指标放在一起，天然就是对抗关系——红队突破成功，意味着蓝队防御失败；红队作业时间越久，蓝队监测盲区暴露得越多。

我见过不少安全团队，为了在演练中拿一个好成绩，会专门针对红队常见打法“开小灶”。比如提前把某个端口的访问日志打开，或者针对某种已知攻击工具的特征码做额外匹配。这样做的确能在评分表上好看一点，但真实的安全水位并没有实质提升。更麻烦的是，这套“应试”逻辑会让红队也觉得没意思，于是红队开始钻研更偏门的手法、更冷门的漏洞利用链，两边在互相猜忌中越走越远。

问题的关键在于，演练目标一开始就设置错了。演练最该问的问题不是“谁赢了”，而是“我们暴露了哪些弱点，这些弱点以后怎么才能不暴露”。指标如果只关心胜负，所有人都会顺着指标去做事，零和博弈的心态就是这么被诱导出来的。

1.2 汇报口径只讲差距，不讲共同成长

复盘会几乎是红蓝对抗的标配环节。但我参加过的大量复盘会，连内容结构都惊人地相似：红队列攻击路径、蓝队列监测记录，最后统一汇总成一张PPT，红色的代表被攻破的环节，绿色代表成功拦截的环节，一张红绿相间的图往上一放就结束了。

这样的复盘看起来信息量很大，实际上啥也没沉淀。红队不会告诉你他构造某个payload时是怎么绕过的现有安全产品，蓝队也不会承认自己哪个检测规则平时根本没维护、到演练期间才被临时拉出来充数。大家讲出来的都是“我愿意让你看到的”，不是“真正对我有价值的信息”。两边的知识库、工具集、经验教训完全没有打通，安全团队只是把一次对抗做成了“汇报材料生成器”，对整个组织的安全能力建设贡献极为有限。

1.3 工具链和知识库割裂，形成两个“平行世界”

我之前接触过一个企业的安全团队，红队用的是一套沉甸甸的攻击工具框架，蓝队用的是另一套监听类的监测平台，两边工具几乎没有任何数据交换。红队把探测结果存在自己的本子上，蓝队收集的流量日志则全部沉淀在日志平台里。同一个内网环境，红队和蓝队的视角完全割裂：红队知道哪个机器存在弱口令，蓝队却只在演练复盘时才知道那个弱口令对应的IP；蓝队发现过可疑的横向连接，红队却不知道这条线索可以帮自己少走很多弯路。

这种割裂大概是“零和博弈”认知最深层的来源——工具和知识库的隔离让红队和蓝队看起来在做完全不同的工作内容，于是大家自然而然地认为这是在比赛谁更强，而不是在做同一件事。

但真实的安全工作根本不是这样的。红队在攻击中发现的每一个利用路径，本质上都是一条“蓝队未来必须监测的线索”；蓝队在日志里看到的每一个可疑行为，本质上都是“红队下一次攻击可能利用的手法”。两边掌握的信息互相印证、互相补充，才是攻防一体的底层逻辑。打通这些信息流，就是红蓝技能互通的第一步。

2. 红队与蓝队的技能互通点：六组典型映射与三个复用案例

总说“红蓝技能互通”，很多人的第一反应是“让红队的人去干蓝队的活，或者反过来”，这是很粗糙的误解。实际上技能互通的核心是识别出“同一项底层能力在不同场景下的两种表现”，然后让这两种表现相互增益。我在实际项目里总结了一张红蓝技能映射表，基本能覆盖大多数企业的核心安全场景，这里直接分享出来。

这张表看着简单，但真正执行起来，每一个映射背后都是实打实的技能复用。我挑三个典型案例展开讲。

2.1 权限维持手法直接变成检测规则素材

红队最常见的权限维持手段，无非是注册表自启动项、计划任务、服务植入、启动文件夹之类的持久化机制。红队会想尽办法让这些机制更隐蔽，比如用合法签名进程侧加载、用WMI事件订阅做无文件持久化。这些手法我不会教你具体怎么免杀，但我想说，恰好是这些“攻击视角”的探索，能让蓝队的检测规则库变得异常丰富。

我在一个项目里做过一个很直接的验证：把过去12个月内红队用过的全部权限维持手法列成清单，逐一比对蓝队已有的检测规则，结果发现覆盖率不到40%，也就是说超过一半的手法蓝队压根没有对应的监测能力。后来蓝队根据这条清单补齐了规则，到下一轮演练时，红队想再通过老路径维持权限就变得非常困难，反而逼着红队去开发新手法。这个过程就是典型的红蓝技能互相增益——红队研究得越深，蓝队防线越厚；蓝队防得越严，红队技术上突破得越深。

2.2 钓鱼攻击的经验直接反哺人的防御

有一次红队做钓鱼演练，精心构造了一封仿冒企业内部系统的通知信，信里嵌的链接指向一个做了伪装的登录页面。结果令人意外：超过30%的员工点了链接并输入了账号密码。这个数字让管理层很震惊，但更值得关注的是蓝队和红队合作复盘后做的事。

他们把钓鱼邮件的完整特征提炼成一套识别规则，交给邮件网关团队，同时把真实案例改编成了日常安全意识培训的素材。下一次演练时，虽然点击率依然存在，但上报率显著提高——员工开始主动向安全团队举报可疑邮件。这就是把红队的攻击武器“反向利用”成了防御体系的一部分。类似的逻辑也适用于“怎么让钓鱼邮件更容易被识破”—这不是帮攻击者，而是帮防御者理解攻击者思路，从而建立更强的第一道防线。

2.3 内网横移路径成为东西向监测的模型输入

红队在内网横移的时候，通常会利用SMB共享、远程服务创建、WinRM远程管理通道等手段。这些行为在流量侧并不难识别，难的是如何在海量日常运维行为中精准区分“攻击者的横移”和“管理员正常操作”。红队在这方面的认知恰好极有价值：他们最清楚哪些横移路径是“默认没被监控”的暗角。

我一贯的建议是，内网横移技能互通不需要等到演练时才做，可以在演练过程中同步进行。红队每走一步横移，就在协作群里同步一步详细路径和手法。蓝队的人当场就能在现有监测系统里查一下“这个行为我们能不能看到”，看不到的立刻记录。等演练结束，这批记录就是一份高质量检测规则需求清单，比蓝队自己闭门造车高效太多。

3. 从红队攻击链反推蓝队检测规则：一套可落地的映射方法论

光有技能映射还不够，落到实操层面，最核心的一项能力是“把红队的攻击路径翻译成蓝队的检测规则”。这不是靠感觉就能做的事，需要一套清晰、可复制的方法论。我在这套方法论上吃过不少亏，花了大半年才调整到比较顺的状态，现在把完整流程分享出来。

3.1 第一步：用统一语言描述红队攻击链

红队的攻击路径报告如果写得不清不楚，蓝队基本没法用。最常见的情况是红队报“通过XX漏洞拿到www服务器权限，然后横向到办公网一台PC，最后抓取到域管哈希”。这句话信息量远远不够——你要重新检测这个手法，至少还得知道具体用了什么工具、什么命令、落在哪个进程、产生了什么网络连接。

解决办法是引入统一的攻击描述语言做支撑。我个人最常用的是MITRE ATT&CK框架，它把攻击行为拆成了战术、技术、子技术三级结构，红队在报告时按照这个框架标注每一步对应编号，蓝队拿到报告后就能直接检索对应的检测点。比如“利用Web服务漏洞上传Webshell”对应T1505.003，“通过SMB进行横向移动”对应T1021.002。有了这套共同语言，红蓝双方沟通效率至少提升一倍。

3.2 第二步：建立“攻击步骤→检测点→检测逻辑”三级映射表

拿到红队的攻击链描述后，蓝队要做的事情不是立刻写规则，而是先建立一张三级映射表，把每一步攻击动作翻译成“在检测数据源里具体长什么样”。

我整理一个实际案例。有一次红队通过Tomcat后台弱口令上传了Webshell，之后用Webshell执行了系统命令，通过certutil下载了后续工具。整个攻击链拆成三步，对应的检测逻辑分别如下：

看到没有，这个映射表把红队的攻击语言翻译成了蓝队的监测语言。红队说“我上传了木马文件”，蓝队需要关心的是“Java进程为什么突然创建了命令行子进程”。双方描述的是同一件事，但视角完全不同。映射表的作用就是让这两种视角顺畅对接。

3.3 第三步：生成检测用例并用历史数据验证

映射表有了，就可以生成具体的检测用例了。针对上面的例子，检测用例可以是一段简单的规则代码，也可以在SIEM平台里直接用查询语句实现。这里给一个实际能用的事件查询示例：

-- 检测: Web服务进程派生异常命令行子进程 -- 数据源: EDR资产进程事件表 SELECT p1.pid, p1.process_name AS parent_process, p1.cmdline AS parent_cmdline, p2.pid AS child_pid, p2.process_name AS child_process, p2.cmdline AS child_cmdline, p2.username, p2.hostname, p2.create_time FROM process_events p1 JOIN process_events p2 ON p1.pid = p2.parent_pid WHERE p1.process_name IN ('java.exe', 'tomcat.exe', 'nginx.exe', 'httpd.exe') AND p2.process_name IN ('cmd.exe', 'powershell.exe', 'wscript.exe', 'cscript.exe') AND p2.create_time >= NOW() - INTERVAL 24 HOUR ORDER BY p2.create_time DESC

这段SQL的思路很简单：先找出Web服务进程，再找出由它直接派生的命令行子进程。如果平时没有运维人员会通过Web服务进程去启动命令行，那么这类进程父子关系就是严重可疑信号。规则写完之后不能直接上线，要拉取最近7到30天的历史数据做验证，看看有没有误报。如果历史数据里经常出现合法运维操作命中了规则，就要增加补充条件，比如排除特定白名单机器、排除特定运维账号。

这个流程走完，一条检测规则才算完整落地。我在实际项目中，一条中等复杂度的规则从红队报告里提取出来、完成历史数据验证到上线，大约需要两个小时。而传统方式下蓝队闭门造车，可能两三天都不一定写出贴合真实攻击手法的规则。

4. 打造攻防一体闭环的四步落地流程：从演练到沉淀再到验证

技能互通的最终目标，是形成一个可持续运转的攻防一体闭环。闭环不等于“把演练办得更好”，而是让每一次红蓝对抗的产出都能沉淀到安全建设中，并在下一轮对抗里生效。我一般把闭环拆成四个阶段。

4.1 战前：红蓝共享攻击面与剧本库

大多数企业的演练筹备阶段，红队和蓝队是各忙各的。红队忙着收集目标信息、琢磨入口方案，蓝队忙着加固重点系统、优化检测规则，两边都不主动跟对方对齐信息。攻防一体闭环的第一条原则就是打破这个状态。

具体做法是，演练开始前一周，红蓝双方坐在一起开一次“战前对齐会”。红队在会上说明本次演练的行动原则、计划使用的攻击方向大类和需要规避的敏感业务系统（比如生产核心库不允许实际破坏）。蓝队则向红队说明当前已有的防护能力范围，哪些资产有重点监控、哪些暂时还处于“裸奔”状态。这个会议的目的不是让蓝队提前加固堵住红队的路，而是确保红队的操作不会造成真实业务损失，同时让蓝队明确自己的监测盲区，带着问题去守。

我在实际项目里发现，战前对齐还能顺带解决一个常见矛盾——红队不敢用真实业务账号去做验证，怕弄坏数据；蓝队不了解红队的攻击条件，以为某个系统很安全。两边信息一碰，很多矛盾就化解了。

4.2 战中：建立“进攻发现→实时同步→即时验证”通道

传统红蓝对抗里，红队发现了新的攻击路径，通常会藏着掖着，直到复盘才公布。这样看起来对抗性很足，但对安全能力建设几乎零贡献。攻防一体闭环要求改变这个模式：红队每发现一个值得记录的突破点，就在约定好的安全协作群里做一次简短同步，包含本次手法的攻击步骤、涉及的技术要点、潜在风险面三个要素。

蓝队值班人员收到同步信息后，当场做两件事：第一，查看现有监测系统能不能看到这个行为，看不到就立刻提工单记录；第二，在靶场环境里快速验证这条路径是否真实可复现，验证结果同步给红队，帮红队判断这条路径是否值得继续投入精力。

有读者可能会问，这样做红队不就丧失优势了吗？其实不会。红队的核心价值是发现“系统里真实存在的可被利用路径”，而不是“在蓝队完全不知情的情况下悄悄进来”。提前同步给蓝队，只是把单次对抗的“惊喜感”，转化成了组织安全能力的“提升量”，这对双方的价值都更大。

4.3 战后：将攻击路径沉淀为“三件套”交付物

演练结束不等于安全建设结束。在我主导的项目里，每一次红蓝对抗结束后，红队都必须产出“三件套”交付物，缺一不可：

1. 攻击路径报告：详细记录从信息收集到最终达成目标的完整路径，每步对应MITRE ATT&CK编号，附带时间线和涉及IP。
2. 检测规则清单：针对攻击路径里每个关键步骤，给出建议的检测逻辑或具体规则。如果已经在战中通过映射方法生成，此处直接整理归档即可。
3. 防护策略建议：除了检测，还要说明每步攻击如何通过补丁、配置加固、暴露面收敛等手段从源头阻断。

这三份东西由红队负责产出，蓝队负责验证可行性，安全负责人负责推动落地。交付物经评审后统一进入企业的安全知识库，作为下一轮演练和日常监测的参考依据。

4.4 常态：用互训和靶场演练保持技能互通

红蓝技能互通最大的敌人是时间。演练结束两三个月后，新发现的攻击手法慢慢淡忘，检测规则也逐渐失去维护，技能互通就名存实亡了。要维持效果，必须把互通变成常态机制，而不是一年一次的活动。

我采用过且效果最好的方式是月度攻防实训。具体做法是：在靶场环境里构造一个包含常见漏洞的仿真内网，红队负责在这个环境里设计新的攻击剧本，蓝队负责在同样的环境里设计检测方案。每隔一个月，两边角色互换——让蓝队去攻一次，让红队来守一次。这种身份互换带来的认知冲击远超讲课培训：一朝做过红队的横向移动，以后做蓝队时自然知道横移流量长什么样；反过来，守过一轮才知道哪些细节对检测来说至关重要。

5. 红蓝一体化落地时最容易踩的五个坑：我都替你趟过了

攻防一体闭环从理念到落地，中间隔着不少坑。很多安全团队不是不懂这个道理，是一动手就撞上各种现实问题。这五个坑是我和团队在实际项目中一一踩过、又一一填平的，写出来帮大家少走弯路。

5.1 坑一：红队报告只写“打通了”，不写“怎么打通的”

这是我在实战中遇到频率最高的问题。红队写报告时习惯性聚焦结果——“通过XX系统漏洞获取权限”“利用弱口令进入内网”，但在检测规则落地时，这些描述几乎等于无效信息。蓝队需要的不是结果，而是过程：具体是哪个进程执行了什么命令，哪个端口访问了哪个IP，哪个文件被落地到了哪个目录。

规避方法是把攻击路径报告模板标准化，强制要求红队按固定格式填写，包含时间线、行为层级、涉及实体、工具指纹等字段。一开始红队会觉得麻烦，但坚持两三轮之后，双方都会尝到甜头——红队不再需要在复盘会上一遍遍口头解释，蓝队也不需要靠猜漏洞去写规则。

5.2 坑二：检测规则一上来就追求全覆盖，结果误报爆炸

有些蓝队拿到红队攻击链路后，恨不得把每个步骤都立刻写成检测规则，而且条件写得特别宽。结果就是规则上线第一天告警就刷屏，安全运营人员被海量误报淹没，最后不得不把所有规则全部下线，一夜回到解放前。

正确做法是严守“检测逻辑验证三步法”：先拿历史数据验证、再设置观察期观察真实告警量、最后根据反馈逐步收敛条件。比如一个Web进程派生命令行的规则，可以先只对核心业务服务器生效，等30天确认误报率可控后，再扩展到全量资产。先窄后宽，永远比一上来就想全覆盖稳得多。

5.3 坑三：红队产出和漏洞管理流程脱节，修补不闭环

红队在演练中发现的漏洞，往往只在安全团队内部流转一下，不会正式进入企业的漏洞管理工单体系。结果就是：红队下次演练时发现同一个漏洞还在，蓝队也早就忘了这个漏洞。整个安全工作困在“发现—遗忘—再发现”的循环里。

这一点必须拉通。具体做法是给红队授予直接提交漏洞工单的权限，红队发现的高风险问题必须按漏洞管理流程分配责任人、设定修复期限、跟踪修复进度。这样一来，红队不只是“找问题的人”，更是企业漏洞生命周期管理的重要输入源。

5.4 坑四：互训变成“红队讲课，蓝队听课”，没有实战交互

很多企业组织的红蓝技能培训，形式是红队做一个PPT向蓝队讲课，蓝队的同学们坐在下面听，偶尔拍照发个群。这种培训效果有限，因为攻击手法的掌握是高度实操性的，看十遍PPT不如在真实环境里做一遍攻防交互。

更好的形式是“对抗式互训”：用统一的靶场环境，红队与蓝队混合编组、角色互换，让每个人都在攻防两端实操一遍。我刚推这个机制时也有阻力——红队觉得蓝队水平不行耽误时间，蓝队觉得自己不懂攻击不敢动手。但坚持三个月后，双方对彼此工作难点的理解程度明显提升，协作时的沟通成本大幅度下降。

5.5 坑五：复盘会开完，产出存网盘吃灰

最后一个坑最具隐蔽性。有些团队在复盘会上讨论得热火朝天，产出物也整理好了，最后却被统一放进了共享网盘里一个名为“2024年攻防演练复盘”的文件夹，之后就再也没人打开过。

防止产出吃灰，核心机制只有一个：每一个产出都必须绑定一条“可跟踪的动作”。检测规则绑定到规则库更新任务，漏洞清单绑定到工单系统的修复任务，攻击路径报告绑定到知识库的文档审核任务。凡是不能绑定动作的产出，宁可不要，因为它只会制造“我们做了很多工作”的假象。

我在实际项目里专门安排了一个“产出追踪表”，记录每一条产出对应的负责人、验收人、完成时限和当前状态，每周同步一次进度。可能有人觉得这是小题大做，但真正推行之后会发现，产出的落地率提升了不止一倍。

最后再分享一点个人体会。做了这么多年安全建设，我越来越觉得，红蓝对抗的价值从来不在于证明谁比谁强，而在于让团队以最低成本暴露问题、用最快速度补齐短板。红蓝技能互通也不是什么高深的理论，它的本质无非是“让攻击者的经验为防御者所用，让防御者的认知为攻击者导航”。把这条链路走通、走稳，攻防一体的安全闭环自然就能实现。

如果你所在团队目前还在为“红蓝对抗到底谁赢了”争得不可开交，不妨试试先从一次战前对齐会开始，从红队报告模板的调整开始。很多转变不需要等什么大工程，一个人推一把，就能转动整个轮子。