根据微软的说法，制造“JadePuffer”病毒的网络犯罪分子还利用被盗的Azure账户身份信息，对云存储系统及其他资源实施了破坏性攻击。“JadePuffer”是今年夏季首次被发现的、由恶意软件驱动的勒索软件攻击案例。今年7月，Sysdig威胁检测团队发现了“JadePuffer”病毒；该病毒整个攻击过程完全由人工智能模型（LLM）控制——从最初获取系统访问权限，到入侵生产数据库服务器并破坏数据，所有步骤都由AI模型完成。
The cyber criminal behind JadePuffer, the first known agentic ransomware infection reported over the summer, has also used stolen Azure identities to conduct destructive attacks on cloud storage and other resources, according to Microsoft. In July, Sysdig threat hunters uncovered JadePuffer, the first-ever documented agentic ransomware infection in which an LLM drove the entire extortion operation, from gaining initial access to compromising a production database server and destroying data.
如今，微软表示他们已经再次检测到这名攻击者（该攻击者被命名为“Storm-3168”），并发现其仍在继续实施恶意活动。研究人员Yossi Weizman和Tushar Mudi在周五的文章中指出：6月初的18小时内，“Storm-3168”入侵了两台Azure服务器，利用这些被入侵的服务器身份信息进行了大规模的破坏性操作，并收集了可用于未来数据窃取的云服务凭证。
Now Redmond says that it has detected the same attacker, which it tracks as Storm-3168, up to new mischief. Over an 18-hour period in early June, Storm-3168 compromised two service principals and used these machine identities for “extensive Azure-focused resource destruction” and “cloud credential collection that could be used to facilitate future exfiltration,” researchers Yossi Weizman and Tushar Mudi wrote on Friday.
这两台被入侵的服务器属于同一个Azure租户。犯罪分子使用其中一台服务器进行侦察和资源信息收集，另一台服务器则用于执行破坏性操作及凭证收集。微软的研究人员尚不清楚“Storm-3168”是如何最初获取这些服务器权限的，但他们指出：该组织的某名员工此前曾在公开的GitHub仓库中以明文形式泄露了客户ID、客户密码及租户ID。
The two compromised service principals belonged to the same cloud tenant. The crims used one of them to conduct reconnaissance and resource discovery, and the other to carry out destructive operations and credential collection. The Redmond researchers don’t know how Storm-3168 initially hijacked the service principals, but noted that an employee of the same organization previously exposed client IDs, client secrets, and tenant IDs in plaintext in a public GitHub issue.
研究人员还提到：“自今年年初以来，我们多次观察到‘Storm-3168’针对多个客户的Azure应用程序服务发起攻击。”整个攻击过程持续了约18小时，其中数据收集阶段耗时约15小时30分钟。在此期间，被入侵的服务器收集了大量关于Azure虚拟机、订阅服务、资源组及各类资源的详细信息，共完成了超过300次成功的数据读取操作。
“Since the beginning of this year, we also observed repeated probing from Storm-3168 linked infrastructure against multiple Azure App services for different customers,” the duo wrote. The entire attack took about 18 hours, with the discovery piece lasting about 15 hours and 30 minutes. During this time, the compromised service principal collected detailed information about Azure Virtual Machines, subscriptions, resource groups, and resources, completing more than 300 successful read operations.
“这种广泛的活动范围使得攻击者能够监控整个组织的 Azure 环境，”魏兹曼（Weizman）和穆迪（Mudi）写道。在第一个被入侵的机器开始收集 Azure 信息大约 90 分钟后，第二个被入侵的服务账户也开始行动：它在短短 5 秒内读取了两个订阅中的所有 Azure 虚拟机（VM）和资源组的数据。据微软（Redmond）称，这两个服务账户都使用了名为 Storm-3168 的攻击工具，它们使用的是相同的网络标识符（network fingerprint），并且都运行着 python-requests/2.34.2 这个用户代理程序。
“This breadth of activity would give the threat actor visibility across the organization’s Azure environment,” Weizman and Mudi wrote. About 90 minutes after the first machine identity began hoovering up Azure information, the second compromised service principal started its work, reading Azure VMs and resource groups across two subscriptions in just five seconds. According to Redmond, both of these service principals used Storm-3168 linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2.
在初次数据收集行动完成约 16 小时后，该服务账户成功找到了 Azure App Service 的配置信息（很可能是在寻找暴露的敏感凭证）；不过它尝试访问 Azure OpenSearch 资源时未能成功。70 秒后，该账户又尝试对一个不存在的存储账户执行了 “ListKey” 操作。随后，破坏性攻击正式开始：在接下来的 35 分钟内，该被入侵的服务账户共发动了 150 多次破坏性攻击或数据窃取行为。
About 16 hours after the initial target reads, the second service principal successfully discovered Azure App Service configuration stores - it was likely looking for exposed credentials, we’re told - and unsuccessfully attempted to find Azure OpenSearch resources. Seventy seconds after this, it also attempted a ListKey operation against a non-existent storage account. Then, the destruction began. During this part of the operation, the compromised service principal attempted more than 150 destructive or credential-stealing attempts in 35 minutes.
这些破坏行为仅持续了约 7 分钟，期间该攻击者试图删除了 100 多个 Azure 存储账户；虽然大部分删除操作成功了，但 Azure 的资源锁定机制以及存储账户级别的保护机制阻止了部分删除操作。此外，攻击者还删除了一个 Azure Key Vault（密钥库）和一个 Function App（函数应用程序），这两个资源都属于同一个资源组，并且很可能为该 Function App 提供了支持。
The destructive activity only lasted about 7 minutes with the machine identity attempting to delete more than 100 Azure Storage accounts. Most of these were successful, although Azure resource locks and storage account-level deletion did block a few. Additionally, the attacker deleted an Azure Key Vault, Function App, App service plan, all of which belonged to the same resource group and likely supported the Function app.
魏兹曼和穆迪进一步指出：“同一个服务账户还试图同时删除多个 Azure SQL 数据库，但由于使用的 API 版本不支持相应的操作，所有删除尝试都失败了。”
“The same service principal also attempted to delete multiple Azure SQL databases in parallel with the storage account deletions mentioned earlier, but every deletion attempt failed because it used an unsupported API version for the Azure SQL database resource type,” Weizman and Mudi wrote.
在破坏行为结束约28分钟后，同一攻击者再次向Azure存储账户发送了清单请求（inventory request），并成功执行了30多次“ListKeys”操作，要求Azure的自动化资源管理（ARM）系统返回这些存储账户的访问密钥。这些存储账户中包含与Azure Site Recovery（Azure灾难恢复服务）相关的账户。此外，攻击者还多次尝试删除用于保护这些存储账户的锁定机制（locks）。
About 28 minutes after the destruction ended, “the same service principal made an inventory request for Azure Storage Accounts and sent more than 30 successful ListKeys requests, asking ARM to return each storage account’s access keys,” they added. “These storage accounts included Azure Site Recovery related storage accounts.”Multiple unsuccessful deletion attempts were also made against Azure Site Recovery locks and Azure Backup protection locks protecting storage accounts.
根据微软的说法，这种破坏行为（即删除大量Azure资源，同时针对与备份和恢复相关的资源）很可能是攻击者正在为发起勒索软件攻击做准备。Weizman和Mudi指出：“从整体来看，这些行为——包括资源破坏、试图干扰恢复机制以及收集可用于访问数据的凭证——都与典型的勒索软件攻击手段相符。”不过，攻击者并未发送任何勒索赎金要求；他们表示：“在我们的观察中，既没有发现勒索赎金信息，也没有确认有任何数据被成功窃取。”
According to Microsoft, the destructive activity - deleting numerous Azure resources, while also targeting backup and recovery-related resources - seems to indicate that Storm-3168 was setting up a ransomware attack. “Taken together, the resource destruction, attempts to interfere with recovery mechanisms, and collection of credentials that could provide access to data are consistent with tactics that can support ransomware and extortion operations,” Weizman and Mudi wrote. However, no ransom note was ever sent. "We did not observe a ransom note or confirm successful data exfiltration in the activity described here," they wrote. ®