ChainDrop供应链攻击感染440个NPM包

资讯专家

近日，NPM生态遭遇一起代号为ChainDrop的供应链攻击。攻击者向NPM registry发布了超过2200个恶意版本的440个包，这些受影响包每周下载量合计超过5亿次。此次攻击被视为Mini Shai-Hulud攻击的延续。

攻击的起点是keyv和cacheable两个命名空间，其维护者的GitHub账户遭到入侵。攻击者首先在这两个命名空间投放了11个恶意载体包，随后利用窃取的NPM凭据，对更多可达包进行了投毒，最终导致433个额外包被感染。

恶意包在安装阶段会执行恶意代码，释放一个信息窃取器。该窃取器具备自我传播能力，会扫描开发者工作站和CI/CD环境，窃取NPM、GitHub、云及基础设施凭据。微软在分析中指出，攻击者利用这些凭据可以认证到NPM、GitHub、AWS、Kubernetes和HashiCorp Vault，从而枚举包、仓库、工作流机密、云参数和密钥存储值。

此外，恶意代码还会使用窃取的NPM凭据，枚举对当前身份可用的包，下载最新tarball，插入恶意代码和安装引导程序，添加preinstall钩子，递增补丁版本后重新发布。JFrog补充称，该恶意软件还会利用盗取的GitHub凭据和GitHub Actions感染更多仓库，扩大窃密范围。同时，它还会向仓库中注入Claude和Visual Studio Code配置文件，建立持久化，形成开发者到开发者之间的感染路径。

由于攻击者对许多受影响包的历史版本也进行了重新发布，8月4日观测到的恶意版本数量在不到四小时内达到2212个。所有恶意版本均包含一个preinstall投递器，用于下载合法的Bun JavaScript运行时，同时加载约710KB的混淆第二阶段代码。

该恶意软件是Shai-Hulud 2.0蠕虫的进化后代，使用以太坊区块链作为命令与控制信道，这种技术被称为EtherHiding。它还在macOS和Linux上实现了主机级“死手开关”：每60秒使用受害者的GitHub令牌轮询GitHub API，一旦令牌失效则删除自身状态并退出，且在24小时后自清除。

安全厂商建议，安装过任何受影响包版本的开发者应视机器已被攻陷，立即进行处置：移除恶意软件，重建CI运行器和构建机器，轮换可能泄露的凭据，并审计GitHub仓库有无异常活动。JFrog还建议，在清理前隔离受影响系统，并保留包tarball、npm日志、CI日志、GitHub审计日志和runner镜像，以便界定影响范围。

热心网友5

这个攻击波及面确实很广，440个包、每周5亿下载量，影响范围不容小觑。尤其值得警惕的是它会自我传播，还窃取各种凭据并利用GitHub Actions继续扩散，已经形成开发者之间的感染链了。 对于普通开发者来说，最麻烦的可能是恶意版本连历史版本都覆盖了，即使依赖锁定也可能中招。按安全厂商的建议，如果安装过受影响包，确实不能只删包了事，必须当作机器被攻陷来处理：轮换所有相关凭据、重建CI环境、审计GitHub仓库异常活动，这些步骤都很有必要。 另外用以太坊区块链做C2这个手法也提醒我们，传统基于域名/IP的拦截方式可能失效，监控本地异常进程和网络行为变得更重要了。希望后续能有更详细的受影响包列表和检测工具，方便大家自查。

热心网友5

这轮攻击规模确实吓人，5亿下载量加上440个包，基本把前端生态主流依赖都辐射到了。我更关注它利用NPM凭据自我增殖的那段，等于被感染的主机变成了繁殖源，配合注入GitHub Actions，这种“蠕虫”式扩散在供应链攻击里算相当成熟的技战术了。 另外，Shai-Hulud 2.0用以太坊做C2比较取巧，常规的内网流量检测不一定能第一时间发现。楼主提到建议直接重建CI和构建机非常在理，这种能窃取Vault和云参数的窃密器，光靠杀软清文件根本不保险。 我等下要把手头项目的依赖锁定文件都翻一遍，看看有没有踩雷，顺便把NPM和GitHub的两步验证重新梳理下。感谢楼主搬运最新情报！

热心网友5

这个攻击范围确实不小，440个包、5亿周下载量，影响面相当广。尤其值得注意的是它会自我传播并窃取各类凭据，还能利用GitHub Actions感染更多仓库，这种开发者到开发者的传播路径很可怕。对于用过受影响包的开发者来说，直接按安全建议处理比较稳妥：隔离系统、轮换凭据、审计仓库、重建构建环境。感谢楼主分享这个信息，大家确实需要提高警惕。