npm被投毒850个恶意包，可造成远程控制和信息窃取！

原创

mmc
mmc

AGI安全

2026年8月8日 10:49
北京

在小说阅读器读本章

去阅读

npm被投毒850个恶意包，可造成远程控制和信息窃取！触发

约 850 个恶意包被批量投放至 npm 仓库，携带跨平台 RAT 与信息窃取载荷，同时覆盖 Windows / macOS / Linux。它不用 preinstall / postinstall 生命周期钩子，而是在 README 里「教」开发者用 require() 把它加载进项目——装完不动它，扫描器就什么也看不到。

npm 投毒 → README 诱导 require() → 跨平台落地 链路示意≈850 个恶意包AI 生成随机名 / 仿冒名typo-squattingREADME 社工诱导require('pkg')不用 install 钩子WEL1DROPPER识别 OS + CPU 架构HTTPS / DNS TXT 双通道WindowsmacOSLinux远程控制 + 信息窃取 · 安装期静默 · 引用即触发

导语

2026 年 8 月 7 日，开源恶意软件研究者 Paul McCarty（OpenSourceMalware） 披露：一场新的投毒行动向 npm 注册表批量推送了 近 800 个恶意包，全部内置跨平台远控（RAT）与信息窃取能力，同时覆盖 Windows、macOS 与 Linux。Sonatype 同步以 「Flooding Dropper」 为名跟踪该活动，统计到的包数量约 850 个。这些包用「AI 生成的随机名」或「刻意拼错的仿冒名」伪装自己，混在海量正常包里几乎无法靠肉眼识别。

但值得研发团队警惕的是它的触发方式变了。过去几年绝大多数 npm 投毒都走 preinstall / postinstall 生命周期钩子——npm install 那一刻恶意代码就跑起来，因此各家 SCA、沙箱安装检测都把火力压在「安装期行为」上。而这批包不带任何安装钩子，它们在 README 里写清楚使用方法，引导开发者用 require() 把包引入业务代码。也就是说：装进 node\_modules 时它是完全安静的，只有当你真的写下那行 require，攻击链才启动。

事件基础信息

供应链投毒 跨平台 RAT 绕过安装期检测 DNS TXT 隐蔽下发 ETW / AMSI 致盲 Sliver C2

攻击手法一：不用安装钩子，改用 README 社工

这是本次事件最需要被记住的技术点。传统 npm 投毒的心智模型是「安装即中招」，所以防线自然落在安装环节：--ignore-scripts、安装沙箱、install-time 行为监控。而这批包把执行时机整体后移了一步。

两种触发模型对比传统模型：安装即执行（易被拦截）npm installpreinstall / postinstall恶意代码执行✓ 安装期扫描 / 沙箱可捕获本次模型：引用即执行（绕过安装期检测）npm install静默落盘（无任何钩子）require('pkg')✗ 安装期无异常 · 开发者亲手触发

攻击者把执行时机从「安装期」推迟到「引用期」，安装阶段的扫描与沙箱因此全部失灵。

为什么这招有效：README 是开发者最信任、也最不设防的位置。「装完之后请这样引入」本身就是完全正常的文档表达，安全工具无法把一段使用说明判定为恶意。于是恶意代码的执行动作，被外包给了开发者自己——只依赖 --ignore-scripts 的防护策略，在这类攻击面前等于零。

攻击手法二：WEL1DROPPER 的双通道下发

一旦 require() 被执行，名为 WEL1DROPPER 的下载器就开始工作。它的第一步是指纹识别：判断宿主机的操作系统类型与处理器架构，再据此拉取匹配的载荷。下发通道有两条，主通道走 Cloudflare Workers 的 HTTPS，失败后自动降级到 DNS TXT 记录传输。

双通道载荷下发机制WEL1DROPPEROS + 架构指纹识别主通道HTTPS 失败后降级① HTTPS · Cloudflare Workersoob-worker.cf103-070.workers.devoob-worker.cf102-baf.workers.devoob-worker.cf99-9b3.workers.dev② DNS TXT · wel1.ruc. → 分块数（1~2000）逐块请求 TXT → 字符串拼接Base64 解码 → 还原二进制

HTTPS 通道被阻断时，载荷会以 DNS TXT 记录分块回传——这是很多出网管控策略的盲区。

DNS TXT 分块传输的具体流程

据 McCarty 描述：下载器先向 c.<domain> 请求一条 TXT 记录，把返回值解析为载荷分块的个数（有效范围 1～2000）；随后逐一请求编号 TXT 记录，把所有返回字符串拼接起来，再经 Base64 解码还原成二进制文件。

不同平台对应的下发域名如下：

最后阶段，程序被写入临时目录，Linux / macOS 上通过 /bin/sh 执行，Windows 上通过 cmd.exe 执行，并以独立进程形式脱离原宿主进程运行。

为什么 DNS 通道值得单独关注：大量企业只做了 HTTP/HTTPS 出网代理与域名白名单，却默认放行 53 端口的 DNS 查询。攻击者用 TXT 记录做载荷传输，等于在「已被允许的协议」里开了一条隐蔽下载信道，绕过了绝大多数基于 Web 代理的管控。

攻击手法三：落地行为拆解

Sonatype 的分析显示，最后阶段以独立进程实施，三个平台各有针对性的对抗与持久化设计。

三平台落地行为对比Windows· 修补 ETW / AMSI 致盲监控· 检测沙箱与虚拟机环境· 注册表启动项 + 计划任务· 下载加密载荷并执行/pkg/update\_win.exemacOS· 检测调试器与分析痕迹· 远程拉取信标程序· 失败则回落 DNS TXT 通道· LaunchAgent 持久化/pkg/beacon\_mac.binLinux· UPX 加壳 ELF 二进制· 从 CF Worker 拉取辅助包· 最终部署 Sliver C2开源命令与控制框架cf99-9b3.workers.dev

Windows 侧的 ETW / AMSI 修补与 macOS 侧的反调试检测，说明攻击者对终端侧检测机制有清晰认知。

• Windows：

尝试修补 Windows 事件跟踪（ETW）与反恶意软件扫描接口（AMSI），直接干扰终端监控与脚本检测能力；同时检测沙箱 / 虚拟环境，通过注册表项 + 计划任务双保险实现持久化；最后下载加密载荷 /pkg/update_win.exe 并执行。
* macOS：

执行同类反分析检查（调试器、分析痕迹），从远程服务器拉取 /pkg/beacon_mac.bin；若失败则回落到前述 DNS TXT 传输，通过 LaunchAgent 实现持久化，以独立进程运行。
* Linux：

样本为 UPX 加壳的 ELF 二进制，从 Cloudflare Worker 地址下载辅助数据包，最终部署 Sliver —— 一个成熟的开源命令与控制（C2）框架，具备完整的会话管理、隧道与后渗透能力。

ETW / AMSI 被修补意味着什么：ETW 是 Windows 上 EDR 采集进程、网络、脚本行为的核心数据源，AMSI 则是 PowerShell / 脚本内容扫描的入口。二者一旦在进程内被打补丁，运行在该进程上下文中的恶意行为对多数终端安全产品就变成了「看不见」的状态。这已经不是脚本小子级别的载荷。

攻击手法四：假 telemetry.js 制造噪音

这些包中还额外携带一个名为 lib/telemetry.js 的文件。它表面上是一个用于上报遥测数据的 SDK，实际内部包含与下载器完全相同的逻辑代码。

有意思的是，OpenSourceMalware 指出：包的入口点并未导入这个文件，其中也没有任何硬编码的基础设施地址。换句话说，它不参与真正的攻击链，纯粹是个诱饵。

「这种过度复杂的遥测机制似乎是为了制造干扰，让恶意行为看起来像是一种正常的性能分析或监控功能，从而在初步审查时难以被察觉。」——OpenSourceMalware

这是一种针对人工代码审计与自动化检测的双向对抗：对人，它把「网络请求 + 编解码 + 进程启动」这些高危特征包装成合理的埋点采集；对机器，它制造大量相似但无害的代码路径，稀释告警的信噪比。审计者看到 telemetry 这个词，警觉性天然会下降一档。

攻击者是谁？

macOS 恶意软件中出现了 tcsbank[.]ru 与 cloudpayments[.]ru 这类域名——分别指向俄罗斯的银行与移动支付服务。研究者据此推测，该行动很可能针对俄罗斯的金融机构与移动支付系统。

2026 年 4 月初 · Moika 行动：超过 250 个恶意包被上传至 npm，采用依赖混淆（dependency confusion）手法，窃取环境信息并投放针对特定操作系统的第二阶段载荷。

2026 年 8 月 7 日 · 本次行动：包数量翻了三倍（近 800 / 约 850），触发方式改为 README 诱导 require()，新增 DNS TXT 降级通道、ETW / AMSI 对抗与 Sliver C2。研究者判断这很可能是 Moika 的升级版。

需要提醒的是：「疑似目标是俄罗斯金融机构」不等于其他地区的开发者安全。恶意包本身是无差别公开投放在 npm 上的，任何人都可能因为一次拼错的包名或一次 AI 推荐的依赖而中招——载荷里的窃取与远控能力对所有中招者一视同仁。

不只是 npm：同期还有这些供应链攻击

本次披露之前，Palo Alto Networks 的 Unit 42 团队已发现多起针对 npm 与 PyPI 的攻击行为，攻击者来自多个不同团伙：

1. 10 个 npm 包：加密货币窃取 + RAT

这批包会导出一个 getPlugin 函数，该函数动态构建载荷 URL，下载一段经过混淆、嵌在 JSON 对象里的 IIFE JavaScript 代码。Unit 42 指出，该载荷实为加密货币窃取工具与远程访问木马，攻击者可借此在受感染主机上执行任意命令。

2. 跨 npm / PyPI 的多团伙恶意包

• 窃取云端凭证信息；
• 部署基于 EtherHiding 技术的区块链 C2（把 C2 地址写在链上，难以下线）；
• 通过 Telegram 外传 Solana 钱包私钥；
• 窃取 .env 文件中的敏感配置；
• 利用伪造 CAPTCHA 做社会工程，诱导用户执行命令实现 RCE；
• 窃取 Discord 令牌与 GitHub Actions CI/CD 凭证。

CI/CD 凭证是最痛的一环：一旦 GitHub Actions 的凭证被窃取，攻击者就获得了「以你的身份发布软件包」的能力——这正是供应链攻击自我扩散的燃料。单点中招会迅速变成对下游所有用户的批量投毒。

从软件包到浏览器扩展：你的浏览器成了爬虫代理

Unit 42 还观察到，威胁行为者利用一批 Chrome 扩展程序——伪装成游戏模拟器、密码管理工具、效率工具、CSS 查看器或 Markdown 转换器——把用户的浏览器变成了网络爬虫的出口代理。

这些扩展使用了同一款商业「带宽共享」SDK，把用户浏览器接入第三方住宅代理网络。具体行为是：通过持久 WebSocket 连接接收远程爬取指令，向用户浏览器的各个标签页注入隐藏 iframe，在后台把页面内容转换成 Markdown 格式，再发送到远程云服务器。

浏览器 → 住宅代理爬虫节点伪装扩展模拟器 / 密码管理CSS 查看 / MD 转换带宽共享 SDKWebSocket 长连接接指令注入隐藏 iframe远程云服务器页面转 Markdown 回传用户 IP 承担爬取风险

爬取流量从用户的真实住宅 IP 发出，风险与责任被转嫁给了毫不知情的浏览器主人。

值得注意的是，部分扩展确实在 Chrome Web Store 描述和 SaaS 网站隐私政策中提到了这一做法，安装后也会弹出同意提示。但 Unit 42 指出，一些扩展把这种「同意」包装成保障服务不中断的必要步骤——用户若拒绝，代理与爬取功能无法使用。典型例子是 InstaSkip（扩展 ID：mdondgockboebafloibbhjofmoedmnnn）。

这类风险的特殊性：它游走在「恶意软件」与「合规灰产」之间——技术上有披露、有同意弹窗，法律上未必构成违法，但用户实际承担的是自己 IP 被用于大规模爬取的连带风险（IP 被封、被溯源、企业网络出现异常外联）。企业环境下应通过扩展白名单策略统一管控。

企业自查步骤

1. 排查近期新增的可疑依赖

重点看近 3 个月内新增、下载量极低、包名怪异（随机字符串、常用包的拼写变体）、发布者账号无历史信誉的依赖：

`# 列出完整依赖树，重点看间接依赖
npm ls --all

检查锁文件中近期新增的条目

git log -p --since=\"3 months ago\" -- package-lock.json

查看某个可疑包的发布时间与维护者

npm view  time maintainers versions`

2. 全局检索可疑引用与文件

本次攻击必须由代码中的 require() 触发，因此代码里的引用点就是最直接的中招证据：

`# 在 node_modules 中搜索诱饵文件
find node_modules -name \"telemetry.js\" -path \"/lib/\"

搜索 IoC 域名关键字

grep -rniE \"wel1\.ru|oob-worker|cf99-9b3|cf102-baf|cf103-070\" node_modules/ src/`

3. 网络侧回溯 IoC

在 DNS 日志、防火墙日志、代理日志中回溯以下指标（DNS 日志优先，因为降级通道走的就是 DNS）：

4. 终端侧持久化排查

• Windows：

检查注册表 Run 键值与计划任务中的可疑条目，排查临时目录下的异常可执行文件；
* macOS：

检查 ~/Library/LaunchAgents 与 /Library/LaunchAgents 下的新增 plist；
* Linux：

排查 UPX 加壳 ELF 文件、异常常驻进程与 crontab / systemd 用户级服务。

5. 浏览器扩展清点

在企业终端上清点已安装的 Chrome 扩展，重点关注权限过大（`）、来源不明的「工具类」扩展，先行移除InstaSkip` 等已点名的扩展。

防护建议：把防线从「安装期」延伸到「引用期」

本次事件的核心启示是：只盯安装钩子的防护模型已经过时。处置建议按优先级排列如下。

1. 不要只依赖 --ignore-scripts：

它对本次攻击完全无效。它仍应保留（能挡住传统投毒），但必须叠加其他手段。
2. 依赖引入走审批 + 私有源代理：

企业内部搭建 npm 私服（Nexus / Verdaccio / Artifactory），只允许经审核的包进入内网源，切断「随手 npm install 一个陌生包」的路径。
3. 锁定版本与完整性校验：

强制提交 package-lock.json，CI 中使用 npm ci 而非 npm install，确保构建可复现、依赖不漂移。
4. 把 SCA / 恶意包检测接入 CI：

在流水线中加入软件成分分析与恶意包情报比对，对新增依赖做强制卡点，而不是事后扫描。
5. 管控 DNS 出网：

研发网、构建机的 DNS 请求收敛到内部递归服务器并留存日志；对异常 TXT 查询频率、超长子域名建立告警规则。
6. 构建环境隔离：

CI Runner、构建容器使用一次性环境，最小化出网权限，避免开发机凭证与生产凭证共存于同一台机器。
7. 保护 CI/CD 凭证：

npm token、GitHub Actions Secrets 使用最小权限与短有效期；发布流程启用双人复核与 provenance 签名，防止中招后被用于二次投毒。
8. 警惕「AI 推荐的依赖」：

本次包名大量使用 AI 生成的随机名与仿冒名，而 AI 编程助手推荐一个不存在或拼错的包名（package hallucination）恰恰是攻击者抢注的温床。AI 建议的依赖必须人工核实一次上游仓库与下载量。
9. 浏览器扩展白名单：

企业终端通过策略限制可安装的扩展范围，禁止未经审批的第三方扩展。

已确认中招怎么办：立刻断网隔离受影响主机 → 清理持久化项（注册表 / 计划任务 / LaunchAgent / cron）→ 轮换该机器上出现过的全部凭证（npm token、GitHub token、云 AK/SK、SSH 私钥、.env 中的密钥）→ 排查是否有以该身份发起的异常发布或提交 → 最后再考虑系统重装。凭证轮换的优先级高于系统重装，因为信息窃取的动作在你发现之前早已完成。

几点值得记住的判断

数量不再是门槛：800 个包意味着投毒已经完全工业化——AI 生成包名、批量注册账号、自动化发布，攻击成本趋近于零。指望「靠人眼识别可疑包名」不现实。

攻击者在研究防御方，而不是相反：放弃安装钩子、改走 README 社工、增加 DNS 降级通道、修补 ETW/AMSI、加假 telemetry 干扰审计——每一步都精准针对现有防线的已知形态。

开发者本人成了执行环节：这类攻击把最后一步交给受害者亲手完成，绕开了几乎所有自动化管控。安全意识不再是「软性建议」，而是链路上的硬性一环。

开源 C2 降低了后渗透门槛：Sliver 这类成熟框架的存在，让攻击者不必自研控制端就能获得完整的后渗透能力，投毒与实战之间的距离被极大压缩。

开发机是最肥的目标：它同时拥有源码、生产凭证、云密钥与发布权限。攻破一台开发机的收益，远大于攻破一台业务服务器。

提示：本文所述事件信息整理自 The Hacker News、OpenSourceMalware、Sonatype 与 Palo Alto Unit 42 的公开披露，IoC 与影响范围请以各厂商官方通告及持续更新为准；处置动作请结合自身环境评估后执行。

当攻击者把执行动作交给开发者自己完成时，所有停留在「安装期」的防线都会同时失效。依赖治理不是装个扫描器就结束的事，它是从选包、引入、构建到发布的一整条链路。后续我们会持续分享组件供应链安全、AI 编程工具安全与企业安全体系建设的落地实操，欢迎点赞、分享、收藏、转发！

AGI 安全 · 企业 AI 安全专项培训

针对开源投毒、组件供应链风险、凭证泄露与合规漏洞

我们提供完整的企业 AI 安全培训体系，助力企业建立完整的安全防护能力

如需定制企业内部安全培训、开源组件风险排查，欢迎扫码咨询

联系人：马老师 ｜ 微信：AICodingC ｜ 公众号：AGI安全