当您的AI助手成为攻击者的指令控制中心

本月早些时候，微软发现了一种名为“芝麻开门”（SesameOp）的新型后门恶意软件，其滥用OpenAI Assistants API作为一个隐蔽的命令与控制（C2）通道。这一发现引起了网络安全界的广泛关注。安全团队不能再仅仅专注于端点恶意软件。攻击者正在将公共且合法的AI助手API武器化，防御者必须做出调整。

什么是SesameOp？

SesameOp是一种定制的后门恶意软件。其设计目的是维持持久性，并且关键的是，允许攻击者隐蔽地管理受感染的设备。

根据微软的信息，感染链将一个加载器组件（Netapi64.dll）与一个基于.NET的后门（OpenAIAgent.Netapi64）结合起来，并利用OpenAI API作为C2通道来获取加密命令。

从根本上说，这意味着攻击者滥用了诸如助手描述、自定义指令和消息等字段来存储信息（包括命令），并使用SesameOp恶意软件执行它们。

然而，真正重要的是，攻击者并未利用AI服务中的漏洞；他们只是重新利用了合法的API功能。为什么这是个问题？因为这意味着组织信任和依赖的合法云AI功能现在可能成为攻击者基础设施的一部分。这也意味着针对这些功能的攻击更难被检测。

利用合法服务进行C2通信并非新现象。此事件只是历史上伪装成合法使用的隐蔽通信的最新案例。例如，今年早些时候，Palo Alto的Unit42记录了一场使用Lambda URL进行C2的恶意软件活动。换句话说，这种模式并不新鲜，但具体的执行方式是新的。

那么，这对您的API攻击面、您的AI和代理部署以及您如何防御它们意味着什么？

SesameOp对API风险格局意味着什么？

存在漏洞的API并不新鲜。在2025年第三季度，Wallarm记录了1,602个与API相关的漏洞，比上一季度增加了20%，其中错误配置占38%，紧随其后的是身份验证破坏问题。更说明问题的是：CISA的KEV目录中新增条目有16%与API相关。

但现在API攻击面变得更加复杂。组织正在部署AI助手、编排代理和基于MCP的微服务，创造了新的端点、流量模式和全新的信任边界，而大多数组织尚未对此进行映射或配置监控。SesameOp展示了攻击者如何利用这一现实为自己谋利。

理解SesameOp的关键在于，攻击者并未攻破OpenAI的Assistant AI；他们只是重新利用了它。他们将一个合法的AI端点变成了一个隐蔽的通信通道，混杂在合法流量中。简而言之，该AI助手在技术上完全按照其应有的方式运行。

SesameOp象征着API攻击战术更广泛的转变。攻击者正从传统的代码利用转向利用合法的服务和业务逻辑。他们利用云平台作为基础设施，混入典型的AI生成流量中，并利用组织对AI系统的信任。

传统的WAF和API网关并非为应对这种情况而设计。它们无法解释助手指令、代理工作流、上下文传递或MCP行为。它们无法理解API端点何时行为“异常”或被用作隐蔽通道。

防御者必须适应。他们需要具备API和AI感知能力的保护、实时阻断、深度可见性和行为分析，能够检测到助手或代理何时停止作为产品功能运行，并开始充当攻击者的控制系统。

Wallarm如何提供帮助

那么，组织如何保护自己免受SesameOp等威胁？让我们探讨一下Wallarm的功能如何帮助降低SesameOp攻击每个阶段的风险。

步骤1：映射攻击面

SesameOp攻击者利用了合法的AI助手API通道。Wallarm的持续发现能力可以发现新的或意料之外的API及AI助手端点、不熟悉的凭据，或者从不应与之通信的机器突然使用AI服务的情况。

步骤2：检测异常流量

尽管SesameOp的C2通道看起来像是合法的AI调用，但Wallarm的行为分析和过滤节点可以检测到在其他正常API流量中的异常模式。重复的轮询、异常的请求时间或未经批准的目的地会显得突出，因为Wallarm会建立正常行为的基线并标记偏差，即使域名本身是合法的。

步骤3：阻断和预防

一旦后门开始使用Assistants API作为其命令循环，获取指令并发布编码结果，Wallarm的内联强制执行可以打破这个循环。通过阻止未经授权的API调用、可疑的有效负载或非白名单的AI助手操作，Wallarm可以切断通过AI端点进行的命令检索和数据渗出。

步骤4：响应和调查

如果确实有东西漏网，Wallarm详细的请求日志、元数据和集成为事件响应团队提供了清晰的可见性。这包括来自开发机器的异常助手创建调用、来自工作站的重复API轮询，以及流向AI端点的编码消息。这种上下文加速了遏制，并使隐蔽的C2通道更容易被应对。

您现在需要做什么以及Wallarm的附加价值

SesameOp表明，合法AI使用和AI滥用之间的界线极其细微。防御这种新型威胁始于加强基础安全，但需通过API和AI感知的视角来实现。

组织应优先考虑：

• 清点API和AI/代理端点：不要假设每个AI助手、MCP接口或微服务都是可见的。您无法保护看不见的东西。
• 监控入站和出站流量：公共AI端点现在可能成为C2候选。跟踪谁与它们通信、频率如何以及原因。
• 对API密钥和目标实施严格控制：仅允许列入白名单的密钥。移除未使用的凭据。默认阻止未知或不受信任的目标。
• 使用内联保护：仅靠检测无法阻止使用AI端点作为通信循环的后门。您需要能够阻断（而不仅仅是告警）可疑API/代理调用的内联保护。
• 将API/AI安全左移到SDLC中：在进入生产环境之前，扫描API定义、MCP接口、代理权限和端点配置。
• 为“合法变滥用”场景做好准备：并非每次攻击都会涉及恶意软件。检测正常API的滥用依赖于行为分析和异常检测。
• 选择支持全栈的平台：Web应用、API、微服务、无服务器和AI代理现在都是同一攻击面的一部分。您需要一个支持所有这些的平台。

但是，您如何将这些基础原则付诸实践？而不必拼凑无数单独的工具并淹没在手动工作中？通过与Wallarm合作。以下是我们解决方案的帮助方式：

与Wallarm一起对抗不断演变的威胁

如果SesameOp告诉了我们什么，那就是我们不能再将AI流量视为事后考虑，或者认为合法服务就构成安全流量。保持安全的组织将是那些将API和AI/代理安全视为一个统一问题的组织。