JadePuffer 通过代理式攻击在七分钟内破坏 Azure 资源

事件概述

2026 年 6 月，微软安全团队在官方博客（Microsoft Security Blog）上公开披露了两起利用被入侵服务主体的 Azure 攻击事件。攻击者使用的代号为 JadePuffer，内部追踪代号为 Storm‑3168。这两起事件分别发生在不同的租户中，攻击者首先获取了受害租户的服务主体凭证，随后以代理方式对云端资源执行了大量的读取、写入以及破坏指令，形成了高度自动化的攻击链。整个过程展示了攻击者在获取凭证后如何利用 Azure 的身份授权模型，以服务主体的身份在目标环境中横向移动并发起批量操作的典型手法。

攻击手法与时间线

在第一起事件中，攻击者利用获取到的服务主体凭证进行长达约 15 小时 30 分钟的持续侦察，期间完成了超过 300 次的读取操作，详细枚举了目标资源的配置信息，包括网络、存储以及身份管理设置。第二起事件则更为迅速，攻击者在约 35 分钟内发起了 150 多次的破坏或凭证收集行动，其中核心的破坏序列仅持续约 7 分钟，在这短暂的时间窗口内尝试删除了超过 100 个存储帐户。时间线显示，攻击者在获取凭证后先进行信息收集，以确认目标资源的防护状态，然后在确认可行后立即切换到破坏阶段，利用高频率的 API 调用实现快速且密集的删除尝试。

在这七分钟的破坏阶段，攻击者首先对目标资源进行枚举，随后调用 Delete API 试图移除存储帐户以及其他关联服务。虽然部分资源已经启用了资源锁定或删除保护功能，成功阻止了删除请求的实际执行，但仍有大量的删除尝试被发送，显示出攻击者的自动化脚本具备极高的调用频率和并发能力。脚本在短时间内循环发送请求，利用 Azure API 的并行处理特性，使得即使部分请求被阻止，整体攻击流量仍保持在高水平。

• 100+ 存储帐户删除尝试
• 150+ 破坏或凭证收集操作
• 300+ 读取侦察请求（第一起事件）
• 30+ ListKeys 调用（约 30 分钟后）

证据与来源

微软将此类攻击归类为 Storm‑3168，并指出攻击者利用获取到的服务主体凭证执行了代理式操作。iThome 报道同时提到，部分服务主体凭证曾在公开的 GitHub issue 中出现，但微软并未确认这些凭证就是入侵的直接来源。调查过程中，安全团队通过日志追踪确认了异常的服务主体行为模式，包括异常的 API 调用频率和跨租户的资源访问尝试，这些都与攻击者的代理脚本行为相符。

在调查过程中，微软未观察到任何勒索信件，也未发现明确的数据外泄迹象。唯一的后续行为是约 30 分钟后，攻击者成功发出了超过 30 次的 ListKeys 请求，这表明其仍在尝试获取更多的密钥信息，以便进一步扩大攻击面。ListKeys 调用的频繁出现被视为攻击者在尝试收集可用于后续横向移动或持久化的凭证，尽管当时并未检测到进一步的破坏动作。

影响与防御成效

资源锁定（resource lock）与删除保护（delete protection）在本次攻击中发挥了关键的防御作用，阻止了大多数存储帐户的实际删除。另一方面，针对 Azure SQL 的删除尝试因使用的 API 版本不受支持而失败，这进一步降低了潜在的损失范围。防御机制的有效性体现在即使攻击者发送了大量删除请求，只有极少数请求能够通过验证并实际执行，从而避免了大规模的数据丢失。

尽管防御机制阻挡了部分破坏行为，但攻击者仍然成功枚举了资源并获取了密钥，说明仅依赖资源锁定不足以完全防止代理式入侵。微软建议受影响的租户立即检查所有服务主体的凭证使用情况，启用条件式访问并严格遵循最小权限原则，以降低类似攻击的风险。对服务主体的使用进行细粒度审计、限制其对关键资源的写入权限以及定期审查其权限分配，是降低被滥用的关键措施。

未来的安全变化包括微软将在 Azure 监控服务中加入对服务主体异常行为的实时警示，并加强 API 版本兼容性检查，以降低利用过时 API 失败的攻击面。企业也被提醒定期轮换服务主体密钥，并将敏感资源纳入更严格的删除保护政策，从而提升整体的云端安全防御水平。通过结合行为分析、访问控制强化以及自动化的密钥管理流程，能够在源头上削减类似 JadePuffer 代理式攻击的成功概率。