当大语言模型的安全防护能挡住几百种攻击时，我们是不是就可以放心了？
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 安全防护不能完全沿用仅针对单模型、单请求的评估边界。未来需要关注的不仅是某个请求是否有害，还包括多个请求之间的关系、不同模型之间的知识迁移，以及最终任务可能产生的实际结果。
分类器没有失效。真正需要强化的是分类器之外的系统架构。
发表于 昨天 23:01
|
查看: 4|
回复: 0
