JadePuffer AI Actor Compromises Azure Tenant in Destructive Cloud Attack

Hands typing on a keyboard with a transparent screen that says LLM surrounded by other tech icons
Source: Boy WWirat via Getty Images

An agentic AI attacker turned compromised Microsoft Azure credentials into a weapon for destroying cloud resources in minutes in what appeared to be a ransomware or extortion attack.

Microsoft attributed the attack to JadePuffer, which it tracks as Storm-3168. Sysdig researchers identified the group in July as the first documented large language model (LLM)-driven ransomware operation.

In this case, JadePuffer compromised two legitimate service principals and then spent hours mapping the victim's environment, according to a Microsoft Security Research blog post published on Sept. 25. After performing reconnaissance, the attacker launched a highly automated destruction campaign that attempted to wipe storage, applications, and databases while targeting backup and recovery controls.

As a whole, the activity is consistent with tactics that support ransomware and extortion operations, Microsoft said. "However, we did not observe a ransom note or confirm successful data exfiltration in the activity described here," according to the post, attributed to Microsoft Security Research and researchers Yossi Weizman and Tushar Mudi.

Reconnaissance First, Then Destruction

Microsoft detailed the attack, which took place in early June, in which JadePuffer compromised two service principals belonging to the same Azure tenant. One performed reconnaissance and resource discovery; the other handled discovery, destructive operations, and credential collection.

The first compromised service principal spent about 15-1/2 hours mapping virtual machines (VMs), subscriptions, resource groups, and other resources, while conducting more than 300 successful read operations. About 90 minutes after that reconnaissance began, the second service principal enumerated VMs and resource groups across two subscriptions in just five seconds.

"This breadth of activity would give the threat actor visibility across the organization’s Azure environment," Weizman and Mudi wrote.

Sixteen hours later, the second service principal successfully enumerated Azure App Service configuration stores, potentially looking for exposed credentials, and made unsuccessful attempts to look for Azure OpenSearch resources. The service principal also attempted a ListKey operation against a nonexistent storage account.

Less than a second later, the destructive activity began, with more than 100 attempts to delete storage accounts, most of which succeeded. JadePuffer also deleted an Azure Key Vault, Function App, and App Service plan in the same resource group. The same service principal also attempted to delete multiple Azure SQL databases in parallel, but the attempts failed because the attacker used an unsupported API version.

About 30 minutes after the destructive activity, the service principal made an inventory request for Azure Storage accounts, including Site Recovery-related accounts, followed by more than 30 successful ListKeys requests to retrieve their access keys.

Exposed Secrets in GitHub

Microsoft isn't certain how the attacker initially compromised the service principal, but found that its client ID, client secret, and tenant ID had previously been exposed in plaintext in a public GitHub issue by an employee of the affected organization. The issue was later edited to remove the exposed secret, but the information remained accessible through its public edit history. Microsoft could not confirm whether the exposed credential was used in the attack.

Still, the acknowledgement of credential exposure potentially being a factor "is a useful warning about how a routine cleanup can leave an account exposed," observes Ross Filipek, chief information security officer at Corsica Technologies. "Once attackers hold an application identity, their activity can look like ordinary cloud administration."

The attack expands the known JadePuffer activity into Azure and highlights the potential for AI-orchestrated attacks to coordinate complex post-compromise operations across cloud environments "with greater speed and scale," Microsoft said.

However, one expert says he's not convinced that the attack was completely AI-directed, like JadePuffer's previous activity was. "I agree with Microsoft’s warning about AI-orchestrated attacks, though the Azure evidence shows coordinated automation rather than proving AI directed each step," says Nick Tausek, lead security automation architect at Swimlane.

However, he acknowledges that agentic AI can still be a dangerous adversary.

In fact, Microsoft said that since the beginning of the year, JadePuffer-linked infrastructure has been probing multiple Azure App services across different customers. The agent appears to be testing various ways to infiltrate cloud environments, including through "WordPress administration, PHP-CGI, LangFlow’s code validation endpoint (/api/v1/validate/code), and other web-shell like paths," according to the post.

Protecting Azure Environments From JadePuffer

Indeed, as the capabilities of agentic AI attackers evolve — and autonomous AI attacks become increasingly common to an even frightening degree — defenders must respond in kind, also using AI to mitigate threats, Microsoft advised.

"Rather than requiring analysts to manually follow each individual action, efforts such as Project Perception and MDASH are intended to support a model in which defenders can investigate and respond across increasingly large and complex environments using AI," the researchers wrote.

Microsoft also recommended various mitigations in its post to reduce the risk and impact of activity similar to that conducted by JadePuffer. This advice includes enabling appropriate Microsoft Defender for Cloud plans for critical Azure workloads; protecting and continuously assessing application credentials and secrets; rotating compromised or exposed credentials immediately and establishing credential life-cycle practices; and applying the principle of least privilege to service principals and other workload identities, among other mitigations.

Dive deeper

Free tools to verify and analyze what this article covers:

source: DarkReading