文章总结： 文章基于作者十年漏洞检测经验，指出Mythos模型报告的漏洞数量虽多但实际威胁有限。核心观点强调行为检测优于单一漏洞签名追踪，并批判机器学习在入侵检测中因误报率高而实用性差。作者认为长期需关注LLM代理权限和未知攻击面，而非漏洞数量本身。 综合评分： 85 文章分类： 漏洞分析,威胁情报,安全建设,安全运营,技术标准

为什么十年的漏洞检测逻辑编写经验让 Mythos 的漏洞数字显得不那么可怕

signalblur signalblur

securitainment

2026年5月4日 17:11 中国香港

在小说阅读器读本章

去阅读

| 原文链接 | 作者 | | — | — | | https://www.magonia.io/research/why-a-decade-of-writing-detection-logic-makes-the-mythos-exploit-numbers-less-scary/ | signalblur |

Anthropic 的营销团队一直在为其新的 Mythos 网络安全模型以及它发现的漏洞数量造势。Mozilla 方面表示，这些发现看起来确有其事。如果短期内这种节奏持续下去，行业内外的许多人都有理由感到担忧，并怀疑这是否会成为新的常态。

作为一名为网络安全厂商编写检测逻辑近十年的人，我认为这些数字远没有看起来那么吓人，也不至于”世界末日”。我管理过的安全运营中心 ( SOC ) 曾长期对抗国家级攻击者，我们团队还因此为所在组织赢得了美国国防反情报局颁发的 Cogswell 奖。我曾在一家财富 100 强公司负责大多数工程师从未有机会接触的那种企业级规模的检测工作，并发布了业界首份关于”检测即代码”的公开白皮书。说这些是想表明，我在这行已经干了相当长一段时间。尽管像 Mythos 这类模型在短期内带来的冲击确实不小，但我同样相信，实际情况远没有外界渲染得那么糟糕。

新漏洞利用的发布速度一直远超防御方编写检测规则的能力

编写检测规则向来是一场”打地鼠”。David Bianco 的《痛苦金字塔》——我们行业奠基性的论述之一——讲的就是这个观点。防御者更应依赖行为检测，而不是单一的入侵指标 ( IoC ) 或具体漏洞利用，因为新漏洞利用的披露速度一直跑在防御方编写规则的能力之前。逐个为漏洞利用编写覆盖规则，并不是检测工程师投入主要精力的地方。这件事还是有人在做的。ET Open 规则集就能让我们直观看到，针对历史 CVE 究竟存在多少条独立规则。规则通常只会针对重大漏洞、任何被积极用于攻击你所在行业的漏洞，以及少数几类自动化能以低成本搞定的场景来编写。

攻击者无需零日漏洞亦可达成目标

威胁行为者并不需要零日漏洞就能拿下目标。几十年来，旧的漏洞利用一直工作得很好。如今最普遍的初始访问手法之一 ClickFix 完全不依赖零日漏洞，而是诱使用户把恶意代码粘贴到 PowerShell 或 Run 对话框中自行执行。

检测逻辑与漏洞利用并非一一对应

对于从未写过检测逻辑的人，我最喜欢用 Microsoft Office 中的远程代码执行 ( RCE ) 漏洞来举例，以说明为什么基于行为的检测要优于针对单个漏洞利用和 IoC 的签名式追踪。Word、Excel 等 Office 产品在过去二十年里贡献了业界一些影响最大、被滥用最多的漏洞，不重复计算的 RCE 类 CVE 已超过 1,000 个，并且还在继续增加。

尽管这些漏洞数量众多、危害严重，但检测其滥用行为其实比想象中容易得多。例如，Microsoft 在 2022 年修改了默认设置：从互联网到达、带有 Web 标记 ( MOTW ) 的 Office 文档将不再直接运行宏，而是需要用户右键点击文档并选择”解除锁定 ( Unblock )”，或者在 PowerShell 中运行 Unblock-File。有人可能会认为这属于漏洞利用缓解或系统加固，而非检测，但我不这么看。从检测工程师的角度，在 Microsoft 推出该改动之前，我完全可以为同样的行为写一个自定义检测器。而在该改动落地之后，基于宏的恶意文档投递量出现了大幅下降。

再加上现代 EDR 工具让行为画像变得简单，你就能针对诸如”Office 文档派生子进程”这类行为建立基线与检测规则——这是 Office 文档在执行代码时的标志性动作。与前述行为类似，这一举措极大地削弱了威胁行为者通过 Office 文档成功执行代码的能力，无论使用的是哪一种具体漏洞利用。

把这两类行为叠加起来，成功执行代码的难度就会呈指数级上升。在此之上你还可以再叠加更多行为，例如 PowerShell 执行一个从网络下载的 .ps1文件。作为检测工程师，我的工作就是叠加足够多的行为，使得当其中一项触发时，其他行为可以提高”这确实是恶意操作”的置信度——通常的做法是把它们绑到风险告警 ( Risk-Based Alerting ) 模型中的分数上，每多命中一项检测，恶意活动的累积可能性就再上一层。

机器学习与异常检测大概不是答案

各组织正因头条新闻一片”蓝队天塌了”而匆忙应对，成熟的检测团队也不例外。大多数团队都在琢磨怎么从单个的行为检测器过渡到基于机器学习的模型。我认为这是个错误，而且有研究可以佐证。

早在当前的 AI 浪潮之前，安全研究界就有两篇论文系统地反对了基于 ML 的入侵检测 ( 任何在 SOC 干过的人都不需要论文也能知道这一点 )：

• Robin Sommer 与 Vern Paxson 的《Outside the Closed World: On Using Machine Learning for Network Intrusion Detection》
• Stefan Axelsson 的《The Base-Rate Fallacy and the Difficulty of Intrusion Detection》

Sommer 和 Paxson 的批评有五条，但真正重要的只有三条。

第一条是 ML 擅长分类，即判断一个输入属于若干已知类别中的哪一个。异常检测则把问题反了过来：你在良性流量上训练，然后让系统标出所有不符合的情况。他们引用的教科书把这叫作 _封闭世界假设_，并直白地指出，这在现实问题中并没有多大用处。垃圾邮件分类有效，是因为垃圾邮件和正常邮件都可以拿来训练；推荐系统有效，是因为它们呈现的本来就是相似的内容，而不是新颖的内容。网络入侵检测属于反过来的那一类问题。

第二条是 网络流量的多样性。真实流量是重尾的、突发的，在所有运维上重要的时间尺度上都是变化的。根本不存在一个稳定的”正常”状态供你学习。一个三月份表现尚可的模型，到六月份就会开始漂移，因为应用组合换了、人员流动了、新的 SaaS 上线了，或者某个重大节假日改变了用户行为。这种漂移会推高误报率，而 Axelsson 告诉我们：误报率正是绝对不能任其升高的那个指标。

第三条就是他们所说的 语义鸿沟。即使异常检测器把某件事标对了，它也只是告诉分析师 “这是一个 异常事件”，而不是它是 _恶意的_、也不是它打算做什么、更不是该如何处置。分析师仍然要自己去判断这个不寻常事件到底重不重要。在真实的 SOC 中，这部分判断工作就是瓶颈。

如果你打算在这个领域用 ML，Sommer 和 Paxson 也给出了几条把它用好的实操建议。

他们的第一条建议——也是我会摆在最前面的一条——是 真正搞清楚系统在做什么。PEAK 威胁狩猎框架以结构化的方式开展威胁狩猎，既能帮你形成这种理解，也能帮你把它记录下来。

他们的第二条建议是把范围尽量收得 窄一些。不要让模型去检测笼统的”攻击”，而是让它检测一个具体、定义明确的活动。

第三条建议常常被忽视。他们认为，机器学习往往作为 特征发现工具比作为检测器本身更有用。意思是，你用 ML 找出在良性流量与恶意流量中信号最强的特征，再在这些特征之上构建一个非 ML 的检测器。

另外有一点也很相关——他们引用的那篇基础率谬误论文：

“在入侵检测中，任何错误分类的相对成本都比许多其他机器学习应用高得多。一次误报意味着昂贵的分析师时间被花在排查报告事件上，最终却发现它对应的是良性的底层活动。正如 Axelsson 所论证的，即便是非常小的误报率，也会迅速让 NIDS 变得不可用。”

在我看来，这篇论文是检测工程师的必读材料。要弄明白它为什么会得出这个结论，我们用一个易懂的例子来拆解一下。

注意：就本文而言，真阳性指的是任何最终查到恶意结果的调查，假阳性则是任何对应良性活动的调查。不过，我建议在安全监控里避免使用二元的真/假阳性框架。

设想一个小型环境，每天产生一百万条事件，其中真正发生的入侵每天有两次。假设每次入侵会产出十条事件，即一百万条事件中有二十条入侵相关事件。任意一条事件属于入侵的概率为 20 / 1,000,000 = 0.00002。正是这个微小的概率，让 误报率成为衡量检测逻辑是否有效时最重要的那个指标。

检测率与误报率经常被混淆，被当成互为反面的两个概念，其实并非如此。检测率是真阳性除以实际发生的入侵事件数，误报率则是假阳性除以实际的良性事件数。这两个数字可以独立变化。误报率最终之所以占主导，并不是因为它在某种抽象意义上更重要，而是因为良性样本的数量大约是入侵样本的 50,000倍。哪怕检测率拉到完美，也只能拿下二十次命中，因为可命中的入侵事件总共就只有二十条。一个 0.001的误报率却能产出一千次误报，因为可触发的良性事件接近一百万条。_误报率被乘上了一个比检测率大得多的数字。_

那么真阳性率 ( TPR ) 的算法是：TPR = TP / 实际入侵事件。代入我们的例子，20/ 20= 1.0( 完美检测器抓到了全部 20 条入侵事件 )。

误报率 ( FPR ) 的算法是 FPR = FP / 实际良性事件。代入我们的例子，FPR是 0.001：1,000/ 999,980≈ 0.001。

当检测率是 1.0( 完美检测器 )、误报率是 0.00001时，你能把全部二十条入侵事件都抓为真阳性。同时，你还会在良性流量上扔出大约十次误报，因为 1,000,000 × 0.00001 = 10。三十条警报里有二十条是真的，贝叶斯检测率约为 66%。

把误报率提到 0.001( 这个数字写在纸面上还挺像样 )，警报队列就直接炸了。二十条真阳性纹丝不动，但误报数飙到 1,000,000 × 0.001 = 1,000。一共 1,020条警报里有二十条是真的，大约 2%。

这个 2%比看上去更残忍。2%是分析师队列里任意一条警报真的属于一次入侵的概率，而不是 “2%的入侵被检测到了”。两次入侵在技术上都进了警报队列，在完美检测率下，你会为每次入侵至少触发一条事件。

问题在于，分析师没法在不一一查看的情况下，从 1,020 条警报里挑出那二十条真的。他们要在一千条误报里淘出那二十条真警报。每条警报的可信度都太低，即便入侵确实被检出了，也不足以据此采取行动。

分析师只用一周就学会了无视这个系统。所以，致命的从来不是检测率，_而是误报率。_

行为检测的漂移更小

一条范围圈得好的行为规则，瞄准的是”没有任何合理业务用途”的行为，而”没有任何合理业务用途”是一个几乎不会漂移的属性。winword.exe派生 powershell.exe是我反复回到的那个例子。几乎没有哪个业务流程需要 Word 去启动一个脚本解释器。这一点放在 2014 年的医院网络上成立，放在 2026 年的律所上同样成立。流量翻倍、员工远程办公、新的 SaaS 上线，这条规则的误报率几乎都不会动。这些变化都不会催生 winword.exe → powershell.exe这种组合。

这就是一条规则如何把误报率压到 Axelsson 数学要求的那个量级附近，并稳稳停在那里。检测器并不是在从当前流量中学习什么算正常，而是在定义系统的某个结构性事实。ML 异常检测就没有这个性质。它的”正常”只是训练时那一刻流量的快照，环境一变，误报率就会飙升——并不是发生了什么恶意活动，而仅仅是基线动了。每一次漂移都意味着又要重训一次，每一次重训都是一次拉高 FPR 的机会。

防御者同样握有 AI/LLM……

防御者也能用上同样的模型。就像漏洞开发者用它们去找零日，蓝队也在用它们识别新行为，并以快得多的速度处理积压下来的行为研究。如前所述，检测和漏洞利用并非一一对应，即便对零日漏洞也是如此。

虽然我一直对异常检测和 ML 在检测工程中的使用持批评态度，但它 确实有自己的位置。正如 Sommer 和 Paxson 的论文所指出的，只要瞄准具体、范围明确的使用场景，它是能发挥作用的。这并不是”要么用 AI/ML、要么用行为”的二元选择，而是两者并用。

我对 LLM 真正担心的不是漏洞利用的激增

我对 LLM 最大的担忧并不是新漏洞利用的激增，而是那些尚未被充分理解的攻击面在增加，以及这些代理被授予的访问权限。我同样担心 AI 代理会让异常检测系统更容易出现误报——它们本质上就是非确定性的。

举个例子，以后非技术岗位的人开始使用这些代理，大概会变成新常态。如果会计部门的某位员工被提示注入攻击，代理被指示用该用户合法的浏览器 cookie 发起一笔电汇，这事就会变得很难检测。而由于真正执行任务的不是用户本人，他甚至可能根本不知道事情发生了，也就无从向安全团队说明这是不是有意为之。

总结 / TL;DR

短期内，我认为漏洞利用可得性的提升会对防御方造成负面影响，而行业和防御工具则会一边追赶。大多数组织还在摸索如何把 LLM 用到检测里，而那通常远比开发漏洞利用要曲折——环境多变且差异巨大，高质量训练数据也难以获取。

长期来看，我认为新漏洞利用与新检测之间的差距会逐渐拉平，虽然这种关系从一开始就不是 1:1。我真正担心的不是漏洞利用的数量，而是这些代理被授予的访问权限，以及它们引入的攻击面至今仍未被充分理解这件事。

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

免责声明：

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

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

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

本文转载自：securitainment signalblur signalblur《为什么十年的漏洞检测逻辑编写经验让 Mythos 的漏洞数字显得不那么可怕》