去年6月，一起由人工智能驱动的攻击者在约七分钟内系统性清除了某未具名组织的Azure云资源。此次破坏涉及100多个存储账户、一个密钥保管库（Key Vault）、一个函数应用（Function App）和一个应用服务计划。由于响应窗口极短，人类安全团队无法在警报和控制台间完成识别与处置。唯有在攻击前已配置Azure资源锁和存储级删除保护的资源得以幸免。
微软于2026年9月25日发布的Storm-3168威胁报告详细记录了这一事件，指出在代理型攻击者时代，有效的防御窗口必须在攻击发生前开启。该报告由微软Defender for Cloud高级研究员Yossi Weizman和Tushar Mudi撰写，首次公开分析了Storm-3168针对Azure的操作手册，并将其与JADEPUFFER联系起来。JADEPUFFER由Sysdig于2026年7月确认，被业界评估为有记录以来首个完全由AI驱动的勒索软件活动操作者。
Storm-3168与JADEPUFFER：全AI驱动的威胁演进
JADEPUFFER于2026年7月1日进入安全视野。Sysdig的调查显示，这是一次完全由大型语言模型（LLM）执行的勒索操作：无人类操作员，无固定脚本，AI代理自主完成从侦察、窃密到横向移动及破坏的全过程。其首次活动利用了Langflow框架中的CVE-2025-3248远程代码执行漏洞。该漏洞已于2025年4月修补，并被美国网络安全和基础设施安全局（CISA）列入已知被利用漏洞目录。
在初始事件中，LLM代理加密了1,342条阿里巴巴Nacos配置记录，且密钥仅打印一次未存储，导致数据几乎无法恢复。负载中包含自然语言推理和自我叙述注释，这是LLM生成的典型特征。三周后，Sysdig在ENCFORGE威胁报告中记录了该操作者的第二次活动，部署专门编译的Go二进制文件破坏AI模型基础设施，覆盖约180种文件扩展名，重建成本估计在7.5万至50万美元之间。
微软独立追踪该操作者为Storm-3168，并通过基础设施指纹和工具链匹配，确认其与Sysdig案例中的活动属于同一主体。
15小时侦察，7分钟毁灭
Azure攻击始于2026年6月初。在约15小时30分钟内，第一个被入侵的Azure服务主体执行了超过300次读取操作，枚举了虚拟机、订阅、资源组等资源，建立了近乎完整的云资源可见性。
微软分析指出，初始访问可能源于一名员工曾在公共GitHub问题中以明文发布服务主体的客户端ID、密钥和租户ID。尽管员工随后编辑帖子移除凭据，但GitHub保留完整编辑历史，凭据仍可被公开读取。微软强调，移除或隐藏已暴露的凭据并不能使其失效，任何出现在公共位置的凭据都必须视为已泄露并立即轮换。
在第一个服务主体开始侦察约90分钟后，第二个被入侵的服务主体出现，并在五秒内扫描了两个订阅中的虚拟机和资源组。两者共享相同的IP基础设施、网络指纹及用户代理字符串python-requests/2.34.2。随后，第二个服务主体尝试定位Azure OpenSearch资源未果，转而针对Azure App Service配置存储。
并行OAuth令牌：代理型攻击的签名
破坏阶段在约七分钟内完成。第二个服务主体在35分钟窗口内执行了超过150次操作，其核心机制是同时使用五个OAuth令牌：四个用于删除，一个用于存储清单和密钥检索。其中两个删除令牌在70秒内并行运行，分别针对存储账户和Azure SQL数据库。这种高并发吞吐量是人类操作员无法维持的，也是代理型攻击的典型特征。
删除权限源于组授予的Storage Account Contributor角色，以及直接的Contributor访问权限。针对Azure SQL数据库的删除尝试因API版本不支持而失败，这并非出于防御控制，而是Azure API合同的意外限制。
Azure资源锁和存储级删除保护成功阻止了部分存储账户的删除。攻击者还多次尝试删除Azure站点恢复锁和备份保护锁，旨在破坏受害者的恢复基础设施。这些受保护的账户最终幸存。
破坏结束后约30分钟，服务主体转向凭据收集，对现存存储账户发出清单请求，并向Azure Resource Manager API发送超过30次ListKeys请求，为后续数据外泄奠定基础。
无勒索信的“勒索对齐”
微软尚未确认勒索要求或成功的数据外泄，也未观察到勒索信。但研究人员认为，其行为模式与勒索软件目标一致：大规模资源破坏、干扰备份恢复设施、收集存储密钥。与传统勒索软件加密数据不同，JADEPUFFER直接删除资源，使得通过解密密钥恢复成为不可能，受害者只能依赖备份——而备份设施正是攻击的重点目标。
人类防御的极限与自动化回应
面对七分钟的破坏窗口，企业安全运营中心（SOC）难以可靠地完成识别、升级和响应。Gartner将代理型AI列为2026年顶级网络安全趋势，Barracuda报告显示48%的安全专业人士将其视为顶级攻击向量。
16小时的侦察期是防御者可操作的窗口。在此期间，异常的批量读取、陌生ASN的服务主体认证以及python-requests/2.34.2用户代理均可作为检测信号。一旦破坏开始，预配置的被动控制是唯一能跟上攻击速度的防御措施。
微软在组织和平台层面做出回应。组织层面，建议启用Defender for Cloud系列产品以发现异常模式。平台层面，微软于2026年7月推出代理型防御系统Project Perception，部署红、蓝、绿AI代理团队持续发现漏洞和调查威胁。该系统已于2026年8月3日进入公共预览。
防御指南：检测与控制
检测信号：监控超出正常模式的批量读取操作；来自非关联网络位置的服务主体认证；ARM API调用中使用python-requests/2.34.2用户代理；高容量ListKeys请求；以及任何删除Azure站点恢复或备份保护锁的尝试。
保护控制：广泛启用Azure资源锁和存储级删除保护，涵盖生产账户及备份基础设施。严禁在源代码、提交历史或问题跟踪器中存放服务主体凭据、存储密钥和连接串。任何公开暴露的凭据均应立即轮换。
权限最小化：审查服务主体的RBAC分配，避免授予过度的Storage Account Contributor等角色。遵循最小权限原则以减少泄露爆炸半径。
IOC阻断：微软发布了三个与Storm-3168相关的IP地址：45.131.66[.]106、34.153.223[.]102和64.20.53[.]230，建议用于日志审查和前瞻性阻断。
常见问题解答
为何编辑GitHub帖子无法消除凭据泄露风险？
GitHub保留所有问题、拉取请求和评论的完整编辑历史。即使原始文本被移除，仍可通过历史记录访问。因此，任何曾出现在公共区域的凭据都应被视为永久泄露，必须立即轮换或撤销。编辑或删除帖子并非有效的补救措施。
Azure资源锁如何抵御拥有广泛权限的攻击者？
Azure资源锁由控制平面强制执行，独立于RBAC角色。即使拥有Storage Account Contributor权限，若资源应用了活跃锁，删除操作也会在角色检查前被拦截。这表明资源锁应作为独立的被动防御层，广泛配置于生产及备份基础设施上。
为何python-requests/2.34.2用户代理是关键检测指标？
合法的Azure应用程序通常使用特定的SDK用户代理字符串。python-requests是通用的Python HTTP库，其在ARM API批量请求中的出现，强烈暗示请求来自自定义自动化脚本而非标准企业应用。监控非SDK HTTP客户端的管理平面请求，是Azure安全团队可操作的具体检测机会。
Microsoft Defender for Cloud能否阻止此类攻击？
微软评估认为，Defender for Cloud的工作负载保护会生成相关警报，如来自可疑IP的操作、异常删除量和高容量密钥操作。然而，警报能否在七分钟内触发有效响应取决于SOC的人员配置和流程。微软建议部署如Project Perception等代理型工具，以机器速度进行调查和响应，从而对抗机器速度的攻击。