黑客在 Shai-Hulud 供应链攻击中破坏了超过 170 个 npm 软件包

黑客在新的 Shai-Hulud 供应链攻击中破坏了 170 多个 npm 软件包和两个 PyPI 软件包，旨在窃取开发人员凭证、云密钥和 CI/CD 机密。

JFrog 安全研究表示受影响的软件包每周获得超过 2 亿次下载，这使得该事件成为开发团队、构建系统和云环境的主要风险。

该活动被称为“Shai-Hulud：Here We Go Again”，使用恶意 npm 加载程序和 PyPI 导入时有效负载在开发人员机器和自动化管道内运行。一旦激活，恶意软件就会搜索秘密并尝试利用窃取的访问权限传播到更多包中。

该攻击针对的是开发人员和企业构建系统使用的可信软件包。该恶意软件不是直接攻击最终用户，而是专注于开发人员构建和发布软件所依赖的工具和工作流程。

在 npm 生态系统中，受损的软件包携带恶意预安装加载程序和混淆的 JavaScript 有效负载。该有效负载可以在包安装期间运行、获取凭据并查找 npm 发布访问权限。

在 Python 生态系统中，受损的 PyPI 包使用导入时下载程序。这意味着当 Python 脚本导入受影响的包时，恶意代码可能会运行，然后从攻击者控制的基础设施下载远程有效负载。

为什么这次攻击很危险

该活动最令人担忧的部分是其蠕虫般的行为。该恶意软件并不是简单地从受感染的系统中窃取机密并停止运行。

一旦找到 npm 令牌或受信任的发布凭据，它就可以扫描受害者帐户可以发布的包。然后它可以修改这些包、增加其版本号、注入恶意代码并重新发布受感染的版本。

这种方法将可信的开发帐户和发布管道转变为分发渠道。软件包看起来是合法的，因为它来自真实的项目，但发布版本中仍然携带恶意代码。

攻击者如何滥用构建系统

几位研究人员表示，该活动滥用现代 CI/CD 工作流程，而不仅仅是依赖被盗的密码。据报道，在 TanStack 攻击中，攻击者控制的代码通过 GitHub Actions 工作流程行为和缓存中毒达到了可信发布路径。

当后续版本的工作流程恢复中毒的缓存时，攻击者控制的有效负载可以从运行器环境中提取身份令牌。这些令牌帮助通过可信自动化发布恶意软件包版本。

这很重要，因为出处和可信发布系统可以确认包的来源，但它们不能总是证明代码本身是安全的。如果攻击者破坏了构建过程，恶意包仍然可能看起来来自可信来源。

哪些包和项目受到影响

该活动影响了多个知名命名空间和项目的软件包。公共警报和研究帖子命名TanStack、Mistral AI、UiPath、OpenSearch、Squawk，以及受影响地区的 Guardrails AI。

英国 NHS 网络警报已列出示例包括 @tanstack/react-router、@mistralai/mistralai、@opensearch-project/opensearch、@uipath/robot、@tanstack/vue-router、PyPI 上的 Mistralai 2.4.6 和 PyPI 上的 Guardrails-ai 0.10.1。

Wiz 还指出，后来的分析发现了一个有效负载错误，导致一些 @uipath 和 @mistralai npm 案例无法运行。但这并不能消除更广泛的风险，因为团队可能仍然需要在接触恶意软件包后调查暴露情况、清理环境并轮换机密。

恶意软件试图窃取什么

JFrog 说有效载荷看起来跨开发人员机器和云环境的各种秘密。其中包括本地凭据、服务令牌、云元数据、Kubernetes 机密以及开发人员工具使用的配置文件。

该恶意软件针对 GitHub 令牌、npm 凭证、AWS 密钥、GCP 机密、Azure 机密、Kubernetes 服务帐户令牌、HashiCorp Vault 令牌、SSH 密钥、Docker 凭证、Terraform 状态文件、shell 历史记录和 .env 文件。

更新后的 PyPI 负载还针对密码管理器和开发人员工具。 JFrog 表示，它尝试从 1Password、Bitwarden、pass、gopass、Claude Desktop 配置、VS Code MCP 配置、Cursor MCP 配置、Codeium、Continue、OpenCode、Kilo 和 Zed 设置等工具收集数据。

• GitHub 和 npm 令牌
• AWS、GCP 和 Azure 凭证
• Kubernetes 服务帐户令牌
• HashiCorp Vault 代币
• SSH 密钥和 Docker 凭据
• Terraform 状态文件和 .env 文件
• 可访问时的密码管理器条目
• 开发者工具配置文件

紧急开关改变了清理顺序

JFrog 警告称，团队必须在撤销 GitHub 令牌之前删除恶意软件的持久性机制。原因是死人开关可以在被盗访问被撤销时做出反应。

在受影响的系统上，恶意软件可以安装一个后台监视器来检查 GitHub 访问。如果令牌不再有效，它可能会触发机器上的破坏性行为。

这使得响应顺序很重要。团队应首先隔离受影响的机器和 CI/CD 运行程序，删除持久性，确认清理，然后才轮换 GitHub、npm、云、Kubernetes、Vault、SSH 和 Docker 凭据。

开发人员和安全团队应该做什么

任何安装或导入受影响软件包的团队都应将相关环境视为受到威胁。这适用于本地计算机、构建工作人员、CI/CD 运行程序以及可能保守秘密的自动化帐户。

开发人员应删除受影响的软件包版本，检查锁定文件，从干净的映像重建 CI/CD 运行程序，并使可能已恢复恶意内容的构建缓存无效。

安全团队还应该在 GitHub 帐户和组织中搜索可疑存储库、活动标记以及使用异常自动化身份创建的提交。 JFrog 特别建议寻找编写为的可疑提交[电子邮件受保护]以及使用与活动相关的描述的存储库。

1. 隔离受影响的开发人员机器和 CI/CD 运行程序。
2. 删除与恶意软件链接的持久性文件和后台服务。
3. 卸载受影响的 npm 和 PyPI 软件包版本。
4. 检查锁定文件和依赖树中是否存在恶意版本。
5. 从干净的图像重建跑步者。
6. 使中毒的构建缓存无效。
7. 清理后轮换 GitHub、npm、cloud、Kubernetes、Vault、SSH 和 Docker 凭据。
8. 在 GitHub 上搜索可疑的存储库、提交和分支名称。
9. 在网络级别阻止已知的活动基础设施。
10. 在活动保持活动状态时暂停不必要的依赖项升级。

为什么软件供应链攻击不断蔓延

此活动展示了攻击者现在如何瞄准软件交付背后的信任。包管理器、发布工作流程和自动化构建系统可帮助团队快速行动，但它们也创建了攻击者可以滥用的路径。

当恶意包在开发人员环境中运行时，它可能会访问保护源代码、云帐户和生产系统的机密。如果这些秘密允许发布访问，则相同的攻击可以从一个项目转移到下一个项目。

Shai-Hulud 活动还表明了为什么团队不能仅依赖套餐声誉。熟悉的项目名称、有效的发布管道或受信任的命名空间并不能保证特定版本是安全的。

FAQ