文章总结： 2026年6月1日RedHat官方npm账户遭入侵，攻击者在72秒内自动化发布32个恶意包版本，通过GitHub账户劫持和OIDC令牌滥用实现供应链攻击。恶意软件利用preinstall钩子执行三层混淆载荷，窃取开发环境凭据并通过AnthropicAPI伪装外传，具备蠕虫式传播和令牌撤销后数据销毁能力。事件凸显官方发布通道攻陷和AI工具成为新攻击面的趋势，建议立即审计依赖、轮换密钥并启用SLSA框架加强供应链安全。 综合评分： 92 文章分类： 供应链安全,漏洞预警,威胁情报,恶意软件,安全运营

Red Hat官方npm账户沦陷: 72秒劫持31个官方npm包！

原创

威胁情报中心 威胁情报中心

奇安信威胁情报中心

2026年6月2日 11:57 北京

在小说阅读器读本章

去阅读

一、事件速览：什么发生了

2026年6月1日，Red Hat 官方 npm 账户 @redhat-cloud-services 被攻陷。攻击者在 72秒 的时间窗口内自动化发布了 32 个携带后门的恶意包版本。这批包的安装量覆盖了 Red Hat Cloud Services 生态的核心客户端库——vulnerabilities-client、sources-client、rbac-client 等。

这不是普通的 typosquatting（仿冒包名拼写错误）或依赖混淆（dependency confusion）攻击。攻击者拿到了 Red Hat 的 npm 发布权限，发布的包来自官方命名空间，数字签名、命名空间归属均合法。开发者执行一次普通的 npm install，就已经踩雷了。

攻击活动被命名为 “Miasma: The Spreading Blight”（瘟疫扩散），是 Mini Shai-Hulud 恶意软件家族的新变种，初步归因为 TeamPCP 组织。

二、攻击链拆解：从一个被劫持的GitHub账户说起

2.1 初始入侵：GitHub账户沦陷

多份独立报告交叉验证后，攻击起点高度一致：一名 Red Hat 员工的 GitHub 账户被攻破。攻击者利用该账户的权限绕过了代码审查流程，向 npm 包仓库推送了恶意孤立提交（orphaned commit），随后通过劫持的 GitHub Actions OIDC（OpenID Connect）令牌获取了 CI/CD 流水线的发布权限。

这个初始入侵路径很值得展开讲。GitHub Actions OIDC 令牌的设计初衷是让 CI 任务免密访问云资源，但它也成了双刃剑——一旦 OIDC 令牌被窃取，攻击者就可以”以合法身份”让流水线执行任何操作，包括向 npm 发布包、写入 Secrets、调用云 API。这就是 SLSA（Supply-chain Levels for Software Artifacts）框架中供应链完整性保障不足的典型表现。

2.2 72秒闪电发布

拿到 npm 发布权限后，攻击者没有手动逐个操作，而是编写了自动化脚本，在 72 秒内连续推送了 32 个包的恶意版本。这种速度说明：

1. 攻击者事先已完成侦察，确定了目标命名空间下的所有包名和版本号
2. 拥有绕过人工审批/确认环节的能力或预设了自动化发布管道
3. 计划周密——一旦被发现，窗口期极短，留给防御方的反应时间几乎没有

2.3 安装时引爆：preinstall 钩子

每个被投毒的包在 package.json 中注入了 preinstall 脚本，这是整个攻击链的执行入口。开发者执行 npm install <package> 时，Node.js 会在安装包体之前先运行这个脚本，恶意代码就此启动。

preinstall → index.js（载荷主体）

#

三、恶意载荷技术解剖

3.1 三层混淆管道

index.js 并不是裸的恶意代码，而是经过了三层叠加处理：

| 层级 | 技术 | 目的 | | — | — | — | | 第一层 | ROT-N 密码位移 | 最基础的字符串变形，不影响功能但能骗过简单正则 | | 第二层 | AES-128-GCM 加密 | 核心载荷加密存储，运行时解密后注入执行 | | 第三层 | obfuscator.io | 控制流平坦化、变量名混淆、字符串编码 |

载荷体量约 4.2MB，每次感染生成唯一加密载荷（per-infection unique encryption），这意味着传统基于哈希的检测（如 YARA 的文件 hash 匹配）直接失效。即使拿到一台受害主机上的载荷样本，也无法直接关联到另一台主机上的样本。

3.2 合法工具滥用：bun 运行时

解密后的载荷并不直接在 Node.js 进程中执行所有操作，而是下载 bun（一个新兴的 JavaScript 运行时）并通过 bun 来执行后续的凭据窃取逻辑。

选择 bun 的原因：bun 在系统进程列表中是一个合法的开发工具，安全告警策略中通常不会被标记为可疑进程。这是一种典型的”living off the land”（LotL，借用合法工具）策略。

3.3 凭据收割范围

恶意软件的核心目的是尽可能多地收集凭据，覆盖范围极广：

代码托管与CI/CD类：

• GitHub 经典个人访问令牌（PAT）
• GitHub 细粒度令牌
• GitHub Actions OIDC 令牌
• npm 发布令牌
• PyPI 凭证
• SSH 私钥（~/.ssh/）
• GPG 密钥

云服务类：

• AWS Access Key / Secret Key
• GCP 服务账号密钥
• Azure 身份令牌

基础设施类：

• Kubernetes kubeconfig 文件
• HashiCorp Vault 令牌
• AWS Secrets Manager 中的密钥
• Azure Key Vault 中的密钥

运行时窃取：

• CI 运行器进程内存中的环境变量（这意味着所有在 CI 环境中通过 env 注入的密钥都会被读取）
• 浏览器中保存的会话信息

这几乎覆盖了现代云原生开发中所有常见凭据存储位置。一个开发者工作站被感染后，攻击者可以沿着这些凭据横向移动到云控制台、Kubernetes 集群、内部密钥管理系统。

四、外传通道：伪装与备用

4.1 主通道：伪装为 Anthropic API 流量

窃取到的数据先经加密处理，然后通过 HTTP 请求发送到 api.anthropic.com/v1/api。

为什么选这个域名？因为：

1. 合法域名：Anthropic 的官方 API 域名，防火墙和代理白名单通常放行
2. 开发环境常见流量：在 AI 辅助编程日益普及的今天，对 Anthropic API 的请求在开发者机器上很常见
3. 加密载荷：数据被加密后嵌入到正常 HTTP 请求体中，深度包检测（DPI）看到的只是对合法域名的 HTTPS 连接

4.2 备用通道：GitHub 死投点

如果主通道失败（网络限制、服务中断、DNS 劫持），恶意软件切换到备用方案：利用窃取的 GitHub 令牌，在受害者账户下创建一个新的公开/私有仓库，将加密后的窃取数据作为 commit 或 issue 内容推送到这个仓库。攻击者只需定期搜索自己控制的关键词就能找到这些”死投点”。

这种 GitHub 死投点模式最早在 Shai-Hulud 原始版本中就已出现，现已成为该家族恶意软件的标准配置。

4.3 蠕虫式传播

与上一代 Shai-Hulud 一致，Miasma 也具备自传播能力。一旦窃取到其他命名空间下有效的 npm 发布令牌，恶意软件会自动将自身代码发布为该命名空间下的新包版本，形成链式感染。这也解释了为什么 72 秒内能在同一命名空间发布 32 个包——自动化程度极高。

五、持久化与反检测

5.1 持久化机制

Linux/macOS 平台：安装系统级监控服务，确保即使重启后仍能执行。

AI 工具钩子注入：

• Claude Code SessionStart 钩子：在 Claude Code 启动时自动执行恶意脚本
• VS Code tasks.json：注入预定义任务，编辑器启动时触发载荷重新执行
• 类似手段针对 GitHub Copilot 等其他 AI 辅助工具

覆盖范围：包括但不限于 Claude、Copilot 等 AI 开发者工具。

5.2 破坏性保险：令牌监视器

Miasma 内置了一个”令牌监视器”——持续监控已窃取令牌的有效性。一旦检测到某个令牌被撤销（revoke），立即触发破坏性操作：清空用户主目录（rm -rf ~）。

这是攻击者的”焦土策略”：

• 对防御方施加心理压力，犹豫是否撤销令牌
• 制造混乱，拖延应急响应时间
• 销毁取证证据，增加溯源难度

5.3 反检测对抗

• EDR 规避：主动检查系统中是否存在 CrowdStrike、SentinelOne、Carbon Black 等端点检测产品，发现后调整行为
• 地理回避：检测系统语言，如果是俄语环境则主动退出不执行
• 载荷唯一性：每次感染生成不同加密载荷，绕过哈希检测（ReversingLabs Spectra Assure 通过行为指标 BH13852、BH13525 等进行检测）

六、归因分析

6.1 TeamPCP 关联

多份报告将此次攻击疑似归因到 TeamPCP。关联依据：

1. 代码相似性：Miasma 的核心逻辑与此前 Shai-Hulud 家族有高度重叠
2. TTP 一致性：GitHub 死投点、worm 式 npm 传播、Anthropic API 伪装等手法延续了 Shai-Hulud 家族的标志性 TTP
3. 工具开源：TeamPCP 已将 Shai-Hulud 攻击工具开源发布，这使得精确归因变得更加困难——任何人都可以 fork 代码发起类似攻击

置信度评估：中等置信度。代码复用是归因依据，但工具开源意味着”模仿者”门槛很低，不排除其他威胁行为体使用同一套工具的可能性。

6.2 MITRE ATT&CK 技术映射

| 攻击阶段 | 技术编号 | 描述 | | — | — | — | | 初始访问 | T1195.002 | 供应链攻陷 – 软件供应链 | | 执行 | T1059.007 | JavaScript 执行 | | 持久化 | T1546、T1574 | 事件触发执行、劫持执行流 | | 凭据访问 | T1552.001、T1552.004、T1555 | 凭据转储（文件、密钥链、浏览器） | | 发现 | T1083、T1087 | 文件和目录发现、账户发现 | | 横向移动 | T1021 | 远程服务利用 | | 收集 | T1005 | 本地数据收集 | | 命令与控制 | T1071.001、T1102 | Web 协议、备用通道（GitHub） | | 数据外泄 | T1041、T1567 | 通过 C2 通道外泄、外传到云存储 | | 影响 | T1485、T1529 | 数据破坏（清空主目录）、系统关闭/重启 |

#

七、影响研判

7.1 风险影响

开发者需注意以下风险：

1. 使用了被投毒版本的 CI/CD 流水线：如果你的项目间接依赖了 @redhat-cloud-services/* 的某个包（例如通过传递性依赖），构建过程中可能触发载荷执行
2. 出海企业的海外开发团队：出海企业如果在海外使用 Red Hat Cloud Services 相关工具，面临直接风险
3. AI 工具供应链风险：Miasma 对 Claude Code、VS Code 等 AI 工具的持久化注入手法代表了一种新趋势——AI 开发工具正在成为供应链攻击的新攻击面。国内常用的通义灵码、文心一言等 AI 编程助手虽然不在此次攻击范围，但类似手法可能很快被复制

7.2 防御建议

即使没有直接受影响，国内安全团队也应该从此次事件中吸取教训：

立即行动：

• 审计所有 CI/CD 流水线中的 npm 依赖，检查是否间接引用了 @redhat-cloud-services/* 的受影响版本
• 如果有，删除 node_modules 和 package-lock.json，重新安装经过验证的版本
• 轮换 CI 环境中所有可能暴露的密钥（npm 令牌、GitHub PAT、云服务凭据等）

短期加固：

• 启用 npm 的 --ignore-scripts 选项，阻止 preinstall/install 钩子自动执行
• 在 CI 环境中监控 Node.js 衍生的异常子进程（尤其是 bun 进程）
• 对 ~/.ssh/、.npmrc、kubeconfig 等敏感文件的异常访问设置告警

长期建设：

• 部署 SBOM（软件物料清单）管理，追踪每一层依赖的来源和版本
• 实施 SLSA 框架要求，确保从源码到构建产物的全链路可追溯
• 对 AI 开发工具（Claude Code、Copilot 等）的配置文件变更进行监控
• 考虑使用制品签名（如 sigstore/cosign）验证 npm 包的完整性

八、事件启示：供应链攻击的新阶段

Miasma 事件标志着 npm 供应链攻击进入了一个新阶段。与早期的 typosquatting 和依赖混淆不同，这次攻击展现了几个值得警惕的趋势：

1. 直接攻陷官方发布通道。 攻击者不再满足于”仿冒”合法包，而是直接拿到合法包发布者的账户/令牌。这使得所有基于”包名/命名空间可信”的信任模型瞬间失效。

2. AI 工具成为新的攻击面。 从 Claude Code SessionStart 钩子到 VS Code tasks.json 注入，Miasma 展示了攻击者正在将 AI 辅助开发工具纳入持久化体系。随着 AI 编程的普及，这个攻击面的暴露面积只会越来越大。

3. 蠕虫式传播降低攻击门槛。 TeamPCP 将 Shai-Hulud 工具开源后，任何脚本小子（script kiddie）都可以发起类似的供应链蠕虫攻击。开源既是技术分享，也成了攻击能力扩散的催化剂。

4. 破坏性载荷改变了攻防博弈。 “令牌撤销即清空主目录”的设计把供应链攻击从纯数据窃取升级为带破坏性的攻击。这给应急响应增加了复杂度——简单撤销令牌可能触发数据销毁，导致取证和恢复都变得困难。

对于国内安全行业来说，这起事件的最大价值在于：它是一面镜子，让我们看到国际供应链攻击的演化方向，从而提前在自己的生态中做好防御准备。

九、参考来源

• https://x.com/SocketSecurity/status/2061454924706172937
• https://cybersecuritynews.com/multiple-red-hat-cloud-services-npm-packages/
• https://cyfar.ca/32-red-hat-npm-packages-backdoored/
• https://arstechnica.com/security/2026/06/red-hat-npm-packages/
• https://intel.threadlinqs.com/miasma-redhat-cloud-services-npm-supply-chain
• https://bladeintel.com/miasma-supply-chain-redhat-npm/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：奇安信威胁情报中心 威胁情报中心 威胁情报中心《Red Hat官方npm账户沦陷: 72秒劫持31个官方npm包！》