文章总结： 微软披露Storm-3168攻击事件，攻击者利用被攻陷的AzureServicePrincipal，在约7分钟内对云资源执行超百次删除操作，破坏速度从小时级缩短至分钟级。攻击前有约16小时侦察准备，身份失陷或因公开泄露的Secret。文章强调工作负载身份安全风险，建议企业加强身份治理、最小权限、行为检测、资源保护及独立恢复能力，并指出备份与生产权限需隔离。 综合评分： 85 文章分类： 云安全,安全运营,威胁情报,红队,数据安全

---

AI 开始参与云端破坏： Storm-3168 只用 7 分钟就能把 Azure 资源打残？

JacobWang JacobWang

NowSec

2026年9月28日 11:03 陕西

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

以前做云安全，我们经常会讨论一个问题：

攻击者拿到云账号以后，到底能做多少事情？

过去答案可能是：枚举资产、读取对象存储、寻找数据库、创建虚拟机、继续提权，然后一步一步扩大影响。

这个过程通常需要时间。

但现在，时间正在被压缩。

微软最近披露的一起 Azure 攻击中，真正的破坏阶段只持续了大约 7 分钟。

2026 年 9 月 25 日，Microsoft Security Research 公布了 Storm-3168 的最新活动。微软将其与此前 Sysdig 披露的 JADEPUFFER 关联，并观察到攻击者利用被攻陷的 Azure Service Principal，对云环境实施大规模资源枚举、凭据收集和破坏操作。

其中最值得关注的一段攻击，仅用了约 7 分钟，就针对 Azure Storage 发起了 100 多次删除尝试，同时还尝试删除 SQL 数据库、Key Vault、Function App、App Service Plan，以及和备份恢复相关的保护资源。大多数被针对的 Storage Account 最终被成功删除。

这件事真正值得安全团队警惕的，并不是“Azure 又出事了”。

真正的问题是：当云 API、工作负载身份和自动化能力结合以后，攻击者完成破坏的速度，已经开始逼近机器速度。

一、先把“AI 攻击”这件事说清楚

这次事件很容易被包装成一句：

“AI 用 7 分钟删掉了 Azure。”

但严格来说，这个表述并不准确。

微软确认的是：Storm-3168 与 JADEPUFFER 相关，而 Sysdig 此前将 JADEPUFFER 评估为首批被公开记录的 Agentic Ransomware——也就是由大语言模型驱动完整攻击链的自治型勒索活动。Sysdig 在此前案例中观察到它可以自主完成侦察、凭据收集、横向移动和数据库破坏。

而在这次 Azure 事件里，微软从操作时间、多个 Service Principal 的分工、并行 Token 和高度重叠的操作序列中判断，整个过程明显具有自动化或脚本化特征，并把它放在 AI-orchestrated attacks，也就是 AI 编排攻击正在加速发展的背景下讨论。

需要注意：目前公开证据并不能证明这 7 分钟里的每一个 Azure 删除操作，都是由 AI 模型实时自主决定的。可以确认的是，该攻击组织与已公开的 Agentic 攻击活动存在关联，而且这次 Azure 操作呈现出了高度自动化特征。

但从防守角度看，这个区别其实没有那么安慰人。

因为不管背后是 Agent、脚本还是两者结合，结果都是一样的：

攻击者完成大规模云资源破坏所需要的时间，已经从“小时级”进一步缩短到了“分钟级”。

二、7 分钟之前，其实还有 16 个小时

如果只看“7 分钟”，很容易忽略攻击真正的准备过程。

微软观察到，这个 Azure Tenant 中有两个被攻陷的 Service Principal。

其中一个身份在 6 月初开始进行大规模侦察，持续大约 15 小时 30 分钟，完成了 300 多次成功的读取操作，包括枚举虚拟机、订阅、资源组和各种 Azure 资源。

另外一个被攻陷的 Service Principal，则在几秒钟内完成了跨两个 Subscription 的虚拟机和资源组枚举。

大约 16 小时以后，它开始枚举 App Service 配置存储，并尝试寻找可能存在的凭据。

然后，真正的破坏开始了。

整个链路更像是：

身份失陷 → 云资产枚举 → 权限确认 → 凭据搜索 → 资源定位 → 批量删除 → 尝试破坏恢复能力 → 继续收集 Storage Key

所以，“7 分钟”不是攻击从零开始到结束。

它代表的是另一件更危险的事情：

一旦攻击者完成云环境侦察并确认权限，真正执行破坏的时间窗口可以非常短。

三、最开始的问题，可能只是一条泄露的 Secret

这次事件里还有一个非常值得国内企业注意的细节。

微软并没有最终确认 Service Principal 是如何被攻陷的，但调查发现，其中一个身份的 Client ID、Client Secret 和 Tenant ID，此前曾经以明文形式出现在该组织员工发布的一个公开 GitHub Issue 中。

后来，这个 Issue 被编辑，Secret 从正文里删除了。

问题是：

Secret 虽然从页面上消失了，却仍然存在于公开的编辑历史中。

微软强调，目前无法确认这组 Secret 是否就是本次攻击使用的初始凭据。

但这个细节足以再次说明一个非常基础、却反复发生的问题：

Secret 一旦进入公开互联网，就不能靠“删除那一行”解决。

它可能已经进入 Git History、Issue 编辑历史、搜索引擎缓存、第三方归档、日志、浏览器缓存，甚至被自动化爬虫提前抓走。

真正的处置必须是：

立即吊销 → 重新生成 → 排查历史使用 → 检查关联权限

而不是把公开页面删掉以后继续使用原 Secret。

四、真正危险的不是账号，而是 Service Principal

传统身份安全里，安全团队最关注的通常是“人”。

员工账号有没有 MFA？

管理员有没有异常登录？

是否存在异地登录？

但云环境里还有另一大类身份：

Workload Identity / Service Principal

它们不是员工，却同样拥有权限。

应用需要访问 Storage，CI/CD 需要部署资源，Terraform 需要创建基础设施，自动化脚本需要调用 Azure API，这些场景都可能依赖 Service Principal。

问题在于，这类身份往往比人类账号更容易被忽略。

它不会请假，不会离职，不会触发异地登录告警，也不会因为深夜调用 API 就显得特别异常。

一旦权限给得过大，攻击者拿到它以后甚至不需要再提权。

在 Storm-3168 事件中，被攻陷的身份本身就拥有 Storage Account Contributor、Contributor、SQL DB Contributor 等权限。攻击者实际执行的删除操作，基本都沿用了这些身份本来已经拥有的 Azure RBAC 权限。

换句话说：权限系统没有被绕过。

被绕过的是企业对“这个身份会不会被滥用”的假设。

五、攻击者为什么连备份一起盯上？

这次攻击还有一个很典型的勒索行为特征：

不仅删生产资源，还尝试破坏恢复能力。

微软观察到攻击者尝试删除 Azure Site Recovery Locks 和 Azure Backup Protection Locks，还针对名称中带有 Terraform、Backup 等特征的 Storage Account 展开操作。

这和传统勒索软件的逻辑完全一致。

传统勒索进入 Windows 环境后，会删除 Shadow Copy、关闭备份服务、破坏恢复环境。

到了云环境，同样的思路只是换了一种表现形式：

先删除业务资源，再尽可能删除恢复资源，让受害者无法快速回到正常状态。

这也是为什么云上的备份和恢复能力，不能和生产权限使用同一套信任边界。

如果一个 Contributor 既能删除生产资源，又能删除备份和恢复保护，那么“有备份”并不代表真正具备恢复能力。

六、这次攻击里，有两道保护真的挡住了删除

这次事件并不是所有资源都被成功删除。

微软披露，少部分 Storage Account 因为存在 Azure Resource Lock 和 Storage Account 级别的删除保护，最终成功挡住了攻击者的删除操作。

这个细节很重要。

它说明即使攻击者已经拿到了高权限身份，独立于身份权限之外的安全控制仍然可能发挥作用。

最小权限减少“能删多少”，资源锁和删除保护解决“能不能删”，备份隔离决定“删完以后能不能恢复”。

这三层控制缺一不可。

七、对国内企业来说，这和 Azure 没那么远

有人可能会认为，这是 Azure 的事情。

实际上，它讨论的是一个非常普遍的云安全问题。

放到国内环境，对应的可能是：

云厂商 AK/SK、RAM 用户、IAM Role、Service Account、CI/CD Token、Terraform Credential、Kubernetes ServiceAccount，以及各种自动化平台长期使用的 API 凭据。

它们有一个共同特点：

业务依赖它们自动运行，因此往往生命周期很长。

一个普通员工密码可能 90 天强制修改一次，但某个 CI/CD 系统里的云 Secret 可能用了两年。

一个员工账号离职以后会被禁用，但某个没人维护的自动化账号可能永远存在。

这就是为什么云安全正在从“账号安全”走向“身份安全”。

安全团队需要管的不只是人，还要管所有能够调用云 API 的机器身份。

八、安全运营应该重点盯什么？

Storm-3168 给安全运营最直接的提醒，是传统的“登录异常检测”已经不够。

对于 Service Principal 和工作负载身份，更应该关注的是行为变化。

例如：

平时只读 Storage 的身份，突然开始删除资源； 平时只访问一个 Resource Group 的身份，突然枚举整个 Subscription； 短时间内大量调用 ListKeys； 一个 Service Principal 同时出现多个 Token 并行操作； 短时间大量删除 Storage、SQL、Key Vault； 开始操作 Backup、Recovery、Resource Lock； 非正常来源 IP 调用 ARM API。

微软在这次事件中就观察到，一个用于破坏和凭据收集的 Service Principal 同时存在五个不同 Token，其中多个 Token 在同一时间段并行执行删除、资产枚举和 Storage Key 获取。

如果企业只看“认证是否成功”，这些操作全部都是合法身份、合法 Token、合法 API。

真正异常的是它们组合起来以后形成的行为链。

九、企业现在最应该补的五件事

第一，重新盘点所有工作负载身份。

不仅是管理员账号，还包括 Service Principal、Service Account、CI/CD 身份、Terraform 身份和长期 API Token。

第二，清理长期 Secret。

能用短期凭据、Federated Identity、Managed Identity 的场景，就不要继续保存长期静态 Secret。

第三，重新检查 RBAC。

业务只需要读取 Storage，就不要给 Contributor；CI/CD 只需要操作某个 Resource Group，就不要给整个 Subscription。

第四，单独保护备份与恢复能力。

备份资源、恢复锁、关键存储、灾备系统，不应该和生产环境共享同一个高权限身份。

第五，把 Secret 泄露处置从“删除”改成“轮换”。

只要 Secret 曾经出现在 GitHub、GitLab、Issue、日志、聊天记录或者公开文档中，就应该按照已泄露处理。

一个最简单的判断标准：

如果攻击者今天拿到这个 Service Principal，它最多能删掉什么？

最后

Storm-3168 最值得关注的，并不是一个“AI 黑客”的故事。

它真正揭示的是云攻击正在发生变化。

云 API 天生适合自动化。

资产枚举可以自动化。

权限判断可以自动化。

凭据搜索可以自动化。

批量删除同样可以自动化。

而当 AI Agent 开始进一步参与这些步骤之后，攻击者真正得到的不是“一个更聪明的脚本”。

而是一个能够根据环境变化继续执行任务的自动化攻击主体。

过去，蓝队还有时间看到告警以后慢慢调查。

未来，当攻击真正进入机器速度，7 分钟可能已经足够让一个云环境失去大量关键资源。

这意味着安全运营也必须改变。

不能只依靠人工看告警，不能只保护员工账号，也不能把备份和生产放在同一套权限体系里。

真正需要建立的是：

工作负载身份治理 + 最小权限 + 行为检测 + 资源保护 + 独立恢复能力

攻击速度已经变了，云安全的响应速度也必须跟着变。

参考资料

1. Microsoft Security Research：Storm-3168: Agentic-driven cloud attacks using compromised service principals

2. Sysdig Threat Research Team：JADEPUFFER: Agentic ransomware for automated database extortion

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：NowSec JacobWang JacobWang《AI 开始参与云端破坏： Storm-3168 只用 7 分钟就能把 Azure 资源打残？》