文章总结： Sha1-Hulud2.0变种通过npm包的preinstall脚本进行供应链攻击，在构建阶段感染系统并窃取凭证，失败时会删除用户主目录文件。该攻击利用Bun运行时绕过安全扫描，通过GitHubActions实现远程控制，并采用交叉受害者策略传输数据。建议立即审计CI/CD配置、轮换凭证、检查preinstall脚本并监控文件系统以防范此类攻击。
综合评分： 90
文章分类： 供应链安全,漏洞预警,漏洞分析,网络安全
紧急预警：npm 再次沦陷！Sha1-Hulud 变种卷土重来，偷不到密钥竟直接“删库”？
原创
Kit Chung
安全圈动向
2025年12月8日 09:05
广东
各位老铁好，这是一个非常典型的、高危的软件供应链攻击案例。作为技术同行，看到这种“偷不到数据就删库”的流氓逻辑，真的让人无语。
还记得今年9月份那个闹得沸沸扬扬的 Shai-Hulud npm 供应链攻击吗？如果你以为那已经是大结局，那就太天真了。
就在刚才（2025年11月下旬），安全圈的警报再次拉响。这一次，Sha1-Hulud 带着它的 2.0 变种杀了个回马枪。而且这次它不论是传播速度、攻击手段，还是破坏性，都比上一波高出了好几个段位。
据统计，短短几天内，已经有超过 25,000 个仓库 被感染，连 Zapier、ENS Domains、Postman 这样的大厂核心包都没能幸免。
最让我感到无语的不是它能偷数据，而是代码里藏着的一个“焦土政策”——如果偷取凭证失败，它会直接删除受害者主目录下的所有文件。
这不仅仅是窃密，这是赤裸裸的破坏。今天，我就带大家拆解一下这个名为 Sha1-Hulud 的“毒王”到底是怎么运作的。
01 隐蔽的入口：被滥用的 preinstall
对于咱们做开发的来说，npm install 是再稀松平常不过的指令了。但黑客恰恰就是利用了我们对这个指令的“肌肉记忆”。
不同于以往很多病毒在运行时（Runtime）才发作，Sha1-Hulud 2.0 选择在 构建阶段（Build Phase） 就下手。
攻击者向 package.json 文件中注入了一个 preinstall 脚本。这个脚本指向了一个名为 setup_bun.js 的文件。
技术细节：
一旦你敲下 npm install在任何依赖包下载之前，preinstall 钩子就会被触发。
这个脚本会悄悄在你的环境中安装或查找 Bun 运行时，然后通过 Bun 去执行核心恶意代码 bun_environment.js
为什么要用 Bun？ 这是一个很鸡贼的点。因为很多传统的 Node.js 安全扫描工具，可能会忽略针对 Bun 环境的特定脚本检查，从而完美绕过静态扫描。
02 寄生与提权：GitHub Actions 成了“肉鸡”
一旦代码跑起来，它不会马上像疯狗一样乱咬，而是开始极其精密的“寄生”操作。
如果你是在 CI/CD 环境（比如 GitHub Actions）中触发了它，那就更糟糕了。
-
伪装 Runner：
它会将受感染的机器注册为一个名为 SHA1HULUD 的 Self-hosted Runner（自托管运行器）。
-
注入工作流：
紧接着，它会创建一个 .github/workflows/discussion.yaml 文件。
-
利用漏洞执行：
这个工作流包含一个注入漏洞，允许攻击者通过在 GitHub 仓库中发起“讨论（Discussion）”，就能在你的服务器上远程执行任意命令。
更骚的操作是，它利用了 Docker 进行本地提权。
Docker 提权原理：
病毒会执行一个 Docker 命令，将宿主机的根文件系统（Root Filesystem）挂载到一个特权容器中。
既然挂载了宿主机的 / ，它就可以直接修改宿主机的 /etc/sudoers 文件，赋予攻击者 无密码的 Root 访问权限。这一步走完，你的服务器基本上就姓“黑”了。
03 盗亦有道？不，是“交叉窃取”
Sha1-Hulud 2.0 在窃取数据方面展示了惊人的“分布式”思维。
它会下载 TruffleHog（原本是用来帮我们查漏补缺的安全工具，现在成了黑客的帮凶），扫描你的本地环境，搜刮 NPM Token、AWS/GCP/Azure 云凭证以及各种环境变量。
但它怎么把数据传出去而不被防火墙拦截呢？
它采用了一种“交叉受害者”策略（Cross-victim exfiltration）：
- 受害者 A 的机密数据，被加密（三层 Base64 嵌套）后，上传到受害者 B 的公开仓库中。
- 受害者 B 的机密数据，可能被传到了受害者 C 那里。
这样一来，流量看起来完全是合法的 GitHub 操作，极难追踪溯源。而且，病毒还会利用 GitHub 的搜索功能，搜索关键词 Sha1-Hulud: The Second Coming 来寻找新的 Token。即使你删除了本地的恶意库，它也能通过搜索“复活”，具备了可怕的自愈能力。
04 最疯狂的设定：失败即“自毁”
前面说的都是窃密，如果仅仅是窃密，这还只是个传统的木马。但 Sha1-Hulud 2.0 最让人心惊肉跳的，是它的 Fail-safe（故障保险）机制。
Koi Security 和 Wiz 的研究人员发现，这个病毒内置了一个极其激进的逻辑。如果在运行过程中满足以下所有条件：
- ❌ 无法验证 GitHub 身份
- ❌ 无法创建 GitHub 仓库
- ❌ 无法获取 GitHub Token
- ❌ 无法找到 NPM Token
简单来说，就是“当它发现自己啥也偷不到，也没法建立持久化连接时”，它就会启动自毁程序。
它会尝试删除受害者主目录（Home Directory）下的所有可写文件。
“If Sha1-Hulud is unable to steal credentials… it defaults to catastrophic data destruction.”
—— 如果捞不到好处，那就毁灭吧。
这种从“间谍”突然转变为“暴徒”的行为模式，标志着供应链攻击已经从单纯的利益驱动，转向了带有惩罚性质的破坏。
05 我们该怎么办？
面对这种武装到牙齿的自动化攻击，单纯靠人工审查 package.json 已经不现实了。这里有几条紧急建议，建议大家立刻执行：
-
立刻审计 CI/CD 配置：
检查 .github/workflows/ 目录下是否有可疑文件，特别是 discussion.yaml 或者名为 shai-hulud-workflow.yml 的文件。
-
全面轮换凭证：
不要抱有侥幸心理，假设你所有的 NPM Token 和云厂商密钥都已泄露，立即进行 Rotate（轮换）。
-
检查 preinstall 脚本：
在引入第三方包时，强制使用能够阻断恶意 preinstall 脚本的安全工具（如 Socket, OSSF Scorecard 等）。
-
监控文件系统：
关注服务器上是否有异常的 setup_bun.js 或 bun_environment.js 文件生成。
💡 写在最后
Sha1-Hulud 2.0 的出现，彻底打破了“构建服务器是临时的，所以没那么重要”的幻想。黑客利用了自动化的力量，在30分钟内就能感染1000个新仓库。
作为技术人，我们必须意识到：安全不是一个“功能”，而是一种“状态”。
如果不加防范，下一次当你敲下回车键构建项目时，可能就是你本地数据灰飞烟灭的时刻。
转发给你的开发团队，赶紧自查吧！
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：安全圈动向 Kit Chung《紧急预警：npm 再次沦陷！Sha1-Hulud 变种卷土重来，偷不到密钥竟直接“删库”？》