Miasma 与 Hades 正在传播：通过可疑文件在开发者机器上检测它们

Miasma 和 Hades 蠕虫正在 npm 和 PyPI 上扩散，在导入和打开项目时运行。了解 Dev Machine Guard 的 Suspicious Files 如何检测它们。

点击放大

Miasma 蠕虫及其 PyPI 分支 Hades 正在 npm 和 PyPI 生态系统中扩散。它们不等待构建步骤或粗心的 npm install，而是在开发者打开项目或导入包时运行，直接从进程内存中读取敏感信息。大多数团队依赖的防御手段——EDR、注册表网关和 SCA 扫描器——并非为捕获此类攻击而设计。Dev Machine Guard 的全新功能 Suspicious Files 正是为此而构建，能够检测这些蠕虫投放到开发者机器上的文件，检测规则由 StepSecurity 维护并自动推送到您的整个设备集群。

StepSecurity 研究团队一直处于这场攻击活动的最前沿，在每波攻击爆发时追踪态势，并通常是第一个报告的：6 月 3 日的 Miasma npm 攻击波、6 月 5 日攻击微软 Azure 组织导致 73 个仓库被禁用、以及 6 月 8 日的 Hades PyPI 攻击活动。五天内三波攻击，横跨两个生态系统。形势发展迅速，每个安全团队需要回答的关键问题是：目前哪些开发者机器受到影响。

为什么这很紧急

这不是单一需要清理的事件。这是一场正在主动扩散、自我复制的攻击活动，其变异速度远超安全公告的更新频率。

2026 年 6 月 3 日，Miasma 蠕虫在不到两小时的滚动攻击中 compromi sed 了 57 个 npm 包，涉及超过 286 个恶意版本。最大受害者是 @vapi-ai/server-sdk，月下载量超过 408,000 次。五天后的 6 月 8 日，同一威胁行为者以 Hades 攻击活动现身 PyPI， compromi sed 了 ensmallen 及大约二十余个相关的机器学习和生物信息学包。在两个生态系统中，研究人员统计了数百个恶意制品。

点击放大

这些是蠕虫。一旦 Miasma 或 Hades 落在开发者机器上，它就会搜索 npm 和 PyPI 发布令牌，然后将自己感染的版本重新发布到该令牌能够发布的所有包。每个新受害者都成为新的传播者。速度就是关键：6 月 5 日攻击活动波及微软的 Azure GitHub 组织时，在不到两分钟内扩散到 73 个仓库，而更广泛的活动现已感染数十个账户下的 113 多个仓库。这就是包数量每小时都在增加的原因，也是为什么"我们哪些开发者现在受到了感染"这个问题需要在几分钟内得到回答，而不是等到下一份安全公告发布之后。

攻击如何演变：从安装到导入

多年来供应链威胁模型一直以安装为中心。恶意包通过 package.json 中的 preinstall 和 postinstall 生命周期脚本运行代码，因此扫描器、允许列表和 CI 检查都学会了在那里查找。Miasma 和 Hades 已经将执行触发器移到了这些工具不监控的地方。

Miasma 的 npm 变体使用了一种我们称之为"Phantom Gyp"的技术：它不依赖生命周期脚本，而是附带一个 157 字节的 binding.gyp 文件，通过原生构建步骤在 npm install 期间触发代码执行，完全绕过 install-script 安全检查。同一个攻击者随后更进一步，感染了仓库，使得只要在 IDE 或 AI 编码助手中打开文件夹就会运行有效载荷，甚至完全不需要安装。

Hades，作为 PyPI 分支，在导入时执行。恶意代码是一个嵌入在包的 __init__.py 中的混淆单行钩子。当开发者导入该包时，钩子会下载一个独立的 Bun 运行时并执行 JavaScript 有效载荷。开发者不需要故意运行任何恶意内容。在 VS Code 中打开项目，或导入一个使用了多年的依赖项，现在就已足够。

点击放大

这就是关键的转变：危险时刻不再是安装时，而是打开时和导入时。携带有效载荷的制品——一个 binding.gyp、一个被注入的 __init__.py、一个 .vscode/tasks.json、一个 .claude/setup.mjs——安静地躺在项目树中，从不出现在包清单或锁文件差异中。

为什么现有防御会遗漏

大多数组织已经部署了多层供应链防御。针对 Miasma 和 Hades，每一层都有盲区。

注册表网关和冷却策略位于安装时。它们控制客户端允许从注册表获取哪些包版本，这很有价值，但对这些蠕虫来说这是一个错误的检查点。注册表网关看不到在原生构建期间触发的 binding.gyp、导入时运行的 __init__.py 钩子，或打开文件夹时执行的仓库文件。当有效载荷运行时，网关的工作已经完成。

EDR 旨在标记可疑进程行为和已知恶意二进制文件。Hades 被专门设计用于绕过它：有效载荷直接从进程内存中读取敏感信息，不会写入磁盘或建立明显可疑的网络连接，并且通过它动态下载的合法签名 Bun 运行时执行。没有恶意二进制文件可用于指纹识别，也没有经典的磁盘写入或数据泄露模式可供告警。Hades 攻击活动甚至携带了 AI 提示注入内容，旨在误导试图分析它的自动 AI 分类系统。

SCA 和依赖扫描器 清点清单和锁文件中声明的内容。携带这些有效载荷的文件不是您声明的依赖项。binding.gyp、被注入的导入钩子或编辑器配置文件不会出现在 package.json 或 requirements.txt 中，因此查看依赖图的扫描器没有什么可标记的。

共同点：这些工具监控的是包和安装。Miasma 和 Hades 从开发者磁盘上的文件执行，在打开和导入时运行，使用内存驻留技术。这个差距正是 Suspicious Files 旨在填补的。

Suspicious Files 检测什么

Suspicious Files 标记与已知供应链攻击相关的文件，覆盖您所有已注册的开发者机器。检测规则由 StepSecurity 研究团队编写并持续更新，基于我们的自主研究。StepSecurity 是最早检测重大供应链攻击的公司之一，已正式获得多个攻击的发现功劳，包括 axios 和 TanStack 的泄露。今天的覆盖范围包括 Miasma 和 Hades 攻击活动背后的制品：

• 一个在 npm install 期间触发代码执行的恶意 binding.gyp（Phantom Gyp 技术）
• 编辑器和 AI 工具配置文件，在打开项目或启动 AI 编码会话时自动执行

这些编辑器和 AI 工具集成点对攻击者越来越有吸引力，因为它们以开发者自己的权限执行，完全不需要包安装：

点击放大

托管检测，无需配置

Suspicious Files 开箱即用。检测规则由 StepSecurity 编写和维护，这是同一个从第一波攻击就追踪 Miasma 和 Hades 的研究团队，并且通常第一个报告这些攻击活动。当攻击者变异时——正如 Hades 从 npm 跳到 PyPI 并分离其加载器和有效载荷以逃避检测时所做的那样——我们会集中更新规则，您的设备集群会自动根据新规则进行评估。您无需编写、调优或维护任何规则。

点击放大

当文件被标记时，仪表板为您提供完整的检测记录：

• 文件路径及其被发现的设备
• 匹配规则关联的攻击活动
• 检测的置信级别
• 文件的 SHA-256，用于关联和威胁情报查询
• 匹配的规则和文件路径模式
• 文件在该设备上首次和最近一次出现的时间
• 条件细分，显示精确匹配了哪些指标以及哪些是必需的

  点击放大

条件细分意味着检测从来不是黑箱。您可以精确看到文件被标记的原因，这使得在活跃事件期间验证和分类处理都很快。

点击放大

为什么这很重要

被攻陷的开发者机器是攻击者可以获得的最有价值的立足点之一。开发者机器持有 npm 和 PyPI 的发布令牌、进入生产环境的 SSH 密钥、具有提升权限范围的 GitHub 凭证，以及对 CI/CD 系统的直接访问。在导入时或打开项目时执行的文件以所有这些权限运行，而 Miasma 和 Hades 的情况是，立即使用它发现的任何发布令牌进一步扩散蠕虫。

传统 MDM 工具了解设备态势，而非开发者工作流程。EDR 了解进程行为，而非供应链策略。注册表网关了解安装，而非导入。蠕虫投放到磁盘上的文件落在它们之间的盲区。Suspicious Files 专门为这个差距而构建，让安全团队看到攻击者实际用来在开发者机器上运行代码的文件。

如何开始

Suspicious Files 是 Dev Machine Guard 的一部分，运行在您已通过现有 MDM 或 EDR 工具部署的相同轻量级代理上，支持 macOS、Windows 和 Linux。无需安装新代理，也无需管理检测内容。

如果您已经运行 Dev Machine Guard，Suspicious Files 现已在仪表板的 Developer Machines 下可用。打开它，查看您的整个设备集群中是否存在任何 Miasma 或 Hades 制品。

如果您尚未使用 Dev Machine Guard，请参阅安装脚本文档了解推广指南，或请求演示了解它如何适应您的环境。

Miasma 和 Hades 已经超越了每个人都部署的安装时防御。它们正在扩散，就在导入时和打开时。您的可见性需要覆盖代码实际运行的地方。