微软提示词注入检测器实战捕获钓鱼攻击

微软构建了一个提示词注入检测器，结果却意外截获了一场钓鱼攻击行动。

上周，微软标记了一起利用机器阅读文本方式漏洞的钓鱼活动。攻击者在邮件正文中嵌入不可见的 Unicode 标记字符，这些字符在屏幕上不会渲染，但会改变软件处理的底层字符串。

微软表示，攻击者已在实战中大规模使用该技术来绕过垃圾邮件过滤器和基于机器学习的分类器，同样的手法也可能对那些定期摄入外部文本的 AI 系统造成威胁。

Tag 字符分割关键词

安全研究人员已记录到一种几乎相同的攻击技术，其目标是大型语言模型（LLM），通常称为"ASCII Smuggling"（ASCII 走私）。该技术使用 U+E0000 至 U+E007F 范围内的 Unicode 标记字符——这些码点存在于字符流中，但大多数界面都不会显示它们。

这就产生了同一段文本的两个版本：人类看到的和软件接收到的。

Human view:     funding
Under the hood: fun⟨U+E0020⟩ding

在微软 Defender for Office 365 追踪的这场攻击活动中，攻击者并非使用标记字符向 AI 模型走私隐藏指令，而是将其嵌入与金融钓鱼相关的高信号词汇中，如"funding""loan"和"credit"。这样一来，扫描这些词汇的过滤器就无法再找到精确匹配。

活动开始前一天，针对 ASCII Smuggling 的狩猎签名在约 21,000 条消息上触发；次日，触发量超过 130 万条。仅仅两天后，数量就突破了 230 万条。整个过程中，收件人看到的只是普通的商业贷款和信用额度邀请。

仅仅两天后，数量就突破了 230 万条。

分词器的解析差异

NLP 系统在处理文本前会将其拆分为 token，在单词中插入意外的 Unicode 字符可能会改变这些 token 的形成方式。研究人员已证明编码技术可以隐藏对抗性内容以躲避 AI 系统，不过微软此次攻击活动中，攻击者将这一技巧用于不同目的。

NLP 系统在处理文本前会将其拆分为 token，在单词中插入意外的 Unicode 字符可能会改变这些 token 的形成方式。

具体发生什么取决于分词器。一些分词器可能会忽略标记字符，而另一些则会不同地拆分周围文本，因此开发者必须测试自己实际使用的模型，而不是假设它们行为一致。

对文本进行标准 Unicode 规范化也不一定能彻底移除这些标签。NFC 和 NFD 可以清理同一字符的不同表示形式，但它们并非为剥离 Unicode 标记字符而设计，这意味着这些标签仍然可以存活到下一步处理流程。

Agent 缺乏邮件的防御机制

邮件服务商除了检查邮件内容外还有其他方式发现可疑消息，但 AI 流水线获取的信息可能远没有那么丰富。

当 Agent 拉取外部文本并用它来决定下一步操作时这就成了问题，因为埋在文本中的不可见字符会改变处理方式，同时也会让隐藏的提示词注入对查看原始文本的人而言更难察觉。

模型前先规范化

对于没有理由接受 U+E0000 至 U+E007F 范围内字符的应用，最简单的方法是在文本到达模型前将其移除。不过当应用有合理理由保留这些字符时，事情就变得复杂了。

在这些情况下，开发者可以将原始文本与移除标签后的版本进行对比，检查是否有任何变化，同时测试应用实际使用的分词器看它如何处理这些字符。无论清理了什么，都应在后续流程中保持清理状态，而不是检查一个版本的文本然后将未处理的原始版本发送给 LLM。

分区旗帜的边界情况

并非所有 Unicode 标记字符都可以安全剥离，因为有些具有合法用途。英国、英格兰、苏格兰和威尔士的分区旗帜 emoji 依赖于不可见的标记字符序列来渲染，而微软最初的狩猎签名范围足够宽泛，曾触发这些旗帜，后来团队才明确添加了例外规则。

并非所有 Unicode 标记字符都可以安全剥离，因为有些具有合法用途。