当“加载模型”变成“执行未知代码”：AI 供应链中的 GPU 挖矿陷阱

原创 威胁情报中心 2026-11-05 17:07 北京

模型权重只有 42 字节、不含任何张量的“模型仓库”，真正发挥作用的是仓库里的一段 Python 代码——两波 31 个恶意仓库、超 3 万次下载的 Load/Mine 活动全景复盘。

一个名为 qwen2-tiny 的模型仓库，模型权重文件只有 42 字节，里面没有任何张量；真正发挥作用的是仓库中的一段 Python 代码。

当使用者以 trust_remote_code=True 加载它时，代码在模型初始化之前执行：写入看门狗、修改 Shell 启动文件、获取挖矿程序，并尝试把矿机伪装成 Linux 内核工作线程。部分版本还会先连接反向 Shell，让攻击者获得交互式访问能力。

这不是一起利用模型权重投毒或 Pickle 反序列化漏洞的攻击。攻击者利用的是 Transformers 明确提供的自定义模型代码加载能力，以及使用者在教程、测试和自动化部署中形成的信任习惯。

Pluto Security 将这次活动命名为 Load/Mine。其调查覆盖两波共 31 个恶意仓库；若计入仅存在技术关联、尚不能证明同属一个运营者的模型，总下载量为 32,376 次。代表性仓库 MENXIANGYU/qwen2-tiny 在 10 月 28 日达到 28,412 次下载。

01 事件快照：攻击者要的不只是 GPU 算力

从防守视角看，挖矿只是最容易被察觉的结果。看门狗、启动项、SSH 授权密钥和反向 Shell 才决定了攻击者能否在矿机被终止后继续回来。

02 真正的入口：模型尚未加载，仓库代码已经运行

1. trust_remote_code=True 到底开启了什么

部分模型需要仓库自带 Transformer 配置、分词器或建模实现。Transformers 为此提供自定义代码加载机制：使用者通过 trust_remote_code=True 或交互确认，允许框架执行发布者提供的 Python 文件。

典型调用如下：

关键不在权重文件，而在 config.json 中的 auto_map。它指定需要加载的 Python 模块和类。框架下载相应文件后，通过 Python 导入机制执行模块；模块顶层语句会先运行，随后框架才取得目标类并继续模型初始化。

以代表性仓库为例，auto_map 指向 modeling_evil2.EvilModel。modeling_evil2.py 在类定义之前调用_boot()，因此恶意逻辑不需要等待模型对象创建成功：

这带来两个直接结论：

• 即使模型随后加载失败，前置代码也可能已经执行。

  不能仅凭“模型没跑起来”排除失陷。

• 代码以加载进程的身份运行。

  它能访问该进程拥有的文件、网络、凭据和 GPU 环境；若以 root 或高权限服务账号运行，影响随之扩大。

2. 为什么“Safetensors 安全”不能推导出“整个仓库安全”

代表性仓库中的 model.safetensors 只有 42 字节且不含张量。它没有承担恶意代码投递功能，只是让仓库外观更接近正常模型。

Safetensors 的安全设计针对的是权重反序列化风险；trust_remote_code 涉及的则是仓库内 Python 实现。二者是不同的执行面。权重格式安全，不等于配置、建模代码和加载流程安全。

03 主机攻击链：从一次导入到持久化挖矿与远程控制

不同仓库和版本的能力并不完全一致。下面以六个已分析的第二波挖矿版本为主线，并单独标注变体行为，避免把所有功能误认为每个样本都具备。

阶段一：建立立足点，部分版本先打开反向 Shell

代表性载荷将看门狗写入：

看门狗作为独立进程运行，使用模型加载器的 Python 解释器，每 120 秒检查并重新启动缺失的矿机。载荷还向以下文件追加重启钩子：

因此，结束挖矿进程并不等于清除感染。看门狗、Shell 启动钩子及其他持久化机制仍需分别处理。

在 qwen2-tiny-5、qwen2-tiny-6 和 qwen2-tiny-9 三个版本中，独立进程会在持久化步骤之前连接 212.32.253.3 的 443 或 9443 端口，并在断线后重试。连接成功后，攻击者获得继承失陷进程权限的交互式 Shell。

阶段二：获取矿机，并准备两条执行路径

挖矿二进制名为 syscore.bin。载荷会依次尝试从已下载的模型快照、既往感染留下的 /tmp/.cch/sync 获取它；若本地没有，则从 Hugging Face 仓库或镜像下载。

需要联网下载时，客户端会取消主机已配置的代理设置，尝试直接出站。在网络允许直连的情况下，这可能绕过代理检查和日志；如果网络强制经过代理，它并不能凭此突破该限制。

第一波钱包相关的在线 worker 报告客户端为 peakminer/2.16.5。研究人员恢复第二波二进制的打包标记并解包后，也确认了其中的 peakminer。

阶段三：首次启动走内存文件路径，失败后回退到磁盘

首次启动时，载荷把二进制复制到 memfd_create 创建的内存文件描述符，再通过 fexecve 执行，并将 argv[0] 设置为：

这样，首次执行不依赖一个普通的磁盘可执行文件路径，进程列表中还会出现类似内核工作线程的名称。但伪装存在可检测的破绽：真正的内核线程不会携带这种用户态挖矿参数，而异常进程的完整命令行中可以看到 worker 登录信息。

看门狗后续重启则使用磁盘上的回退副本：

第二波 syscore.bin 大小为 40,625,780 字节，使用 UPX 打包。样本中两处 UPX! 标记被改为 PEK!，导致常规 upx -d 拒绝解包；但样本内置的加载逻辑仍能完成解包和运行。这一改动主要增加静态分析难度，并不改变其挖矿功能。

阶段四：借用 Xinference 注册表回传状态，清理竞争矿机

载荷把状态信息伪装成 Xinference 本地模型注册名称，例如：

状态码覆盖启动、二进制就位、内存路径运行、磁盘回退运行、下载失败、启动失败、看门狗恢复挖矿等阶段。每第五个看门狗周期还会写入含 GPU 利用率的心跳信息。能够访问相应 Xinference API 的攻击者可以读取并解码这些名称。

这里不应误解为 Xinference 模型注册表天然等于远程 C2。样本首先把状态写入本地注册表；攻击者能否远程读取，还取决于 API 是否可达以及访问控制是否缺失。这也是 Pluto 建议为 Xinference API 启用认证并限制网络可达性的原因。

矿机运行后，载荷还会删除竞争模型的注册信息、剥离其启动命令并终止匹配进程。早期版本扫描 /proc/*/cmdline，识别 13 种竞争矿机名称，以独占计算资源。

阶段五：特定变体尝试从特权容器进入宿主机

在第一波披露邮件发出约 8.5 小时后，MENXIANGYU/qa-whl-1021 发布。其中的脚本面向特权容器场景：激活 LVM 卷、挂载候选宿主机磁盘，寻找宿主机根文件系统或 GPUStack 的 /var/lib/gpustack，进而建立宿主机 root 登录通道。

这一脚本把目标从 Xinference 扩展到 GPUStack，也说明攻击者关注容器下方的宿主机。但它有明确前提，不能表述为任意容器加载模型后都会自动逃逸。是否使用特权容器、是否暴露宿主机资源，直接决定该路径能否成立。

另一个后期下载器对 212.32.253.3:8898/lf_py.py 的第二阶段内容实施来源 IP 限制。非白名单请求只得到 403 和 static ip.，意味着分析人员在不满足来源条件时可能无法获取真实后续载荷。

04 两份遗留备份，串起测试账号与生产账号

活动发现过程同样值得关注。

研究人员首先扫描 config.json 的 auto_map 实际引用的 Python 文件，以及模型权重旁的 Python 文件，关注 subprocess、socket、ctypes、memfd_create 等高风险行为。测试账号 dsxk4mr8tq 下的 qwen2-tiny-gpt2 因此进入视野：其 modeling_evil.py 同时命中多类特征，账号在 10 月 12 日的 2.5 小时内创建了六个仓库。

真正连接不同账号的是 qwen2-tiny-lite 中遗留的两个备份文件：

主文件中的下载地址已经更新，备份文件却仍保留旧地址，分别指向 Hugging Face 的 hhzz667 和 ModelScope 的 wssb123e。运营者复制生产代码到测试账号时忘记清理备份，版本痕迹由此成为关联证据。

这比单纯依据模型名称或代码相似度更扎实：旧 URL 将测试账号、生产账号和跨平台二进制镜像直接连接起来。

05 两波活动演进：入口不变，访问方式与载荷持续调整

截至 10 月 28 日的下载量拆分如下：

MENXIANGYU/qwen2-tiny 一个仓库占第二波下载量约 97.7%。但下载量可能包含研究、镜像、重复拉取或自动化访问，不能直接换算为感染主机数。

06 为什么扫描结果显示“干净”

Hugging Face 会在每次提交时使用 ClamAV 扫描小于 2 GB 的文件，并集成 Protect AI、JFrog 等扫描能力检查支持的机器学习模型格式。问题在于，这些能力与本次入口并不完全重合：

• 杀毒扫描主要识别已知恶意特征；

• 模型安全扫描重点处理 Pickle、Keras 等权重或序列化格式风险；

• 本次核心是 auto_map 指向的普通 Python 文件，其危险之处在于导入后的行为，而不是权重格式本身。

Pluto 的测试显示，第一波 12 个仓库均未被标记；第二波代表性 modeling_evil2.py 也未被已运行的扫描器判为恶意。JFrog 返回的信息是“不是机器学习模型”。

07 实际影响：矿池仍有收益，风险不止于算力消耗

Pluto 记录，第一波钱包通过 716 笔交易收到约 2,276 PRL，并已将约 2,241 PRL 转出。相关矿池在第一波仓库移除后仍显示在线 worker。

研究期间，九个名称类似共享 Notebook 和 A100 GPU 节点的 worker 在 90 秒内陆续加入，约六分钟后停止提交份额。研究人员认为，这一现象与管理员发现后终止任务的情形相符，但公开信息并未进一步确认这些主机的管理方和处置过程。

归因方面，Pluto 依据简体中文代码注释、阿里云上的 C2、ModelScope 与 hf-mirror.com 镜像、面向 Xinference 和腾讯云的变体，以及集中于中国标准时间深夜的活动时段，将核心活动评估为经济利益驱动、使用中文的个人或小团体。这些证据可以支持语言环境和动机判断，但不足以支持更高层级归因。

soumikmahato 的“parasit”分支带有印尼语注释并采用不同构建方式。Pluto 对此保留两种可能：第二个运营者，或同一运营者刻意构建外观不同的冗余分支。分析时不应把该分支的每个特征都强行归入同一作者。

08 另一条独立攻击链：伪造 Solana 项目，诱导 AI 编程代理执行命令

Bleeping Computer 在同一篇报道中还介绍了 Air Security 的 SolanaCry 研究。它与 Load/Mine 没有证据表明属于同一活动，但共同揭示了一个变化：攻击者不只等待人阅读恶意说明，也开始利用 AI 代理自动搜索、选择和执行的工作流。

1. 仓库只有 README，却足以完成投递

GitHub 仓库 SolanaUpdateTools/solana-starter-kit 创建于 2025 年 11 月，研究时有 286 个星标。它自称提供 Anchor、TypeScript 客户端和 Next.js 界面，实际上没有对应项目代码，唯一文件是 README。

README 的唯一“安装步骤”是一条 Windows PowerShell 命令。命令把字符串片段拼接为：

随后通过 iwr 下载内容，再交给 iex 直接在内存中执行。此投递阶段不先把脚本保存为普通磁盘文件；如果 AI 编程代理根据搜索结果选中仓库并照做，开发者可能只看到代理转述的安装结果，而没有审查原始命令。

2. 合法远程管理软件被改造成隐蔽控制通道

Air 从互联网档案中恢复的实际载荷 indicator.ps1 约 21 MB，内嵌 14 个文件：13 个为合法签名的 NetSupport Manager 组件，另一个为攻击者配置的 client32.ini。

脚本创建隐藏目录 %LOCALAPPDATA%\y2inwRnI6G，写入组件，并通过以下注册表运行键实现登录自启动：

配置将 maxwintodaybtc[.]com:443 设为控制端，关闭聊天、提示、断开按钮和系统托盘等用户可见功能。NetSupport 本身是合法商业远程支持软件，但在这里提供屏幕与键鼠控制、文件传输、远程命令执行、音频采集和注册表访问等能力。

脚本最后清理 RunMRU 历史并删除自身，再显示“开发者功能暂时因负载暂停，请 72 小时后重试”的虚假错误。AI 代理可能把它转述为普通服务故障，从而降低开发者立即检查命令和主机变化的概率。

Air 根据样本中的 RADIUSSecret 将其与 eSentire 跟踪的 NetSupport 集群 EVALUSION 关联，并发现其命令拼接方式与此前伪造 TradingView“AI 信号”工具的活动一致。这属于基于配置与加载器特征的研究关联。

Air 检查时，原始载荷 URL 已返回 404；BleepingComputer 则通过互联网档案中的样本确认了上述行为。因此，检查时 URL 失效不代表历史执行风险消失，也不能据此判断仓库曾经无害。

09 防守建议：把模型代码当作代码依赖，把代理读到的内容当作不可信输入

1. 模型上线前：审查、固定版本、隔离验证

• 默认不为不可信仓库启用 trust_remote_code=True。

  对确有业务需要的仓库建立发布者、仓库和用途白名单，而不是只检查模型名称。

• 审查完整代码链。

  从 config.json 的 auto_map 出发，检查其引用的全部 .py 文件及后续导入，不只扫描权重文件。

• 固定已审查的提交版本。

  使用完整 commit 哈希锁定 revision，避免审查后仓库内容发生变化；必要时在内部镜像中保存已验证副本并校验哈希。

• 在隔离预发布环境先加载。

  使用非 root、非特权容器，不挂载 Docker Socket 和宿主机敏感目录，不注入生产凭据，限制出站网络与文件写入。

• 将行为检测纳入模型准入。

  对 subprocess、原始 socket、ctypes、memfd_create、动态下载执行、启动项修改等组合行为进行静态和动态检测，但不要把单一正则或“扫描干净”作为最终结论。

2. 推理平台：缩小单次加载的影响半径

• 为 Xinference API 启用认证并限制网络可达性，避免将管理接口直接暴露给不可信网络。

• GPUStack、Xinference 和模型评测任务使用独立低权限账号，避免 root 运行。

• 禁止使用特权容器加载未经验证的模型；限制宿主机设备、LVM、敏感目录和管理接口挂载。

• 对模型加载进程设置出站目的白名单，重点监控矿池、原始 IP、非常用端口和运行时新增的下载行为。

• 将 GPU 利用率异常与进程、容器、模型注册信息关联分析，避免仅凭 GPU 使用率判断是否存在后门。

3. AI 编程代理：搜索结果可以读，命令不能自动放行

• 把仓库 README、网页和搜索结果视为不可信内容，不允许其中的指令绕过人工审批。

• 对代理发起的 Shell、PowerShell、包安装和远程脚本执行保留明确的人工确认，尤其是 iex、iwr、管道执行及拼接 URL。

• 不允许代理仅凭星标、搜索排名或项目描述选择并执行 starter kit；先核对仓库文件、发布者历史与项目真实性。

• 记录代理读取的仓库、生成的命令和实际执行结果，使安全团队能够还原“哪段外部内容触发了哪条命令”。

4. 已加载可疑模型：按主机失陷处置，而不是只结束矿机

1. 隔离并保留证据。

   先限制生产和出站访问，再采集进程、连接、日志、模型缓存、启动文件、计划任务、SSH 密钥和模型注册表变化。

2. 排查同源暴露。

   检查其他加载过相同仓库或共享同一镜像、Notebook、CI 缓存的主机。

3. 清除所有回访路径。

   同时处理看门狗、Shell 启动钩子、cron、SSH authorized_keys、反向 Shell、恶意模型注册和后续载荷。仅删除模型或杀掉矿机并不充分。

4. 从干净主机轮换凭据。

   撤销并更换失陷进程可接触的 Hugging Face Token、云凭据、密码和 SSH 密钥，并检查近期异常使用。

5. 无法确认完整性时重建。

   使用可信镜像重新部署，不在已失陷主机上仅做表面清理后继续投入生产。

10 结语

这次活动的核心并不复杂：攻击者把普通 Python 文件放进名称熟悉的模型仓库，等待使用者打开一个常见参数。复杂的是随后形成的工程化能力——多源下载、看门狗、内存文件执行、进程伪装、状态回传、竞争矿机清理、反向 Shell，以及特定场景下的宿主机访问。

对 AI 基础设施而言，安全边界不能只画在“模型文件”上。模型仓库中的配置和代码、加载进程的权限、推理 API 的暴露面、容器与宿主机之间的隔离，以及 AI 代理自动执行外部说明的权限，都属于同一条供应链。

11 技术附录

附录 A：MITRE ATT&CK 技术映射

以下映射依据公开样本行为整理，覆盖 Enterprise ATT&CK。并非每个仓库都具备全部行为，带“特定版本／变体”的条目应结合样本范围理解。

A.1 Load/Mine：Hugging Face 恶意模型活动

A.2 SolanaCry：伪造 Solana Starter Kit

附录 B：失陷指标（IOC）

B.1 核心活动仓库

B.2 网络基础设施与矿池

B.3 钱包地址

B.4 主机文件、进程与配置痕迹

第一波植入的 SSH 公钥：

B.5 核心样本 SHA-256

第二波矿机解包后的 ELF Build ID：

B.6 SolanaCry 指标

附录 C：只读排查命令

以下命令用于 Linux 主机初步核查，不会清除或修改任何文件。结果需结合进程树、网络日志和模型加载记录判断。

Windows 侧可重点核查：PowerShell 与代理执行日志中是否出现上述仓库或域名、SecureModule 运行键、隐藏目录及非预期 NetSupport 组件。若确认执行过相关命令，应同时排查代理会话日志和开发者主机，而不是只清理 README 或仓库缓存。

参考链接

1. Pluto Security：Load/Mine—A Hugging Face Malware Campaign Returns After Takedown
https://pluto.security/blog/hugging-face-malware-campaign-load-mine/

2. BleepingComputer：Hugging Face malware campaign returns to hijack GPUs for crypto mining
https://www.bleepingcomputer.com/news/security/hugging-face-malware-campaign-returns-to-hijack-gpus-for-crypto-mining/

3. Air Security：SolanaCry—Malware in the wild steals crypto wallets from web-browsing AI agents
https://www.air.security/blog-posts/solanacry

4. Hugging Face Transformers：Custom models 与 trust_remote_code
https://huggingface.co/docs/transformers/en/models

5. Hugging Face Hub：Malware Scanning
https://huggingface.co/docs/hub/security-malware

6. Hugging Face Hub：Pickle Scanning
https://huggingface.co/docs/hub/security-pickle

7. MITRE ATT&CK：Enterprise Techniques
https://attack.mitre.org/techniques/enterprise/

8. 相关 GitHub 仓库页面：SolanaUpdateTools/solana-starter-kit
https://github.com/SolanaUpdateTools/solana-starter-kit

阅读原文

跳转微信打开