TeamPCP 和 BreachForums 发起 1,000 美元的供应链攻击竞赛

TeamPCP 和 BreachForums 正在推动一场供应链攻击竞赛，为最大的开源包妥协提供 1,000 美元的门罗币，根据 Socket 的最新研究。

据报道，该竞赛要求参与者使用 Shai-Hulud，这是一种与最近的 npm 和 PyPI 泄露相关的供应链攻击工具。攻击者必须提交论坛句柄或 BreachForums 个人资料，并提供访问证明才能获得资格。

评分系统使得该活动对于开源生态系统来说尤其危险。据报道，获胜者是根据受感染软件包的每周和每月下载次数来评判的，这奖励了针对流行依赖项的攻击，并鼓励了较小软件包的广泛危害。

供应链竞赛如何运作

Socket 表示比赛已宣布与 TeamPCP 合作，由被识别为论坛所有者的帐户在 BreachForums 上进行攻击。该帖子提供了 1,000 美元的门罗币奖金，以及在网络犯罪论坛中的声誉和地位。

参与者必须在攻击中使用 Shai-Hulud 并提供论坛所描述的合理的访问证明。分数来自包覆盖率，它将下载量转化为公共排行榜。

这种结构产生了危险的激励。单个高下载包可以获得很高的分数，但也可以组合多个较小的包妥协，从而为低级攻击者提供了在整个生态系统中传播攻击的理由。

为什么小奖励仍然会带来大风险

与成功的供应链妥协的价值相比，1,000 美元的奖励显得微不足道。对于熟练的犯罪分子来说，访问 CI/CD 机密、云凭证、维护者令牌、源代码和企业开发人员系统的价值可能要高得多。

这就是为什么这场比赛看起来不像是一场严肃的支付，而更像是一场招募和声誉活动。它为较低层的参与者提供了公开挑战、已知的工具名称以及通过销毁被盗访问权限来获得地位的方法。

SORadar 将这一趋势描述为游戏化网络犯罪。地下论坛可以将入侵转变为公开竞赛，参与者可以复制方法、比较结果并寻求认可，而不是孤立的攻击。

Shai-Hulud 已经进入了主要的开发者生态系统

这场竞赛是在几波针对软件供应链的 Shai-Hulud 活动之后举行的。最近的活动攻击了 npm 包、PyPI 包、GitHub Actions 工作流程、Docker 镜像、OpenVSX 扩展和开发人员基础设施。

StepSecurity 最近报道称TeamPCP 的 Mini Shai-Hulud 蠕虫通过窃取 CI/CD 机密并通过受信任的发布管道发布恶意版本来破坏合法的 npm 软件包。同一项研究表明，受损的软件包带有有效的 SLSA Build Level 3 来源证明，这使得仅通过来源检查就很难区分恶意软件包。

Snyk 还报告称，2026 年 5 月的 TanStack 泄露涉及 @tanstack 命名空间中 42 个包中的 84 个恶意 npm 工件。恶意版本后来传播到其他维护者，包括 Mistral AI、UiPath 等。

开源恶意软件使模仿攻击变得更容易

据《登记册》报道TeamPCP 似乎通过 GitHub 上流传的存储库开源了 Shai-Hulud 蠕虫病毒。据报道，Ox Security 观察到了与早期 Shai-Hulud 活动类似的代码模式，包括凭证盗窃和基于 GitHub 的死锁行为。

即使某些副本不完整或被修改，攻击逻辑的公开传播也可以降低其他犯罪分子的门槛。经验不足的参与者可以重用代码、更改基础设施并针对开源项目测试变体。

这是防守者更关心的问题。该活动不需要吸引精英干员来制造伤害。它只需要足够多的模仿者来生成更多可疑的软件包更新、更多受损的维护人员以及给企业安全团队带来更大的压力。

• 开源攻击代码可以帮助模仿者更快地构建变体。
• 论坛竞赛可以将窃取的访问权限转化为公众声誉。
• 基于下载的评分可以鼓励对大包和小包的攻击。
• 受损的发布管道可能会使恶意包看起来可信。
• 企业团队可能会面临更多来自软件包更新和 CI/CD 异常的警报。

安全研究人员已将 TeamPCP 与针对安全工具、云开发工作流程和可信软件包发布系统的活动联系起来。 Socket 表示，它已经通过 GitHub Actions、Docker 镜像、OpenVSX 扩展、npm、PyPI 和 Packagist 跟踪了该组织。

Unit 42 还追踪到自最初的 Shai-Hulud 浪潮以来，npm 供应链攻击不断升级。研究人员表示，攻击者越来越关注可蠕虫传播、CI/CD 持久性以及可以从开发人员环境中获取凭据的多阶段有效负载。

这种模式说明了为什么安全团队不应将竞赛视为论坛噪音。如果参与者的目标是具有大型依赖链或受信任的企业用途的包，即使少数参与者也可以创建真正的运营工作。

组织如何减少暴露

组织应该假设可能会出现更多的模仿尝试。最安全的应对措施是收紧软件包摄入量、减缓有风险的依赖项更新，并观察 CI/CD 工作流程是否存在异常发布活动。

团队不应仅依赖包的受欢迎程度或出处。已知的包名称、合法的维护者帐户或有效的构建证明并不总能证明当前版本是安全的。

开发人员和安全团队应检查依赖关系，限制发布权限，并审核可以访问注册表令牌、GitHub OIDC 身份、云机密和生产部署凭据的工作流程。

1. 在包更新到达生产版本之前启用依赖项审查。
2. 使用包锁定文件并避免高风险环境的自动升级。
3. 应用发布年龄冷却时间以减少对新发布的恶意版本的暴露。
4. 审核使用 pull_request_target 或特权令牌的 GitHub Actions 工作流程。
5. 将 npm、PyPI 和 GitHub 发布权限限制在所需的最小范围。
6. 在确认安装恶意软件包后轮换机密。
7. 在怀疑受到损害后，从干净的映像重建 CI/CD 运行程序。
8. 监视异常存储库、可疑分支和意外的软件包版本冲突。
9. 当指标可用时阻止已知的恶意基础设施。
10. 培训开发人员将意外的软件包更新视为安全事件。

为什么这场竞赛对开源安全很重要

这场比赛展示了网络犯罪团伙现在如何借鉴普通软件社区的策略。他们利用品牌、公开挑战、共享工具和声誉系统来吸引参与者并扩大攻击规模。

对于开源维护者来说，这增加了另一个负担。一个项目并不需要家喻户晓才能对攻击者有用。较小的包仍然可以拥有发布权、构建代币和下游信任。

对于企业来说，教训是显而易见的。供应链安全现在依赖于监视从源代码到发布管道再到依赖项更新的完整路径。攻击者不仅试图窃取凭证。他们正试图将可信软件交付转变为他们的分销网络。

FAQ