剖析Shai-Hulud 2.0:2025年最激进的NPM供应链攻击内幕

本文深入分析了2025年底爆发的“沙虫2.0”大规模NPM供应链攻击。攻击者在数小时内通过恶意包污染了数百个NPM包和数万个GitHub仓库,窃取海量云凭证与开发者密钥,并利用GitHub API进行隐蔽数据外传,对软件开发生态构成严重威胁。

Shai-Hulud 2.0: Inside The Second Coming, the Most Aggressive NPM Supply Chain Attack of 2025

攻击者如何渗透 npm 生态系统,Check Point 研究人员发现了什么,以及组织如何保护其开发流水线。

被称为“第二次降临”的 Shai-Hulud 2.0 攻击活动,是近年来观察到的最广泛、最快速的 npm 供应链攻击之一。在 2025 年 11 月 21 日至 23 日期间,攻击者仅在几小时内就破坏了数百个 npm 软件包和超过 25,000 个 GitHub 仓库。与安装后激活的传统恶意软件不同,此攻击活动滥用了 npm 的 preinstall 生命周期脚本,使得恶意载荷能够在安装完成之前、甚至在安装失败时运行。

查看 CISA 公告 此处

Check Point 研究人员分析了攻击者创建的大量仓库,并确认该攻击活动导致大规模的多云和开发者凭证暴露。在审查的大约 20,000 个仓库中,以下凭证被验证为已暴露:

  • 775 个 GitHub 访问令牌
  • 373 个 AWS 凭证
  • 300 个 GCP 凭证
  • 115 个 Azure 凭证

虽然许多条目是由于在相同的 CI/CD 环境中多次执行而产生的重复项,但仍然存在大量有效且敏感的密钥,说明了此事件的广泛影响。

攻击活动时间线

  • 2025年9月:首次出现 Shai-Hulud 攻击,破坏了 npm 库,导致约 5000 万美元的加密货币被盗。
  • 2025年11月21日至23日:新一波攻击开始。攻击者引入了扩展的载荷、新的传播方法和更广泛的自动化。
  • 2025年11月24日:安全供应商开始发布警报,确认 npm、CI 和 CD 环境普遍受到威胁。

Shai-Hulud 攻击的工作原理

感染始于被劫持或恶意发布的受信任或仿冒的 npm 包。一旦开发者安装了受影响的包,恶意代码会在 preinstall 步骤中执行,使攻击者能够早期访问开发或构建环境。

载荷由两个主要组件组成:

  1. setup_bun.js:安装 Bun 运行时。
  2. bun_environment.js:执行核心恶意逻辑。

使用 Bun 而非 Node.js 是一种有意的规避技术。大多数安全工具和沙箱都针对跟踪 Node.js 行为进行了优化,这使得 Bun 成为一种在常见检测路径之外进行操作的诱人方式。

一旦执行,恶意软件会枚举环境变量、SSH 密钥、GitHub 令牌、npm 令牌、CI/CD 变量以及跨 AWS、Azure 和 GCP 的云凭证。这些秘密被收集到结构化的 JSON 文件中,例如 cloud.jsonenvironment.jsonactionsSecrets.json

攻击者不是与外部命令和控制服务器通信,而是将被盗数据外传到 GitHub。他们创建标记为 Sha1-Hulud: The Second Coming 的公共仓库,并将被盗的密钥直接上传到其中。这种技术将恶意活动混入合法的 GitHub API 流量中,使得识别变得异常困难。

随后,恶意软件会建立持久性。它将受感染的系统注册为自托管的 GitHub runner,使攻击者能够远程执行任意工作流。此外,恶意工作流文件可以被插入到受害者的仓库中,以维持长期访问权限,即使后续删除了受感染的包。该恶意软件还包含一个破坏性的故障安全机制,当它检测到被遏制或分析时,能够擦除本地文件。

传播是部分自动化的。被盗的凭证被用来发布新的恶意 npm 包或创建新的 GitHub 仓库,在 JavaScript 生态系统中产生类似蠕虫的扩散。

影响

暴露的规模是巨大的。此次攻击活动导致:

  • 621 个受感染的 npm 包
  • 25,000 个被入侵的 GitHub 仓库
  • 487 个受影响的 GitHub 组织
  • 14,206 个泄露的密钥,其中 2,485 个仍然有效

暴露的数据类型包括 GitHub 和 npm 令牌、SSH 密钥、云提供商凭证以及 CI/CD 密钥。受影响的生态系统涵盖加密相关库、工作流自动化工具和一系列开发平台。

此次攻击活动展示了依赖项级别的破坏如何轻易升级为完全的多云访问、长期的开发者身份暴露以及 CI/CD 工作流的广泛渗透。

建议步骤

使用 npm 的组织应假设可能存在暴露风险,并立即采取行动:

  • 审计依赖清单和锁文件
  • 删除受感染的包并从可信来源重新安装
  • 清除 npm 缓存
  • 轮换在开发和 CI/CD 环境中使用的所有密钥
  • 检查 GitHub runner 并删除任何未经授权或未知的条目
  • 移除存在的恶意工作流文件

预防措施

  • 对所有 GitHub 和 npm 账户强制执行 MFA
  • 监控 GitHub 组织内创建的意外仓库
  • 应用基于 SBOM 的扫描和完整性检查
  • 加强 CI/CD 隔离和密钥处理策略
comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计