JadePuffer crims hijacked Azure identities and used them to blow up cloud resources

REG AD

Smells like more agentic ransomware, Redmond warns

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.

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.

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. 

“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. 

“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.

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.

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.

“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.

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.

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. ®