ChainDrop蠕虫npm供应链入侵:完整溯源、一键排查脚本与防御加固实战

发布时间:2026/8/30 23:09:22
ChainDrop蠕虫npm供应链入侵:完整溯源、一键排查脚本与防御加固实战 前言2026年8月4日npm生态爆发近年最严重的供应链蠕虫攻击——ChainDropShai-Hulud最新变种。不同于普通恶意包单点投毒这次攻击具备完整的自主传播、凭据窃取、持久驻留、自残反制、无域名C2通信能力。攻击者攻陷keyv、cacheable系列核心缓存包维护者账号通过官方可信流水线发布带合法SLSA3签名的恶意版本累计感染npm平台400包、1300版本月度总下载量突破20亿次。绝大多数企业和开发者的中招场景都不是直接依赖恶意包而是通过项目底层传递依赖被动带入隐蔽性拉满。本次事件最致命的两个核心痛点也是绝大多数排查文档遗漏的关键第一恶意包自带官方合法签名常规安全校验、依赖检测工具会直接放行第二蠕虫内置自残机制未隔离环境下直接轮转凭据、吊销令牌会触发本地全盘文件擦除造成二次业务灾难。市面上多数科普内容只讲事件表象没有完整的攻击链路拆解、落地排查步骤、一键检测脚本、长期加固方案。本文从第一性原理出发还原完整攻击逻辑通过对抗式审查梳理全流程风险点提供从应急止损、机器查杀、凭据轮转、批量审计、长期防御的全链路实战方案所有脚本、配置、操作步骤均可直接复制落地。一、事件核心基础信息精准无冗余1.1 攻击核心属性攻击家族Shai-Hulud 蠕虫家族ChainDrop 最新变种爆发时间2026年8月4日 UTC 09:35–13:20所有恶意版本均在此窗口发布入侵载体keyv、cacheable-request、flat-cache、file-entry-cache 等底层缓存核心包感染规模npm 400 公开包、1300 迭代版本覆盖绝大多数Node.js、前端工程核心特征可自我传播的供应链蠕虫、合法SLSA3签名伪装、无域名以太坊C2、凭据窃取持久驻留自残反制影响终端开发者本地电脑、所有CI/CD构建机GitHub Actions、GitLab CI、Jenkins、Gitee Actions1.2 普通开发者/企业的中招误区很多团队自查后认为自己安全本质是认知漏洞而非设备安全。误区1项目package.json没有直接写keyv、cacheable依赖就不会中招。事实是webpack、vite、axios、缓存工具等数百个常用包均依赖该系列组件传递依赖会静默带入恶意版本。误区2开启依赖安全扫描、SLSA校验即可拦截。事实是攻击者攻陷官方维护账号与流水线恶意包的签名、构建链路、发布记录全部合法常规安全工具无法识别。误区3发现异常直接吊销token、修改密码即可止损。事实是蠕虫内置监控脚本检测到令牌吊销会立即触发本地文件擦除直接破坏工作机与构建环境。误区4卸载恶意依赖即可清除风险。事实是恶意载荷会落地持久化脚本、篡改Git配置、植入后台监控进程单纯卸载依赖无法彻底清除。二、ChainDrop蠕虫完整攻击链路溯源第一性原理拆解所有供应链攻击的核心逻辑不变高可信底层依赖投毒 → 静默自动执行 → 权限窃取 → 横向扩散 → 持久控制。ChainDrop的突破点是把每一个环节的对抗规避做到了极致完全贴合正规开发流程规避绝大多数安全策略。2.1 攻击入口高价值底层包账号失陷攻击者未使用漏洞利用、钓鱼链接等常规攻击手段直接拿下keyv与cacheable系列包的维护者GitHub与npm账号。这类包具备两个顶级攻击价值一是底层基础组件几乎所有前端、Node项目都会间接依赖受众极广二是迭代频率高版本更新属于正常行为不会触发人工风控告警。拿下账号权限后攻击者直接修改仓库源码植入恶意代码通过原生GitHub Actions流水线自动构建、签名、发布新版本。整个发布流程完全合规生成的SLSA3 Provenance签名真实有效主流供应链安全工具、镜像仓库校验机制全部判定为可信包。2.2 触发机制合法npm preinstall钩子静默执行攻击者在恶意版本的package.json中植入preinstall生命周期钩子这是npm原生合法功能用于安装依赖前执行自定义脚本。只要开发者或CI机器执行任意npm install、pnpm install、yarn install命令无需用户授权、无需弹窗确认恶意setup.mjs载荷会自动运行。这也是本次攻击传播速度极快的核心原因——完全依托常规开发操作零感知触发。这里存在一个关键版本差异npm 12及以上版本默认禁用preinstall自动执行逻辑可天然免疫本次攻击npm 11及以下版本默认开启脚本执行属于高危版本。2.3 载荷执行链路双层规避架构绕过终端防护蠕虫采用两段式dropper架构专门规避Node专属EDR、终端杀毒、进程监控工具规避逻辑极具针对性。第一阶段前置检测与环境过滤。载荷启动后首先校验系统区域主动规避俄语系地区IP与设备规避溯源与区域性安全监测随后检测当前运行环境区分本地开发机与CI构建机适配不同窃取策略。第二阶段 runtime逃逸规避。恶意脚本不会直接通过Node.js运行会自动下载Bun运行时通过Bun加载混淆后的核心恶意载荷math_init.js。绝大多数终端安全工具仅针对Node进程做行为监控完全无法识别Bun进程的恶意行为实现精准绕过。2.4 核心窃密能力全维度凭据搜刮第二阶段载荷启动后会全盘扫描本地与环境变量中的各类密钥凭据覆盖开发者与企业生产所有核心权限体系具体包括1. 研发账号凭据npm发布Token、GitHub个人访问令牌PAT、Git账号密码、SSH公私钥2. 云资源凭据AWS密钥、Azure、GCP云服务令牌、K8s集群ServiceAccount密钥、Pod临时凭据3. 安全基础设施HashiCorp Vault密钥、各类加密服务令牌4. 业务私有凭据本地.env文件、数据库连接串、第三方API密钥、Slack、Stripe等平台密钥5. CI临时凭据读取GitHub Actions Runner内存抓取构建过程中的临时授权Token与机密变量。窃取的数据会经过AES-256-GCM加密RSA-4096密钥封装双重加密处理避免明文传输被流量检测工具捕获。2.5 数据外渗无域名C2架构传统防护彻底失效本次蠕虫最顶尖的对抗设计是抛弃了传统恶意程序的域名、IP C2架构彻底规避域名黑名单、IP封禁、流量审计机制采用双路无特征外渗方案。第一路GitHub死信仓库投递。蠕虫利用窃取的受害者GitHub令牌在受害者账号下自动创建公开仓库仓库固定携带「Shai-Hulud: Here We Go Again」签名描述将加密后的凭据数据上传至仓库实现数据落地。整个过程依托GitHub合法流量无法通过流量特征识别恶意行为。第二路EtherHiding以太坊智能合约动态C2。攻击者无需固定服务器域名与IP通过以太坊公开智能合约动态解析C2地址实时更新控制节点。载荷无需修改即可自适应C2节点切换溯源与拦截难度极大。2.6 蠕虫自传播能力实现供应链链式感染这是本次攻击被定义为「蠕虫」而非普通木马的核心依据。传统恶意包仅能被动等待用户安装而ChainDrop具备主动横向扩散能力。蠕虫窃取受害者npm发布权限后会自动遍历该账号名下所有公开npm包批量植入preinstall恶意脚本自动推送新版本。单个账号失陷后会瞬间感染其名下所有依赖包形成链式扩散这也是短时间内400npm包集体沦陷的核心原因。2.7 持久驻留自残反制锁死受害者止损路径为防止用户查杀与凭据轮转蠕虫部署了双重兜底机制大幅提升处置难度。持久化方面落地gh-token-monitor.sh监控脚本写入本地~/.local/bin目录配置开机自启与定时监控任务同时篡改VSCode、AI代码助手配置文件实现长期驻留单纯重启设备无法清除。自残反制方面监控脚本实时校验本地令牌有效性。一旦检测到用户在当前机器吊销GitHub、npm令牌未做隔离直接止损会立即触发全盘文件擦除逻辑销毁本地代码、配置、密钥文件造成不可逆数据损失。2.8 完整攻击流程架构图攻击者GitHub/npm维护账号CI/CD构建机开发者本地机以太坊C2GitHub死信仓库攻陷维护者账号权限源码植入preinstall恶意脚本官方流水线发布带SLSA3签名恶意版本官方流水线发布带SLSA3签名恶意版本执行npm install触发preinstall执行npm install触发preinstall下载Bun运行时规避Node监控执行混淆核心载荷全盘扫描凭据RSAAES加密外渗各类密钥RSAAES加密外渗CI临时令牌利用窃取Token批量感染用户名下npm包落地监控脚本实现持久驻留检测令牌吊销触发本地文件擦除攻击者GitHub/npm维护账号CI/CD构建机开发者本地机以太坊C2GitHub死信仓库三、高危恶意版本精准清单唯一可信查杀依据全网所有非此清单的版本均为安全版本无需盲目升级降级避免业务故障。以下为2026年8月4日爆发的全部恶意迭代版本精准匹配可查杀所有感染节点。keyv6.0.0唯一恶意版本5.x全系安全flat-cache6.1.24file-entry-cache11.1.6cacheable-request13.0.20上述包的衍生子包、关联依赖包同步被植入恶意代码只要项目锁文件中存在以上版本无论是否执行脚本、是否运行业务机器全部判定为失陷状态必须全面排查清理。四、企业/个人全流程应急处置实战严格顺序不可逆本节为核心落地内容所有操作经过对抗式审查严格遵循先止损、再查杀、后轮转、终加固逻辑顺序错误会直接触发自残机制导致数据损毁、权限彻底失控。所有命令可直接复制批量执行。4.1 第一步环境隔离阻断扩散杜绝自残触发所有疑似、已感染机器立即断网禁止任何网络访问。重点隔离所有开发工作站、Jenkins、GitHub Actions自建Runner、GitLab CI构建机。隔离核心红线未完成持久化恶意文件清理前绝对不能在当前机器吊销、修改、轮转任何凭据。临时规避配置全局禁用npm脚本执行阻断后续载荷触发# 全局禁用所有npm生命周期脚本npmconfigsetignore-scriptstrue# pnpm/yarn同步禁用pnpmconfigsetignore-scriptstrueyarnconfigsetignore-scriptstrue4.2 第二步一键批量检测机器感染状态提供完整可复用检测脚本自动扫描依赖锁文件、本地恶意持久化文件、Git异常配置、系统定时任务输出完整感染报告。#!/bin/bash# ChainDrop/Shai-Hulud 一键感染检测脚本echo 开始检测ChainDrop蠕虫感染特征 # 1. 检测恶意依赖版本echo-e\n[1] 检测恶意npm依赖版本grep-Ekeyv6.0.0|flat-cache6.1.24|file-entry-cache11.1.6|cacheable-request13.0.20package-lock.json yarn.lock pnpm-lock.yaml2/dev/null# 2. 检测持久化恶意监控脚本echo-e\n[2] 检测本地持久化恶意文件ls-la~/.local/bin/gh-token-monitor.sh2/dev/null# 3. 检测Git恶意配置篡改echo-e\n[3] 检测Git异常配置与提交规则gitconfig--getcore.excludesfile2/dev/null|grep-Econfig.batgitlog--oneline|grep-ishai-hulud\|chaindrop2/dev/null# 4. 检测Bun异常安装记录蠕虫依赖运行时echo-e\n[4] 检测Bun异常安装进程与文件ls-la~/.bun2/dev/nullpsaux|grep-ibun|grep-vgrep# 5. 检测CI Runner恶意残留echo-e\n[5] 检测GitHub Runner恶意节点grep-rSHA1HULUD~/.github/runner/2/dev/nullecho-e\n 检测完成存在以上任意特征即为感染机器 4.3 第三步彻底清除恶意持久化文件与缓存检测出感染特征后执行以下清理脚本彻底删除蠕虫驻留文件、系统任务、包缓存杜绝后台静默运行。#!/bin/bash# ChainDrop 一键清除脚本echo 开始清除ChainDrop蠕虫残留 # 删除核心监控恶意脚本rm-rf~/.local/bin/gh-token-monitor.sh# 清空npm/pnpm/yarn全局缓存、项目缓存npmcache clean--forcepnpmstore pruneyarncache clean# 删除Bun恶意运行时残留rm-rf~/.bunrm-rf/tmp/bun*# 清理系统定时任务与开机自启残留crontab-l|grep-vgh-token-monitor|crontab-rm-rf~/.config/systemd/user/gh-monitor.servicerm-rf~/Library/LaunchAgents/com.gh.monitor.plist# 重置Git恶意配置gitconfig--unsetcore.excludesfile2/dev/nullrm-rf.gitignore.bakecho-e\n 恶意文件清除完成 企业CI场景必须额外操作清空所有构建节点的共享缓存、镜像缓存、Runner工作目录重建基础构建镜像避免缓存复用导致二次感染。4.4 第四步锁定安全依赖版本杜绝复发通过package-lock.json强制锁定安全版本禁止恶意版本迭代更新适配所有项目工程。# 强制覆盖锁定为安全版本npmoverrides keyv6.0.0 keyv5.6.0npmoverrides flat-cache6.1.24 flat-cache6.1.23# 重新生成干净锁文件rm-rfpackage-lock.json node_modulesnpminstall--ignore-scripts安全版本锚定keyv固定5.6.0、flat-cache固定6.1.23其余关联包锁定恶意版本前最后一个稳定版。4.5 第五步干净环境统一凭据轮转核心风控动作绝对准则所有凭据轮转操作必须在从未执行过npm install、未感染的全新干净机器操作杜绝触发自残擦除机制。需要100%轮转的全量凭据清单无遗漏1. 研发账号GitHub所有PAT令牌、npm发布Token、Git SSH公私钥、Gitee/代码仓库权限令牌2. 云服务权限AWS AccessKey、Azure/GCP服务账号密钥、阿里云/腾讯云API密钥3. 容器与运维K8s所有ServiceAccount令牌、集群访问凭证、kubectl配置4. 安全组件HashiCorp Vault所有访问令牌、加密服务密钥5. CI/CD体系Jenkins、GitHub Actions、GitLab CI所有Secret密钥、构建临时权限6. 业务私有凭据项目.env文件所有密钥、数据库连接串、第三方支付/推送API密钥。所有旧凭据操作完成后立即吊销禁止保留任何有效旧权限防止攻击者复用窃取凭据二次入侵。4.6 第六步全维度安全审计排查横向入侵凭据轮转完成后必须开展全链路审计确认攻击者未利用窃取权限横向扩散、篡改代码、留存后门。1. GitHub审计核查账号登录日志、异地登录记录、仓库推送记录、标签版本发布记录、Workflow执行记录重点排查8月4日前后的异常版本提交2. npm仓库审计核查账号名下所有包的版本发布记录、批量迭代记录排查蠕虫自动发布的恶意patch版本3. 云平台审计核查所有云资源的访问日志、权限变更记录、密钥调用记录排查异常IP、异常时间的非法访问4. 代码审计全局检索项目代码、Git提交记录排查preinstall脚本、setup.mjs、Bun运行指令等恶意代码特征5. 内网审计扫描所有开发机、服务器、CI节点排查持久化监控脚本、异常定时任务、未知进程。五、攻击对抗技术深度拆解对抗式审查核心抛开表面现象从对抗视角拆解本次蠕虫的核心突破点理解防护失效的底层原因才能搭建有效长期防御体系。5.1 SLSA可信签名体系的彻底失效原因行业普遍认为SLSA3签名可保障供应链安全本次攻击直接击穿该认知。SLSA校验的是构建流程合法性而非代码内容安全性。攻击者攻陷官方流水线后恶意代码的构建、签名、发布流程完全合规签名真实有效所有依赖SLSA校验的安全设备、平台都会放行。这意味着单纯依赖官方签名、平台认证的供应链防护思路存在根本性缺陷必须叠加代码行为检测、版本异常监测、脚本执行管控多层策略。5.2 Bun运行时逃逸的对抗逻辑目前绝大多数企业终端EDR、主机安全工具规则库仅针对Node.js进程的恶意行为建模对Bun运行时的监控几乎空白。蠕虫主动下载Bun执行载荷相当于切换到安全工具的监控盲区完美规避进程行为审计、脚本静态检测。同时Bun的代码执行效率更高、混淆容错性更强适配蠕虫的混淆载荷运行进一步提升逆向分析与查杀难度。5.3 以太坊C2无特征通信优势传统恶意程序的域名、IP、端口均有固定特征可通过防火墙、流量审计、威胁情报库拦截。ChainDrop使用以太坊智能合约动态解析C2地址无固定服务器、无固定域名、无固定流量特征流量完全混入正常区块链网络请求现有安全设备无法识别拦截。只要攻击者不主动废弃合约C2节点可无限迭代变更溯源和拦截基本无解只能从终端载荷与凭据层面兜底防护。5.4 自残机制的对抗价值常规恶意程序的处置逻辑是「查杀→改密码→轮转凭据」蠕虫通过自残机制直接颠覆该流程逼迫用户陷入两难不轮转凭据则权限持续泄露轮转凭据则本地数据被毁。这也是本次事件造成大量企业处置卡顿、损失扩大的核心原因。六、企业长期供应链安全加固方案可落地制度配置本次事件暴露的不是单一包漏洞而是整个Node.js/npm供应链的通用安全短板。以下加固方案适配个人开发者、中小企业、大型研发团队全部可直接落地无空泛理论。6.1 npm全局安全配置全员强制开启永久禁用自动脚本执行从源头阻断preinstall、postinstall类恶意载荷触发适配所有项目。# 全局默认禁用所有生命周期脚本npmconfigsetignore-scriptstrue--globalpnpmconfigsetignore-scriptstrue--globalyarnconfigsetignore-scriptstrue--global# 升级npm至安全版本12默认禁用preinstall自动执行npminstall-gnpmlatest业务如需依赖合法脚本采用白名单机制单独放行禁止全局放开脚本执行权限。6.2 CI/CD流水线专项加固企业核心防线1. 构建节点最小权限CI Runner禁止配置npm发布Token、Git高权限令牌、云服务密钥构建环境仅保留编译、打包权限无发布、访问生产资源权限2. 缓存强制清理所有CI流水线新增前置步骤每次构建强制清理依赖缓存、镜像缓存杜绝恶意缓存复用3. 脚本执行严控CI构建命令统一添加--ignore-scripts参数禁止构建过程自动执行依赖脚本4. 版本异常监控监控npm账号短时间批量发布新版本、短时间大量patch迭代的异常行为触发人工审核拦截。6.3 账号与权限体系加固1. 所有包维护者、核心研发账号强制开启硬件MFA关闭密码登录、短信登录杜绝账号被盗2. 所有Git、npm令牌按需授权、短时有效期禁止永久有效令牌最小权限分配3. 区分开发、构建、发布权限构建账号无发布权限发布账号无代码修改权限权限拆分隔离。6.4 终端与主机安全加固1. 终端安全工具新增Bun运行时进程监控、未知脚本执行告警补齐监控盲区2. 监控本地~/.local/bin目录、系统定时任务、开机自启项的异常新增文件实时告警3. 禁止开发机存储生产级密钥、高权限令牌杜绝单点失陷造成全域风险。6.5 私有镜像仓库加固企业内部npm镜像仓库开启版本白名单拦截本次恶意版本及后续衍生恶意版本定期批量扫描所有缓存包清理投毒版本禁止瞬时新版本自动同步设置版本冷却时间拦截蠕虫批量快速发包。七、全网通用IOC特征库批量查杀适配整理本次ChainDrop蠕虫全部精准IOC特征可直接导入安全设备、EDR、扫描工具实现批量监测查杀。恶意文件特征setup.mjs、math_init.js、gh-token-monitor.sh恶意路径特征~/.local/bin/gh-token-monitor.sh恶意进程特征Bun运行未知混淆脚本、SHA1HULUD命名Runner进程恶意仓库签名Shai-Hulud: Here We Go Again恶意版本特征keyv6.0.0、flat-cache6.1.24、file-entry-cache11.1.6、cacheable-request13.0.20八、复盘供应链攻击的底层防御启示本次ChainDrop事件彻底暴露了前端/Node生态的核心安全短板开发者长期依赖海量底层开源依赖却默认信任所有官方包、正规渠道版本将供应链安全完全交由平台与开源维护者自身无任何校验与防护能力。SLSA签名、平台认证、依赖扫描只能解决「恶意第三方伪造包」的问题无法解决「官方合法包、官方流水线投毒」的顶级风险。当维护者账号失陷、官方链路被掌控所有传统浅层防护全部失效。真正有效的供应链防御核心是不信任任何外部依赖不信任签名、不信任版本、不信任渠道只信任自身可控的版本锁定、脚本管控、权限隔离、行为监控。对于所有企业研发团队必须建立常态化依赖审计机制底层基础包迭代、传递依赖版本更新、陌生脚本执行、批量版本发布全部纳入安全风控范围不再被动等待安全事件爆发后应急处置。互动提问欢迎评论交流1. 你的项目工程是否存在keyv/cacheable系列传递依赖是否已经完成恶意版本排查与锁定2. 你们团队当前是否开启npm全局脚本管控、CI脚本执行限制日常研发中还有哪些供应链安全漏洞