JadePuffer/Storm-3168：一自主型行为体在7分钟的破坏性爆发中删除了某Azure租户的存储

微软安全研究部门报告称，2026年9月25日，一个使用两个被入侵服务主体的攻击者在2026年6月初于一个未具名的 Azure 租户内活动，先进行了超过15小时的侦察，随后在大约七分钟内试图删除100多个存储账户，并成功删除了其中大多数，还删除了一个 Azure Key Vault、一个 Function App 和一个 App Service 计划。微软将此次入侵归因于其追踪编号为Storm-3168的攻击者，安全公司 Sysdig 将其称为JADEPUFFER，并在2026年7月记录其为首个由大语言模型端到端实施的勒索软件行动。微软表示未发现勒索信，也未确认有任何数据被窃取。该档案将此活动记录为一起高严重性事件，确认涉及 AI 并造成实际危害，Orca AI 事件档案中的完整条目载有其来源、严重性评级和置信度评估。

受害者姓名未公布。Microsoft 的报告描述了一个 Azure 租户、属于该租户的两个遭攻陷的服务主体，以及它们之间的分工：一个服务主体进行了约 15 小时 30 分钟的侦察，并成功执行了 300 多次读取操作，枚举虚拟机、订阅、资源组和资源；另一个服务主体则执行了发现、破坏性操作和凭据收集。Microsoft 未说明有多少组织受到影响，也无法确定这些服务主体最初是如何被攻陷的。

遥测所显示的内容，按顺序

第二个主体在第一个开始约90分钟后启动，并在大约五秒内枚举了两个订阅中的虚拟机和资源组，据微软称。两个身份都使用了微软与Storm-3168关联的基础设施，共享相同的网络指纹，并呈现相同的用户代理，python-requests/2.34.2。微软表示，时间安排和分工“强烈表明是自动化或脚本化执行”。

大约16小时后，第二个主体检查了 Azure App Service 配置存储中是否有暴露的凭据，并尝试查找 Azure OpenSearch，但未成功。70秒后，它针对一个不存在的存储账户尝试执行 ListKey 操作。那次失败调用后不到一秒，破坏就开始了。在接下来的35分钟里，Microsoft 统计到超过150次破坏性或凭据收集操作；核心破坏阶段持续了约七分钟。

那七分钟，以及守住的管控措施

Microsoft 表示，该攻击者针对的大多数存储帐户均已被成功删除。该攻击者还删除了一个 Azure Key Vault、一个 Function App，以及同一资源组中一个似乎用于支持该 Function App 的 App Service 计划。其目标并不限于存储：Microsoft 记录到多次尝试删除 Azure Site Recovery 锁和 Azure Backup 保护锁，并报告这些尝试均未成功。

Microsoft 表示，并非所有删除操作都成功了，而且失败原因各不相同，这种差异对防御者很重要。少数存储账户得以保留，是因为 Azure 资源锁和存储账户级别的删除保护阻止了该操作。与此同时，删除 Azure SQL 数据库的尝试则因另一个原因失败：每一次都使用了不受支持的 API 版本。Cloud Security Alliance 将此描述为操作失误，而非操作被阻止。Microsoft 将资源删除、干扰恢复的尝试以及凭据收集的组合总结为“与可支持勒索软件和敲诈勒索活动的战术一致”。

Microsoft 的说明描述的是普通的 Azure 角色分配，而不是对 Azure 本身的利用。它发现，一个通过组授予的 Storage Account Contributor 角色允许了存储破坏，直接授予的 Contributor 角色允许删除三个应用程序资源并另有一次密钥检索，而直接授予的 SQL DB Contributor 角色导致了未成功的 SQL 尝试。Microsoft 观察到为第二个服务主体签发了五个唯一令牌：其中四个支持删除，第五个负责存储清单和密钥检索。其中两个删除令牌在同一个 70 秒时段内处于活动状态。报告还指出，名称带有 terraform 和 backup 主题的存储账户也在目标之列，可能是为了妨碍恢复。

存储键的返回值

破坏结束后约 30 分钟，同一主体再次出现。它清点了存储账户，并发起了超过 30 次成功的 ListKeys 请求，其中包括针对与 Site Recovery 关联的存储的请求。同一资源组中一个名称相似的存储账户在删除阶段未受影响，随后也被成功列出密钥。Microsoft 未发现勒索信，也未确认数据外泄成功，但表示所收集的密钥可能为未来的外泄提供支持。

Corsica Technologies 首席信息安全官 Ross Filipek 就此次事件接受 CSO Online 采访时表示，这一连串情况改变了“恢复”的含义。他说，仅重建被删除的资产还不够，因为随后对存储密钥的请求可能开辟出另一条通往数据的路径；响应人员必须确定哪些身份和密钥被触及，并在信任已恢复的服务之前审查其使用情况。Filipek 对 CSO Online 表示：“一旦攻击者掌握了一个应用程序身份，他们的活动看起来就可能像普通的云管理操作。”

凭据是如何浮出水面的

微软无法确认最初的访问途径。它确实发现了一处暴露：某个服务主体的客户端 ID、客户端密钥和租户 ID 曾以明文形式出现在一个公开的 GitHub issue 中，该 issue 由受影响组织的一名员工发布。该 issue 后来被编辑过，但微软表示，通过该 issue 的公开编辑历史仍可访问该密钥。报告明确表示，微软无法确认所使用的密钥是否就是这一密钥。

该发现附带的警告才是实际要点。Microsoft 表示，已公开暴露的凭据应被视为已泄露，应立即撤销或轮换，并调查其此前是否被使用；删除或遮盖已暴露的机密并不会使其失效，公开暴露的凭据在撤销或轮换之前仍然可用。

Microsoft 还描述了自 2026 年初以来，与 Storm-3168 关联的基础设施针对 Azure App Services 上的 WordPress 管理、PHP-CGI、Langflow 端点 /api/v1/validate/code以及类似 webshell 的路径进行的更广泛探测。这些目标并未与受害者的订阅重叠，Microsoft 也未发现从 App Service 到 Azure Resource Manager 凭据的路径。报告列出了三个指标：45.131.66[.]106 用于探测和恶意 ARM 请求，以及 34.153.223[.]102 和 64.20.53[.]230 用于 App Service 探测。

同一个执行者，不同的操作

Sysdig 于 2026 年 7 月 1 日发布的报告，正是“agentic”一词会被用在该行为体身上的原因所在。Sysdig 将 JADEPUFFER 描述为首个有记录的智能体式勒索软件案例——“一个由大语言模型端到端驱动的完整勒索行动”——并表示其能力来自 AI 智能体，而非人工操作的工具包。在那次入侵中，该行为体利用了 CVE-2025-3248（位于一个面向互联网的 Langflow 实例中），使用 MySQL 内置的 AES_ENCRYPT() 函数加密了 1,342 个 Nacos 配置项，删除了原始表，并留下了一个名为 README_RANSOM 的表，其中包含一个比特币地址和一个 Proton Mail 联系方式。Sysdig 报告了 600 多个不同的载荷、会自我叙述的代码，以及一个在 Nacos 登录失败后 31 秒内执行的多步纠正载荷。Sysdig 还表示，它无法查看系统提示词或该智能体的配置。

Azure 行动是同一行为体发起的一次独立行动，并非 7 月入侵的重演：其目的是删除和收集密钥，而不是加密，并且 Microsoft 未发现勒索信。两者之间的联系部分建立在基础设施之上。Cloud Security Alliance 在 9 月 28 日的一份研究简报中指出，Microsoft 列出的两个 IP 地址 45.131.66[.]106 和 34.153.223[.]102 曾出现在 Sysdig 7 月的报告中。同一简报还提醒，仅凭 IP 复用不能排除共享第三方托管。

已确立、已评估，并且仍然开放

Azure 入侵的机制已有详尽记录。其自主性则未达到同等记录标准，而这一差异是本记录最重要的限定条件。

Microsoft 的遥测数据证实：单个租户中有两个遭入侵的服务主体；在约 15 个半小时内超过 300 次成功读取操作；超过 100 次存储账户删除尝试，其中大多数成功；一个 Key Vault、一个 Function App 和一个 App Service 计划被删除；因 API 版本不受支持而全部失败的 SQL 数据库删除；因资源锁和删除保护而免遭删除的存储账户；破坏之后超过 30 次成功的 ListKeys 请求；一个公开 GitHub 问题及其编辑历史中的明文服务主体凭据；未观察到勒索信；且未确认数据外泄。

Microsoft 评估认为：该活动属于 Storm-3168；删除、对恢复的干扰以及密钥收集这三者的组合与勒索软件和敲诈勒索相符；执行很可能是自动化或通过脚本进行的；并且收集到的密钥可能支持未来的数据外泄。Microsoft 的公开报告未描述有自主代理对 Azure 特定步骤进行推理。

公开：服务主体最初是如何被攻破的；受害者身份以及受影响组织的数量；是否有任何数据离开该租户；以及是否是 AI 代理而非脚本直接指挥了这些 Azure 操作。

云安全联盟在9月28日的说明中精准指出了这一证据缺口：它写道，“智能体”这一描述目前依据的是“跨身份的精密度、节奏和分工”，而非捕获到的智能体推理轨迹。Sysdig在7月所使用的证据——自我叙述式载荷以及快速诊断与纠正循环——在Azure攻击活动的公开记录中并不存在。安全公司Swimlane的Nick Tausek对CSO Online表示，Azure方面的证据表明“这是协调一致的自动化，而非证明AI指挥了每一步”。

对该披露的报道采用了更为夸张的表述框架。BleepingComputer 的标题称 Azure 遭受了“智能体式 AI 攻击”，Dark Reading 的标题则称一个“AI 行为主体”入侵了一个 Azure 租户；而微软自己的报告称，其时序与分工“强烈表明是自动化或脚本化执行”，并且并未将 Azure 的各个单独步骤归因于某个智能体。

档案将这条记录评为置信度 A，并且没有将其标记为存在争议。该记录中“已确认”的 AI 参与标签取决于对 JADEPUFFER 的归因：Sysdig 记录称，JADEPUFFER 是由 LLM 驱动的行为体。这并不表示 Microsoft 在 Azure 删除事件期间捕获了某个智能体的推理过程。损害已经确立，自动化已经确立，自主性则是推断得出的。

微软认为应该改变什么

微软的建议具有可操作性，并且直接源于此次入侵的运作方式。它要求防御者启用 Microsoft Defender for Cloud 中针对 Resource Manager、Storage、Key Vault、App Service 和 Databases 的相关计划；将服务主体凭据、存储密钥、连接字符串和其他机密排除在源代码、配置、存储库和问题之外；使用 Microsoft Entra Workload ID 而非长期有效的机密；应用最小特权并审查工作负载标识的 Azure RBAC 分配；以及限制并监视备份和恢复资源，包括试图更改其保护控制措施的行为。

微软的公开报告没有说明该租户是否恢复了其数据、受害者是否得到通知，也没有说明收集到的密钥此后是否被使用。这些结果不在记录中。记录所承载的是一个可衡量的对比：资源锁和删除保护阻止了一些删除操作，即使面对拥有广泛特权的身份也是如此；而 SQL 数据库则是因 API 版本错误而得以保全，而不是因为防御者做出了决定。微软的叙述没有说明该租户接下来做了什么。它确实说明，攻击者在花费七分钟进行删除之前，花了超过 15 个小时进行读取。