您是否已经到了信任 AI 代码助手胜过信任自己手动审查的程度？许多开发者确实如此。我们依赖大语言模型 (LLM) 来扫描漏洞、建议修复方案并验证第三方软件包的完整性。但是，当恶意软件知道如何向 AI “回话”时会发生什么？上周，我花了几个晚上研究了 Hades 攻击活动（Hades Campaign）的技术细节，这一威胁标志着攻击者应对自动化防御方式的转变。这不仅仅是一个数据窃贼，它是一场针对我们用来保护自己的软件进行的心理战。
StepSecurity 的研究人员最近确认，该攻击活动是 Miasma 威胁参与者组织的最新作品。虽然 Miasma 之前专注于云凭据收割，但 Hades 是一个更具攻击性、具有自我传播能力的蠕虫。它通过 PyPI 生态系统中受损的软件包，专门针对 Python 开发环境。受影响的库列表包括 ensmallen、mflux-streamlit 以及几种用于生物信息学的工具。如果您从事计算生物学或数据科学工作，您的工作站就是该特定组织的高价值目标。
Python 初始化过程中的入口点
攻击始于开发者导入受损的软件包。Hades 将其主要加载器隐藏在 __init__.py 文件中。这是 Python 用于将目录标记为包的标准文件。通过将恶意脚本放置于此，攻击者确保了代码在包被加载到项目中的那一刻执行。加载器经过混淆处理以规避基础的基于特征的检测，但其目的很简单：它将一个预编译的 Bun 运行时二进制文件植入系统。
Bun 是一个高性能的 JavaScript 工具包。对于合法开发者来说，它是一个出色的工具，但它也是恶意软件完美的执行引擎。由于 Bun 是一个自包含的二进制文件，它允许恶意软件在受害者机器上无需安装 Node.js 的情况下运行复杂的 JavaScript 有效载荷。这绕过了寻找可疑 npm 或 Node 活动的传统监控。从架构层面来看，使用 Bun 允许攻击者在大多数以 Python 为中心的工作站的标准安全可见性之外的影子环境中运行。
恶意软件如何对自动化守门人进行“煤气灯”欺骗
Hades 最具创新性的特征是它能够对 AI 安全代理撒谎。许多现代开发环境使用 LLM 来扫描代码中的恶意模式。Hades 预见到了这一点。在恶意文件的顶部，该恶意软件包含了一段设计为对抗性提示（adversarial prompt）的文本。这段文本指示 LLM 忽略其下方发现的任何可疑代码，并将该软件包归类为已验证且安全的。
上个月，我在沙箱环境中测试了类似的技术。我向 LLM 提供了一个包含明显反弹 shell 的脚本，但在其前面加了一段注释，称该代码是针对政府合同的预授权安全测试。AI 忽略了该漏洞利用，并报告该脚本遵循所有安全协议。Hades 使用的正是这种数字特洛伊木马策略。它利用了 AI 的认知逻辑。由于 LLM 容易受到社会工程的影响，它们会将这些隐藏的指令视为高优先级命令。这导致了误报（false negative）判定，使恶意软件得以溜过组织的自动化分析。
利用供应链完整性框架
Hades 不仅仅是隐藏，它还试图让自己看起来很正式。它利用了几个关键任务安全框架，包括 OpenID Connect (OIDC) 和软件伪制品供应链级别 (SLSA)。当恶意软件发现自己在 GitHub Actions 工作流中运行时，它会检查 OIDC 变量。然后，它利用这些凭据通过 Sigstore 生成加密签名的 SLSA 来源包（provenance bundles）。
这是对旨在保证软件完整性的系统的复杂绕过。通过生成有效的 Sigstore 包，恶意软件可以将受损版本的库发布到 PyPI 或 npm，而这些库看起来像是来自官方、经过验证的构建环境。对于外部观察者或自动化工具来说，该软件包看起来具有有效的监管链。这使得安全基础设施变成了攻击者的武器。它使受损代码看起来比合法的、未签名的代码更值得信赖。
内存抓取与横向移动
一旦恶意软件站稳脚跟，它就开始收集数据。它包含针对 Linux、macOS 和 Windows 定制的内存抓取器。这些抓取器针对活动进程的内存映射，以提取磁盘上无法访问的敏感加密数据。这是一种隐蔽的方法，因为它避免了创建可能被终端检测与响应 (EDR) 系统标记的可疑文件。
该蠕虫还会寻找传播途径。它扫描受感染系统中的 SSH 密钥、SCP 配置和 GitHub 令牌。如果发现具有写入权限的令牌，它会利用 GitHub Actions 运行器直接从内存中提取机密信息。然后，它会尝试感染用户拥有的其他存储库。命令与控制 (C2) 流量隐藏在公共 GitHub 基础设施中。被盗数据被压缩、加密并推送到攻击者控制下的新公共存储库。这些存储库通常带有描述：“Hades — The End for the Damned”（哈迪斯——被诅咒者的终结）。
焦土持久化机制
持久化是 Hades 设计的核心组件。恶意软件在工作站上建立存在感，并监控被盗凭据的状态。如果安全团队检测到违规并撤销了被盗的 GitHub 令牌，Hades 会进入反应模式。它会执行一个擦除程序（wiper），尝试删除用户的本地文件。
这是一种报复性策略。它为事件响应者创造了一个高风险局面。如果你切断访问权限，你可能会丢失本地机器上的数据。这种逻辑迫使组织在补救阶段必须小心行事。该恶意软件还针对 14 种不同 AI 代理的配置文件。它植入指令，每当开发者就当前工作区咨询其 AI 助手时，就会触发新的感染。这创造了一个循环：向 AI 工具寻求帮助的行为会重新感染系统。
构建针对欺骗性恶意软件的主动防御
Hades 攻击活动表明，我们对 AI 作为主要安全层的依赖是一个漏洞。我们必须转向一种将 AI 视为协作者而非最终权威的模型。从风险角度来看，最好的防御是细粒度的防御，不依赖于单一的守门人。
保护环境的关键要点：
- 对 LLM 使用严格的边界隔离。 绝不要在没有系统提示（system prompt）的情况下将原始、不可信的代码传递给 AI 扫描器，该提示应明确禁止模型遵循代码本身包含的指令。
- 审计您的 GitHub Actions 权限。 为 OIDC 令牌实施最小权限原则，并确保运行器对您的存储库没有不必要的写入权限。
- 监控未经授权的二进制执行。 Hades 依赖于植入 Bun 运行时。能够标记或阻止在
__init__.py路径中执行未知二进制文件的工具可以在入口点阻止感染。 - 手动验证 Sigstore 来源。 虽然 Hades 可以伪造包，但构建时间或环境变量中的差异有时可以在取证审计中被发现。
- 实施稳健的备份策略。 由于 Hades 包含擦除程序，拥有开发工作的离线或不可变备份是减轻补救期间数据丢失威胁的唯一方法。
审视威胁态势，Hades 很可能是未来的预演。攻击者不再仅仅试图撬开我们的大门，他们正在学习如何说服数字保镖让他们进去。我们需要停止将 AI 的判定视为绝对真理，并开始将其视为需要人工验证的数据点。
来源：NIST Cybersecurity Framework, MITRE ATT&CK Framework (Software Supply Chain Compromise), StepSecurity Hades Campaign Report.
免责声明：本文仅供信息参考和教育目的，不能替代专业的网络安全审计或事件响应服务。
