Hades攻击波袭来：19个PyPI恶意包如何偷走你的全部开发凭证

点滴安全 · 安全资讯

2026年6月10日

开篇：你pip install的一瞬间，攻击者可能已经拿到了你的AWS密钥

2026年6月9日，安全公司Socket和StepSecurity联合披露了一起大规模的Python供应链攻击事件——“Hades”攻击波。攻击者在PyPI（Python Package Index，Python官方包仓库）上发布了19个恶意包，包含37个被污染的wheel安装文件。这些包看起来和正常的Python库没什么两样，但在你执行pip install的那一刻，一个精心设计的凭证窃取器就已经在你的系统上悄然启动。

这不是一起孤立的攻击事件。Hades是”Miasma”供应链攻击活动的最新分支，而Miasma本身又源自更早的”Shai-Hulud”蠕虫攻击。这个攻击 lineage 已经持续了数月之久，每次出现都以新的变体和更隐蔽的手法卷土重来。这一次，攻击者甚至学会了如何欺骗AI安全扫描器，让恶意代码在被分析时看起来完全无害。

正文一：攻击技术拆解——从pip install到全面失陷

Hades攻击的核心技术手法可以用一个词概括：自动化。整个攻击链在设计上力求在用户毫无察觉的情况下完成凭证窃取，具体步骤如下：

第一步：恶意包安装触发。攻击者利用Python的*-setup.pth文件机制，这个文件会在Python解释器启动时被site模块自动处理和执行。也就是说，受害者甚至不需要在代码中import这个恶意包——只要安装了它，恶意代码就会在下次Python启动时自动运行。这是对之前npm生态中install-hook问题的Python版本复刻。

第二步：下载Bun运行时。恶意代码启动后，会从GitHub下载Bun JavaScript运行时的独立压缩包。选择Bun而非Node.js是有讲究的：很多开发环境中并没有安装Node.js，但Bun可以作为独立二进制文件直接运行，无需安装，也不会触发传统的包管理器控制或网络代理日志告警。

第三步：执行混淆JavaScript窃取器。Bun下载完成后，恶意代码会启动一个经过高度混淆的JavaScript凭证窃取器_index.js。这个窃取器的目标范围极其广泛，包括：GitHub令牌、npm凭证、PyPI令牌、RubyGems凭证、JFrog凭证、CircleCI令牌、Anthropic API密钥、AWS凭证、GCP凭证、Azure凭证、Kubernetes配置、Docker配置、Vault令牌、SSH密钥、Shell历史记录、.env文件、.npmrc文件、.pypirc文件、Claude/MCP配置等。

第四步：数据外传。窃取到的凭证数据被上传到攻击者控制的公开GitHub仓库。这一次的仓库描述被标记为”Hades – The End for the Damned”和”Hades * The End for the Damned”，延续了Miasma活动使用希腊神话命名的风格。

整个攻击链在几秒到几分钟内就能完成，而受害者可能只是在终端里敲了一个看似无害的pip install命令。

正文二：更可怕的发现——AI欺骗与反制措施

Hades攻击中最令人不寒而栗的新特性，是攻击者开始主动对抗AI安全分析工具。

欺骗AI扫描器：安全研究人员发现，Hades恶意包中嵌入了纯文本的提示注入（prompt injection）代码，专门设计用来欺骗基于大语言模型的包分析工具。当AI安全工具分析这些包时，恶意代码中的提示会让AI模型判定该包是安全的，从而绕过自动化安全检查。这意味着攻击者已经把AI安全工具视为需要绕过的防线之一，并为此做了专门的适配。

反溯源机制：恶意代码在执行前会检查系统的地区设置，如果检测到系统使用俄语区域设置，则会自动退出而不执行任何恶意操作。这个特征与之前多个俄罗斯关联的攻击活动一致，可能是攻击者为了避免感染本国系统而采取的预防措施。

数据擦除报复机制：Hades恶意软件会安装一个名为”gh-token-monitor”的后台服务，如果检测到开发者撤销了被盗的GitHub令牌，这个服务会自动执行rm -rf ~/; rm -rf ~/Documents，将受害者的整个主目录和文档目录彻底删除。这是一种报复机制——你发现被盗并重置凭证的代价，是你的所有数据。

跨平台内存扫描：与之前仅能在Linux上通过/proc/{pid}/mem读取进程内存不同，Hades引入了针对macOS和Windows的定制化内存扫描器，能够直接从GitHub Actions Runner进程中提取密钥。这意味着无论你的CI/CD环境运行在什么操作系统上，都面临着凭证泄露的风险。

正文三：开源项目gpt-pilot被攻陷——供应链攻击的链式反应

Hades攻击波还揭示了一个更深层的问题：攻击者不仅通过发布恶意包来传播恶意代码，还通过直接攻陷知名开源项目的GitHub账户来扩大影响。

安全研究人员发现，一个未知的攻击者攻陷了与开源AI开发工具”Pythagora-io/gpt-pilot”相关联的GitHub账户”LeonOstrez”，并强制推送了Shai-Hulud蠕虫的变种代码到项目的主分支。这意味着任何克隆或拉取这个项目代码的开发者，都有可能在运行项目时不知不觉地激活恶意代码。

gpt-pilot是一个颇受欢迎的开源AI开发工具，拥有大量开发者用户。攻击者选择这样的项目作为攻击目标，看中的正是其广泛的用户基础和开发者对这些工具的信任。

有趣的是，这次攻击最终被一个不太可能的”英雄”阻止了——Python代码格式化工具ruff。由于恶意代码的格式不符合ruff的规范，在自动化检查中被标记了出来。这个意外的防御效果说明，代码质量工具在供应链安全中也能发挥意想不到的作用。

正文四：开发者和企业该如何防护

面对如此复杂的供应链攻击，开发者和企业需要建立多层防御体系：

包安装前检查： – 使用pip audit或Socket等工具检查依赖包的安全性 – 仔细检查包名是否与预期一致——攻击者经常使用与热门包相似的名称（typosquatting） – 关注包的下载量、维护者信息、最近更新时间等元数据

CI/CD环境加固： – 使用固定版本的依赖锁定文件（requirements.txt、poetry.lock） – 在CI/CD流水线中集成依赖安全扫描步骤 – 限制GitHub Actions的工作流权限，遵循最小权限原则 – 定期轮换CI/CD环境中的所有凭证和令牌

开发环境防护： – 在虚拟环境中进行包安装和测试，避免直接在系统Python环境中操作 – 定期检查系统中是否存在可疑的后台服务或进程 – 使用.gitignore确保敏感凭证文件不会被提交到代码仓库 – 启用GitHub的secret scanning功能

企业级防护： – 建立内部PyPI镜像，只允许经过审核的包被使用 – 部署网络监控，检测到异常的外部数据传输时发出告警 – 对开发环境进行网络隔离，限制不必要的出站连接 – 建立软件物料清单（SBOM）管理流程

应急响应： 如果你发现自己可能安装了上述恶意包，应立即： 1. 断开网络连接 2. 更换所有可能泄露的凭证（GitHub令牌、AWS密钥、SSH密钥等） 3. 检查系统中是否存在”gh-token-monitor”等可疑服务 4. 审查最近的GitHub仓库提交记录，确保没有被篡改 5. 检查CI/CD流水线的历史日志，确认没有异常操作

结语：供应链攻击正在成为最大的威胁面

Hades攻击波不是终点，而是一个不断进化的攻击谱系中的最新节点。从Shai-Hulud到Miasma，再到Hades，我们看到了攻击者在技术上的持续迭代：从npm生态扩展到PyPI，从简单的凭证窃取到AI欺骗、数据擦除、跨平台内存扫描。

在开源软件供应链日益复杂的今天，一个pip install命令所承载的信任链远比我们想象的要长。每一行import语句背后，可能都隐藏着数十个传递依赖和它们各自的安全假设。对于开发者来说，保持对供应链安全的警惕，已经不是一种”加分项”，而是一种”基本素养”。

在AI辅助攻击和AI安全防护的对抗中，没有永远的赢家，只有持续进化的攻防博弈。我们能做的，就是在这场博弈中始终保持清醒。