内容提要
Elastic 应对 Shai-Hulud 2.0 npm 供应链攻击,该蠕虫入侵数百个包并窃取数据。Elastic 通过依赖扫描、威胁情报、撤销令牌、冷却期及检测规则快速响应,确认其 CI 管道受影响但客户无碍,已轮换密钥并移除恶意依赖,同时提供狩猎查询建议。
延伸解读
供应链攻击的隐蔽性
Shai-Hulud 2.0 通过 npm 包传播,利用传递依赖关系感染 Elastic 的 CI 管道,而非直接攻击产品。这种攻击方式隐蔽性强,因为开发者往往难以追踪所有间接依赖。Elastic 的响应表明,即使产品本身不包含 npm,构建过程中的依赖也可能成为攻击入口,凸显了供应链安全的复杂性。
跨受害者数据窃取的风险
该蠕虫会将受害者的数据发布到与另一名受害者关联的 GitHub 仓库,导致仅搜索自己的仓库可能无法发现泄露。这种跨受害者数据窃取增加了检测难度,因为数据可能出现在不相关的仓库中。Elastic 建议使用特定 IOC 查询来识别此类行为,强调了主动威胁狩猎的重要性。
防御措施的有效性
Elastic 的快速响应得益于其已有的安全实践,如软件组成分析、威胁情报比对、令牌撤销和依赖冷却期。这些措施在攻击发生前就降低了风险,并在事件发生后迅速控制。这表明,建立完善的供应链安全机制对于应对新兴威胁至关重要,而不仅仅是事后补救。
Q&A
Shai-Hulud 2.0 蠕虫是什么?它和初代版本有什么不同?
Shai-Hulud 2.0 是一种针对 npm 生态系统的恶意蠕虫,于 2025 年 11 月出现,入侵了数百个软件包,包括 AsyncAPI、Zapier、PostHog 和 Postman 等热门项目。与初代版本相比,它使用 setup_bun.js 安装 bun,然后执行包含恶意代码的 bun_environment.js 文件;它还会创建随机命名的 GitHub 仓库进行跨受害者数据窃取,并且感染范围从最多 20 个包扩大到最多 100 个包,若无法认证则清除用户主目录。
Elastic 是如何快速响应 Shai-Hulud 2.0 攻击的?
Elastic 采取了多项措施:使用 SCA 工具持续扫描依赖项;利用威胁情报源比对恶意包列表;迁移到 Trusted Publisher 并撤销令牌;实施 14 天冷却期;使用 OSQuery 扫描已知受感染包;运行 OOTB 检测规则;向开发人员发送安全公告。
Elastic 的 CI 管道是如何受到 Shai-Hulud 2.0 影响的?
Elastic 通过合作伙伴 Entro 得知其 CI 管道运行了 Shai-Hulud 2.0 恶意软件,并将数据发布到公共 GitHub 仓库。该管道用于 GitOps,具体是 Elastic Cloud 的编排器。罪魁祸首是传递依赖关系。但 Elastic Cloud 系统和客户未受影响。
Elastic 在发现攻击后采取了哪些修复措施?
Elastic 从所有已识别的 GitHub 仓库移除了恶意依赖;识别了可能运行恶意软件的管道和手动流程;轮换了所有非临时密钥;确认未对客户造成影响;GitHub 删除了暴露数据的仓库。
Elastic 提供了哪些 KQL 查询来帮助客户检测 Shai-Hulud 2.0 相关活动?
Elastic 提供了多个 KQL 查询,例如:检测 GitHub Self-Hosted Actions runner 名称中包含 SHA1HULUD 的进程;检测 node 或 bun 执行 bun_environment.js;检测 trufflehog 从 node_modules 目录运行;检测 curl 下载 GitHub actions runner;检测 docker 以特权模式挂载主机文件系统并执行 bash 命令。
Elastic 提供了哪些开箱即用的检测规则来防护 Shai-Hulud 2.0?
Elastic 提供了多个 OOTB 检测规则,包括:与可疑网络服务的异常网络连接、连接到常见滥用网络服务、对 DPAPI 主密钥的潜在发现、发现 Windows 凭据管理器存储的潜在风险、通过未签名进程访问 Web 浏览器凭据、潜在的浏览器信息发现、通过 Node.js 生成的 Curl 或 Wget、通过 TruffleHog 执行访问凭据等。
Shai-Hulud 2.0 是如何窃取数据的?
Shai-Hulud 2.0 通过创建随机命名的 GitHub 仓库来窃取数据,通常会将一位受害者的数据发布到与另一名无关受害者关联的仓库中,这种行为被称为“跨受害者数据窃取”。