GitHub被黑3,800仓库遭窃：我的zsh

导语：说个真事——我 5 月 19 日刚把 ~/.zsh_history 传到了 Google Drive，5 月 20 日 GitHub 就被 TeamPCP 给端了。当时我就想问：这也太巧了吧？我的凭证是不是已经在那堆被卖的代码里了？天塌了，得改多少密码？

一、事件始末：GitHub 承认被”端了”

5 月 19 日，GitHub 安全团队检测到员工设备上有异常活动，第一时间进行了遏制。

与此同时，威胁组织 TeamPCP 在 Breached 网络犯罪论坛发了个帖子，张口就说：我们从 GitHub 偷了大约 4,000 个私有仓库，现在开价至少 5 万美元出售，有意者私信。

到了 5 月 20 日，GitHub 官方发推确认：确实被入侵了，被窃的内部仓库约 3,800 个，跟攻击者的说法”方向性一致”。

那入侵是怎么发生的？GitHub 的声明指出：一名员工安装了被污染的 VS Code 扩展。恶意版本已被移除，关键密钥也已轮换。

现在这批数据正在 LAPSUS$ 的暗网泄露站上兜售，要价已从 5 万涨到了 9.5 万美元。

二、Nx Console：220 万安装量的”穿甲弹”

虽然 GitHub 官方没有指明是哪个扩展，但安全社区基本锁定了目标——Nx Console。

Nx Console 是 Node.js 生态里非常流行的 VS Code 扩展，主要用于管理和运行 Nx 工作区命令，安装量高达 220 万。

巧的是，就在 5 月 19 日同一天，Nx Console 被后门化，恶意版本在商店里只存活了约 18 分钟——但这 18 分钟足够让成千上万的开发者中招。

Nx Console 维护者随后发布的公告里，曝光了恶意代码窃取的目标路径，与此次 GitHub 入侵的受害范围高度吻合。这基本坐实了攻击链路：通过污染 Nx Console 扩展，攻入 GitHub 员工开发环境 → 横向移动到内部代码仓库 → 批量拉取 3,800 个仓库。

三、TeamPCP 是什么来头？跟 LAPSUS$ 什么关系？

TeamPCP 这个名字可能有些同学还不太熟悉，但说到 LAPSUS$，估计很多人有印象——那个 2022 年先后拿下三星、育碧、微软的网络犯罪组织。

据安全公司 KELA 和 Sophos 的分析，TeamPCP 从 2026 年 3 月底 就开始与包括 LAPSUS$ 在内的勒索和敲诈组织合作了，模式很清晰：TeamPCP 负责提供初始访问权限，合作方负责后续的加密和敲诈。

到了 5 月，TeamPCP 胆子更大了——直接在 LAPSUS$ 的暗网泄露站上开卖 GitHub 的赃物。

他们可不是小打小闹。TeamPCP 的武器库里有一个叫 “Mini Shai-Hulud” 的蠕虫恶意软件，攻击手法高度自动化：

初始入侵：通过窃取 CI/CD 凭证或投毒工具（如 Trivy）进入开发环境。

横向移动：利用窃取的凭证访问 GitHub 仓库，向 Docker 镜像、VS Code 扩展、PyPI/npm 包中注入恶意代码。

窃密与扩散：恶意代码执行后，窃取云服务凭证、SSH 密钥等所有开发环境密钥。npm 令牌被劫持后，用于劫持其他软件包，实现蠕虫式自动扩散。

简单说，这是一套供应链攻击的组合拳。

四、我的 .zsh_history 到底有没有危险？

回到开头那个问题——我 5 月 19 日上传的 ~/.zsh_history，5 月 20 日 GitHub 就被黑，这是不是冲着我来的？

先别慌，大概率不是。

GitHub 官方声明里明确说了：GitHub 没有证据表明客户数据或企业账户受到了secondary exposure（次生影响）。这次被窃的是 GitHub 自己的内部仓库，不是用户代码仓库。你存在 GitHub 上的代码暂时没事。

但！是！

你的开发环境可能有问题。

TeamPCP 的攻击路径是通过员工的开发环境入手的，他们的目标是 CI/CD 凭证、SSH 密钥、npm/token 令牌等。如果你是开发者，以下几点值得自查：

你装了 Nx Console 吗？

5 月 19 日那天如果你的 VS Code 自动更新了扩展，恶意版本可能已经进了你的环境。虽然存活时间只有 18 分钟，但万一你正好在那段时间重启或更新了 VS Code……

你的 npm/token 令牌有没有暴露风险？

这次攻击里，TeamPCP 会主动劫持 npm 令牌来扩散恶意包。如果你过去在 CI/CD 里用过 GitHub Actions 的 secrets，那些令牌理论上也有可能被窃取。

你那 5 月 19 日传 GD 的 .zsh_history 里有什么？

这个才是你真正该担心的——如果你的 .zsh_history 里记录了 git push 用的 token、SSH 密钥路径、AWS CLI 命令（带凭证的）、或者任何 API key……那不管是 GitHub 被黑还是 GD 被黑，凭证都会暴露。

建议立即行动：

轮换所有重要的访问令牌：GitHub PAT、npm token、AWS key，能换就换
检查 VS Code 扩展列表：尤其是 Nx Console，看有没有异常版本
检查 .zsh_history 内容：如果里面有 token 或 key，立即轮换
启用 GitHub 的 SSH key 指纹通知：防止有人在后台默默 clone 你的仓库

五、安全社区提供了什么工具？

安全社区已经有人给出了 KQL 查询（Kusto Query Language），可以检测组织内是否安装了恶意扩展。微软系的同学可以用这个跑一下 Defender 的日志。

另外，StepSecurity 和 Socket Security 也发布了专项分析，建议去翻翻他们的报告，有详细的 IOCs 和检测规则。

六、”终端卫生”这个新概念值得注意

Aikido Security 的研究人员提了一个很有意思的观点：传统的安全边界已经失守了。

过去我们以为”只要服务器打补丁、防火墙配好”就够了。但现在攻击者的目标直接转向开发者的本地终端——因为你本地有代码、有密钥、有 CI/CD 访问权限，你才是那个脆弱点。

这就引出一个新概念：终端卫生（Endpoint Hygiene）。

企业需要像管理服务器一样管理开发者的本地环境——审查 IDE 扩展的权限和来源、定期审计敏感文件、定期轮换凭证。这比以往任何时候都重要。

七、总结

回到最初那个问题：我 5 月 19 日上传的 .zsh_history，5 月 20 日 GitHub 被黑，这是不是针对我？

答案是：大概率不是，但你的凭证可能需要换。

GitHub 这次被黑，目标是他们的内部仓库，不是普通用户。但 TeamPCP 的攻击手法——通过污染开发工具链入手——说明了一个问题：开发者的本地环境已经成为网络攻击的重要突破口。

不管你的 .zsh_history 有没有被”精准关照”，，趁这个机会全面排查一下自己开发环境里的各种 token 和 key，该换的换，该删的删。这波操作，不亏。

最后，如果 GitHub 后续发布了完整的技术报告，我会第一时间跟进。感兴趣的可以关注一下。

文章版权归作者所有，未经允许请勿转载。

THE END

GitHub 被黑亲历记：我的 .zsh_history 泄露了吗？