515种绕过方法全部失败，9类攻击却成功了：LLM安全防护到底漏掉了什么？

安全牛

2026年10月20日 11:33
北京

去阅读

点击蓝字 关注我们

当大语言模型的安全防护能挡住几百种攻击时，我们是不是就可以放心了？

CrowdStrike最近的一项研究给出了一个意外的答案：他们测试了大约515种直接绕过技术，全都没成功。但当他们换个思路，把有害任务拆成几个看起来正常的软件开发请求，再用另一个没装安全分类器的模型把结果拼起来，情况就变了。

在10类攻击场景的测试中，有9类成功生成了可以运行的攻击代码。

这说明什么？安全分类器能准确识别单个请求有没有问题，但对于多个合法请求组合后产生的危险能力，就不一定能看出来了。

为什么强大的分类器还是有盲区？

现在的先进大语言模型通常会配备独立的安全分类器，在用户请求进来时做实时检查。这就像在用户和模型之间设了一道安全检查站，一旦发现有害内容就直接拦下来。

CrowdStrike的研究先验证了这道防线确实很强。

他们针对受高级安全分类器保护的前沿模型（包括Claude Opus 5.5、Fable 5等），测试了大约515种不同的绕过技术——编码变换、心理操纵、多轮对话升级、Unicode技巧，还有24种受认知科学启发的新方法。

结果？成功率0%。

但问题来了：分类器的有效性和整个AI系统的安全性，不是一回事。

传统分类器主要看单次请求，但真实攻击任务可能有多个步骤。每个步骤单独看都挺正常，有合法用途，但组合起来就可能形成完整的攻击能力。如果请求之间的关联关系不在分类器的观察范围内，即使每个请求都被正确判断了，系统也无法保证最终结果安全。

关键是，这个风险不是因为分类器判断错了，而是因为多个安全片段的组合过程发生在分类器看不到的地方。

技术原理：拆解、重述、重组

研究团队把这个技术流程总结为三步：任务拆解 → 良性重述 → 结果重组

整个流程涉及三个角色：任务编排器、受保护的前沿模型A、没装分类器的小模型B。

第一步：任务拆解

把原本有攻击目的的复杂任务，拆成多个独立的软件开发子任务。这些子任务涉及的技术能力在正常软件开发中也会用到，比如进程管理、内存操作、运行时代码生成等。

单独看某个技术请求，分类器很难判断它到底是不是恶意的。

第二步：良性重述

把各个子任务放进合理的软件工程场景，比如游戏修改、安全检测、合法软件开发。然后让受保护的前沿模型A来处理这些请求。

因为这些场景确实需要用到相关的底层能力，所以模型A会在安全分类器允许的范围内，正常输出技术内容。

第三步：结果重组

最后由没装相同安全分类器的小模型B，把前沿模型输出的技术片段整合起来，形成完整的攻击代码。

前沿模型A负责提供专业知识和准确实现，小模型B负责最终整合。整个流程就这样绕开了单次请求安全审查的保护边界。

研究团队还指出，免费API加上本地开源模型的组合，已经能以较低成本运行这样的流程。

三类典型场景：正常需求如何变成攻击载体？

研究验证了三类软件工程场景，都能作为良性重述的载体。

场景一：游戏修改

游戏修改和游戏开发中，经常需要读取进程信息、访问内存、修改运行状态。这些能力在技术层面和某些Windows进程操作有交集。

研究人员用游戏修改相关的正常需求做测试，获得了跨进程写入、进程句柄管理、内存保护属性修改、远程线程创建等技术内容。测试结果：18次请求全部通过，通过率100%。

场景二：安全检测工程

安全工程师写检测规则时，需要了解漏洞利用可能涉及的行为、API调用、访问特征。所以检测研究和攻击技术分析在知识层面是重叠的。

研究人员以编写Sigma检测规则等防御任务为背景测试。比如CVE-2021-34527的检测规则编写，通过了安全检查，得到17,127个字符的输出，里面包含与漏洞利用机制相关的技术信息。

场景三：合法软件开发

研究展示了即时编译器（JIT Compiler）开发的例子，涉及运行时生成x86代码等功能，需要可执行内存分配、代码写入、执行控制转移等底层操作。

这个示例也通过了分类器检查，返回了4,158个字符的内容。

这三个案例说明：游戏开发、安全检测、编译器开发等正常场景，可能和攻击工具开发共享部分底层技术知识。防御体系不能简单地把某项技术能力等同于恶意行为。

实战案例一：Windows进程注入

Windows远程进程注入是研究最初验证的场景。这涉及跨进程内存访问、内存空间分配、数据写入、线程创建等操作。

研究人员把相关技术需求拆成三个有合法用途的请求，提交给受保护的前沿模型A。模型A输出了需要的技术组件。

然后小模型B把这些组件整合起来，最终生成了一份221行、可以编译的C语言程序。这个程序实现了完整的Windows远程进程注入调用链，涉及OpenProcess、VirtualAllocEx、WriteProcessMemory、CreateRemoteThread等Windows API。

更简化的版本通过游戏辅助工具这个场景，用单次提示就完成了类似结果。

这说明两点：

第一，成功绕过不是因为分类器判断错了，前沿模型处理的就是正常的软件工程请求。

第二，模型A生成的独立技术组件，在另一个模型中经过整合后，能形成完全不同用途的程序。

实战案例二：CVE漏洞利用代码生成

研究团队以检测工程为背景向前沿模型A请求技术信息，再由小模型B整合。

测试涉及PrintNightmare、Log4Shell、反序列化、命令注入、SQL注入、服务器端请求伪造、目录遍历等多个主题。

结果显示，不同请求之间差异明显。PrintNightmare和Log4Shell相关Sigma规则请求返回了比较详细的内容；反序列化、命令注入等主题也获得了一定规模的技术输出。但部分其他请求仍然被阻断。

这说明检测工程场景并不意味着所有安全敏感请求都会通过，分类器还是会根据具体内容做判断。但在部分通过的场景中，输出内容已经包含能被后续整合的利用机制知识。

小模型B随后把相关信息处理成了可运行的概念验证代码。

核心风险不是安全模型直接提供恶意代码，而是防御性技术知识可能在跨模型处理中被转换为攻击能力。

10类场景测试：9类通过，1类阻断

研究团队参照MITRE ATT&CK，选了10类有代表性的攻击场景进行完整流程测试：

• 凭据访问：通过
• 反向Shell：通过
• 键盘记录：通过
• 持久化：通过
• 横向移动：通过
• DLL注入：通过
• Shellcode执行：通过
• 权限提升：通过
• 缓冲区溢出与漏洞利用开发：通过
• 防御规避：阻断

前9类场景都通过完整流程生成了可运行的攻击代码。

唯一失败的场景：防御规避

在防御规避测试中，研究人员想通过修改运行时安全监控相关函数来绕过检测机制。这类请求没能像其他场景一样通过良性重述获得所需内容。

即使请求中避免使用安全领域的明显术语，只要实际操作涉及在内存中修改运行时监控函数，分类器就会阻止。

这说明该分类器不只是识别关键词，还能理解请求背后的技术概念。这是一项重要的正面防护结果，证明面向技术行为概念的识别能力，可以在特定场景下形成有效阻断。

跨模型知识迁移：小模型为什么需要大模型帮忙？

既然最终代码由小模型B生成，攻击者为什么还需要用受保护的前沿模型A？

答案是专业知识差异。

研究团队做了对照实验，比较小模型B独立工作和完整跨模型流程的结果。

在反向Shell和DLL注入场景中，小模型B单独就能生成完整实现，引入前沿模型A后质量没明显差异。这些技术公开资料丰富，小模型已经有相应能力。

但在其他场景中，前沿模型的知识优势就明显了：

• 键盘记录：小模型B生成的内容比较简略，缺少底层Hook API实现深度；完整流程提供了更详细的技术实现。
• 权限提升：小模型B主要提供基础示例，完整流程增加了Windows令牌操作及身份模拟的专业细节。
• 凭据访问：完整流程提供了更准确的Windows内部机制知识，包括LSASS相关模式和句柄权限。
• CVE漏洞利用：小模型B主要提供通用描述，完整流程能引入特定漏洞的利用机制、API调用信息和内存破坏模式等细节。

跨模型组合流程最值得关注的风险，恰恰出现在不同模型专业知识差距大的领域。

原本受安全分类器约束的高质量技术知识，可以通过合法子任务进入下游模型，并在组合过程中获得新用途。

防护实践启示

基于研究结论，可以归纳出几个值得关注的方向：

1. 关注请求序列的整体含义

逐请求安全分类仍然是有效的基础防线。但如果只停留在单次请求层面，就可能遗漏不同请求之间的组合关系。

研究提出，跨请求语义累积是一种值得考虑的方向——分析同一API密钥近期发起的请求，判断这些请求在语义层面是否共同覆盖了某种有害任务。

不过这种方法存在结构性限制，不是完整解决方案。

2. 将多模型协同纳入威胁建模

单一模型的安全表现不能完全代表多模型系统的整体安全水平。需要考虑模型之间如何分配任务、传递信息，以及这些信息在后续步骤中可能形成的组合结果。

特别是前沿模型和未配置相同安全机制的小模型之间，跨模型知识流动值得重点关注。

3. 认识跨请求关联防御的边界

跨请求分析需要能观察到完整请求序列。但攻击者可能控制任务编排器，把不同子任务分散到多个模型服务商，用本地开源模型完成编排，或者轮换API密钥。

在这些情况下，单个服务商只能看到完整流程的部分请求，即使能分析自己平台内的多次交互，也未必能还原最终任务目标。

4. 重视面向技术概念的识别能力

虽然完整流程在9类场景中成功，但防御规避场景的阻断结果同样值得关注。即便请求避免使用明显敏感词，分类器仍然识别出了中和运行时监控机制的核心技术行为。

这体现了概念层面安全判断的作用。有效的安全分类不只是识别表面的敏感表达，还可以涉及对底层操作及其安全含义的理解。

5. 将攻击者编排行为作为独立分析对象

理解攻击者如何在不同模型服务之间分配请求、轮换密钥、利用本地模型完成编排，是一个独立于模型安全分类能力的威胁追踪问题。

模型提供商能看到的可能只是若干正常请求，而真正决定任务目标、执行顺序和最终组合结果的上下文，可能始终由外部编排器掌握。

平行研究验证

2026年9月，Microsoft Research发表了《Capability Laundering》研究，描述了类似的攻击方式。两项研究在同一时期独立开展，相关结论具有一致性。

Microsoft Research主要关注化学、生物、放射性和核相关风险领域；CrowdStrike重点研究网络攻击场景。

两项研究从不同方向得出的共同结论是：以单次交互为边界的安全过滤机制，存在无法完整覆盖跨任务组合风险的结构性限制。

这种平行发现说明，该问题不是某个特定提示词引起的偶然现象，而是需要在AI系统架构层面理解的安全问题。

结语

这项研究最值得注意的地方，在于它同时展示了现代AI安全分类器的能力和局限。

一方面，约515种直接绕过方法全部失败，说明先进安全分类器能有效抵御大量传统攻击方式。

另一方面，完整任务拆分为多个正常子任务后，10类测试场景中的9类获得了可运行的攻击代码。

两组结果并不冲突。问题不在于分类器是否正确判断了单次请求，而在于现有安全架构是否有能力观察和评估最终任务。

前沿模型提供的专业知识，可以通过良性请求进入下游处理流程，并在其他模型中被重新组合。

这意味着，AI安全防护不能完全沿用仅针对单模型、单请求的评估边界。未来需要关注的不仅是某个请求是否有害，还包括多个请求之间的关系、不同模型之间的知识迁移，以及最终任务可能产生的实际结果。

分类器没有失效。真正需要强化的是分类器之外的系统架构。

相关阅读

让好人先用上最强的 AI：Anthropic 的答案不是全放开，而是三级准入

AI批量提交来了，企业SRC怎么接？分级预筛、模板优化、内外部扫描区分实操

沙箱“未发现威胁”≠文件安全：60%定向攻击样本会装乖，一线分析师别被干净报告骗了

联系我们

合作电话：18610811242

合作微信：aqniu001

联系邮箱：[email protected]