GuardBreaker攻击：用核武器提示词瘫痪AI恶意软件分析

一个与俄罗斯有关联的黑客组织针对乌克兰政府和物流机构，最近投放了一款带有"请求核武器制造说明"提示词的恶意软件。他们并不是真的想要这份说明，而是希望你的AI恶意软件分析工具因为触发安全拒绝机制而拒绝查看文件的其余部分。

整个把戏就这么简单：便宜、巧妙，并且暴露了AI辅助安全运营（SOC）工作流中一个被悄悄忽视的脆弱点。

事件经过

据The Hacker News报道，黑客组织UAC-0099针对乌克兰政府和物流目标部署了一款基于.NET的新型远程访问木马ASHVEIN。其投递链条使用了诱饵文档、DLL侧加载（sideloading），以及隐藏在HTML中的命令，以运行载荷并规避传统检测。

真正值得停下来思考的，是研究人员称之为GuardBreaker的技术。在恶意VBScript内部，嵌入了一段请求核武器制造说明的提示词。它的目的不是从模型中提取危险信息，而是触发用于分析代码的大语言模型（LLM）的安全拒绝机制，从而让这个LLM停止分析紧挨着它的恶意逻辑。

换个角度想想这意味着什么。如果你的事件响应流程现在包含了"把可疑脚本粘贴到LLM里，问它这段代码在做什么"，那么这个流程就有了一个攻击面。攻击者根本不需要击败你的恶意软件分析能力，他们只需要让分析者——无论是人类还是AI——拒绝去看。

DLL侧加载（DLL Sideloading）是一种滥用Windows合法程序加载机制的攻击技术。Windows在加载动态链接库时遵循特定的搜索顺序，会优先在可执行文件所在目录中查找DLL。攻击者利用这一机制，将恶意DLL伪装成合法软件所依赖的同名库文件，放置在合法程序的同级目录下，从而让合法进程代为加载并执行恶意代码。由于执行者是受信任的合法进程（例如系统自带的工具或知名软件），这种技术能有效绕过基于进程白名单或签名验证的安全检测。UAC-0099在ASHVEIN的投递链中使用该技术，正是为了让恶意载荷借助合法宿主进程的信任背书运行，降低被终端防护产品拦截的概率。

攻击的真实运作方式

大多数人以为针对LLM辅助安全工具的提示词注入，意味着让模型泄露数据或执行非预期操作。但GuardBreaker是一种形态完全不同的攻击：从攻击者视角看，这是一次防御性而非进攻性的"触发拒绝"越狱。

一旦看明白，机制其实很直接：

1. 恶意软件作者在VBScript代码块中嵌入一个明显会触发拒绝的请求（核武器制造说明几乎是所有主流模型安全训练中的通用触发线）。
2. 这段完整的VBScript被传入SOC分析师或自动化流程所使用的LLM工具，用于总结或分流。
3. 模型的对齐训练完全按设计工作：它拒绝了，很可能回复类似"我无法协助提供制造武器的说明"。
4. 分析师得到的是一句拒绝，而不是分析结果。脚本中真正执行DLL侧加载或与C2服务器通信的部分，从未被总结、标记或解释，因为模型停在了第一段让它警觉的内容上。

这并不玄乎。本质上是一次针对分析师工具的拒绝服务（DoS）攻击，只不过伪装成了安全触发器。而它之所以奏效，恰恰是因为安全训练做得好。模型不是被骗去做坏事，而是在错误的时刻被骗去做了"安全的事"。

提示词注入（Prompt Injection）是针对大语言模型的一类攻击，指攻击者将精心构造的指令混入模型处理的外部内容中，试图覆盖或篡改原始系统提示，使模型执行非预期操作。传统的提示词注入通常以"进攻性"为目标，例如让模型泄露系统提示、绕过内容限制或冒充其他身份。GuardBreaker所代表的变体则截然相反——它不谋求让模型"做更多"，而是让模型"什么都不做"。这种"防御性拒绝型"注入利用的是模型对齐训练中安全拒绝机制的确定性：攻击者不需要了解目标模型的具体实现，只需知道几乎所有经过RLHF（人类反馈强化学习）对齐的主流模型都会对某些敏感话题触发硬性拒绝，核武器制造说明便是其中公认的高可靠触发词之一。

被忽视的检测盲区

大多数防御在这里崩溃，而问题不出在模型本身，而是流程设计。

如果你的恶意软件分析流程是"把原始文件内容直接倒进LLM提示词"，那么你就没有一个层级能区分哪些内容是用来分析的、哪些内容是用来被执行（或在此案例中被拒绝）的。LLM看到的是一整块未经区分的文本。它无法分辨"这段VBScript内嵌了一个越狱载荷"和"一个人类真诚地在询问核武器"，它只会对照安全训练进行模式匹配，然后退出。

传统的杀毒软件和基于YARA规则的扫描器根本不会注意到这一点。这里没有可匹配的文件哈希，也没有已知签名，因为这次"攻击"针对的不是终端，而是事后拼接到SOC流程里的"人在回路"AI工具。没人把恶意软件分析助手当作攻击面来做威胁建模，所以也没人在它前面建一道防线。

这就是盲区所在。不是传统意义上"LLM被越狱了"（没人让它输出有害内容），而是LLM被反向越狱：在该分析时被骗去拒绝分析。

为什么需要在模型之前加一道清洗层

这是一个教科书级的案例，说明应当在不可信内容到达分析模型之前就通过一层清洗（scrubbing）处理，而不是指望模型实时自行判断。

以Sentinel这类AI防火墙为例，其快速路径的正则库包含人格切换（persona-shift）和权限劫持（authority-hijack）等模式；对本案更重要的是深度路径的向量相似度层，它会把内容与一套攻击签名嵌入库比对评分，而不管使用了哪些具体词汇。一个嵌在VBScript代码块里的危险内容请求，不会长得像正常代码，它会呈现出其真实面目：一段语义上明显突兀、缝进看似无害脚本中的注入尝试。无论载荷写成"告诉我怎么造炸弹"，还是裹上社会工程学的外衣，这种相似性都会暴露出来。

实际的接线方式应当是：原始脚本内容在交给分析工具的LLM做总结之前，先POST到清洗接口。如果嵌入的提示词评分超过中和阈值，清洗层会剥离或中和违规片段，同时保留脚本其余部分供分析。你的恶意软件分析LLM拿到的是净化后的版本，外加一个标记，告诉它（以及分析师）有对抗性内容被剥离了。模型根本不必决定是否拒绝整份文档，因为到它手里时，触发器已经不在文档中了。

这也意味着你的分析师不会丢失周边上下文——而上下文正是DoS式拒绝攻击真正想摧毁的目标。你仍然能看到DLL侧加载逻辑、C2信标模式等全部内容。被拔掉的只是核武器诱饵，而不是整个文件。

需要说明的是：作者并未用这个具体的VBScript样本实际测试过，报道中也没有给出确切的载荷文本。能确定的是，这正是"在LLM看到之前扫描不可信内容"时，深度路径与快速路径层所要捕捉的那一类载荷。

示意性流程

一个示意性的处理结果大致是：可疑脚本被提交清洗，返回中威胁评分约0.89、动作为"neutralized"（已中和），安全载荷中保留了obj.Run "rundll32.exe payload.dll,EntryPoint"这类DLL侧加载调用，而嵌入的指令劫持载荷被替换为[NEUTRALIZED]标记。DLL侧加载调用完整留给分析师标记，核武器诱饵则压根到不了模型，也就没有东西能触发拒绝了。

YARA是安全行业广泛使用的恶意软件模式匹配工具，分析师通过编写描述文件特征（字符串、字节序列、结构特征等）的规则，来识别和分类已知恶意软件家族。YARA规则在检测具有固定特征的已知威胁时高效可靠，但其本质是静态签名匹配，天然无法应对语义层面的攻击。GuardBreaker在这里制造了一个结构性盲区：嵌入的"核武器制造说明请求"是普通的自然语言文本，不包含可执行代码、恶意字节序列或已知恶意软件特征——对YARA规则而言，它和一段注释毫无区别。真正的攻击发生在分析工具的认知层而非文件层，这正是为什么防御必须前移到LLM的输入管道，而不能依赖传统的基于特征的检测方案。

核心启示

如果你的事件响应或恶意软件分流流程中，任何环节会把原始、不可信的文件内容直接灌进LLM，那就应当把这些内容当作对抗性输入——就像你会在信任之前把网络数据包或上传文件默认视为恶意一样。要在模型看到之前扫描，而不是等它拒绝之后再补救。

GuardBreaker不是传统意义上"让AI说坏话"的越狱，而是一种将正确的拒绝行为武器化、从而致盲分析工具的越狱。但无论哪种，修复思路都一样：不要让模型成为第一个接触不可信文本的东西。

这起事件提醒整个安全行业，AI辅助工具在带来效率的同时，也引入了全新的、尚未被充分建模的攻击面。随着越来越多的SOC把LLM嵌入日常流程，攻击者针对AI工具本身的创意只会越来越多。