SesameOp 后门
研究人员发现了一种名为 SesameOp 的新型后门，它利用 OpenAI Assistants API 作为非常规的命令与控制 (C2) 通道。该恶意软件并非使用典型的网络基础设施或定制的 C2 服务器，而是将 Assistants API 用作隐蔽的中继和存储机制，以检索加密指令并返回执行结果，从而使攻击者能够将恶意流量与合法的 API 请求混杂在一起。
目录
它是如何被发现的
该植入程序于2025年7月在一次复杂的入侵调查中被发现，当时身份不明的攻击者已在目标系统内维持了数月之久。研究人员并未公布受影响组织的身份。后续分析显示，这是一次多层入侵，其持久化机制和环境内组件共同支持了长期访问——这种行为符合间谍活动的目的。
技术架构
SesameOp 的感染链包含一个名为 Netapi64.dll 的加载程序 DLL 和一个名为 OpenAIAgent.Netapi64 的 .NET 后门组件。主要技术特征：
- 该 DLL 使用 Eazfuscator.NET 进行了高度混淆，旨在实现隐蔽性和持久性。
- 在运行时，加载器通过 .NET AppDomainManager 操作注入到宿主进程中，这是由精心构造的 .config 文件与合法的宿主可执行文件配对触发的。
攻击者还通过插入恶意库来入侵 Microsoft Visual Studio 实用程序，使用 AppDomainManager 注入技术来确保持久性和从看似合法的工具链执行代码。
内部工具
调查人员描述了一种“复杂的”内部Web Shell结构，该结构与持久存在的、策略性部署的恶意进程相连。这些进程充当本地协调器，执行通过Assistants API传递的命令，并将任务移交给其他植入组件。这种组合设计使攻击者的活动与正常的开发者和管理工具交织在一起，从而增加了检测难度。
OpenAI助手API是如何被滥用的
该后门使用助手 API 作为消息存储/中继。命令从助手列表中获取，并通过描述字段进行解释；该实现识别三种指令类型：
SLEEP — 指示植入物暂停线材一段指定的时间间隔。
有效载荷——指示代理从指令字段中提取代码或指令，并在单独的线程中运行它们。
结果— 表示执行输出应发布回 Assistants API，并将描述设置为“结果”，以便操作员可以检索结果。
操作流程
激活后，该后门会查询 Assistants API 以获取加密命令。它会在本地解码并执行有效载荷，然后将执行结果以消息的形式发送回 API。这种中继模型将合法的云端 AI API 转变为任务发送和输出接收的中间环节，有效地将攻击者的流量伪装在预期的 API 使用模式中。
归因、意图和战略目标
目前，尚无公开的攻击来源。该植入程序强调持久性、隐蔽控制和长时间驻留，这强烈表明攻击者旨在持续访问系统——这与情报收集或长期间谍活动相符。此案例也揭示了一种更广泛的趋势：滥用广泛使用的合法云服务来逃避检测并阻碍事件响应。
值得注意的是，Assistants API 计划于 2026 年 8 月弃用，并将被 Responses API 取代，这可能会影响未来类似滥用行为的运作方式。
要点总结
SesameOp 的显著之处在于，它将主流 AI 集成端点改造为隐蔽的 C2 通道，结合了 .NET AppDomainManager 注入、混淆的 DLL、被入侵的开发工具和内部 Web Shell，从而实现了持久且难以检测的控制。此次攻击活动凸显了防御者监控异常的开发工具行为、内部主机对云 API 的异常使用以及 .NET 环境中 DLL 注入或运行时篡改迹象的必要性。
