JadePuffer agentic AI attacks target Azure, destroy cloud resources

The JadePuffer ransomware operator is targeting Azure tenants with agent-driven attacks that conduct reconnaissance, steal credentials, and destroy core components.

The malware emerged in July, with researchers at cloud security company Sysdig highlighting that it uses AI agents to automate the entire attack chain, from reconnaissance, credential theft, and lateral movement to persistence and data encryption.

Shortly after, the company noted that JadePuffer expanded its focus to AI assets, training datasets, and vector databases, using a tool called EncForge.

Microsoft Security Research observed two JadePuffer attacks in June that mapped cloud resources, retrieved storage account keys, and deleted Azure Storage accounts.

The destructive stage lasted seven minutes and targeted more than 100 storage accounts, as well as Key Vaults, Function Apps, Virtual Machines, and App Services.

Although the threat actor was able to delete most of the targeted Azure Storage accounts, some remained unaffected because of Azure resource locks and storage account-level protections.

Microsoft tracks the JadePuffer threat actor as Storm-3168 and says it used two compromised service principals - security identities that enable applications, hosted services, and automated tools to authenticate to Azure and access assigned resources.

Both service principals belonged to the same tenant. One was used for reconnaissance and resource discovery, while the other "performed discovery, destructive operations, and credential collection."

The attacker removed backup and recovery protections (Azure Site Recovery locks), indicating an effort to make restoration more difficult.

This operational pattern could further support ransomware extortion, although Microsoft did not report anything about financial demands and didn’t confirm data theft in the observed cases.

According to the researchers, attempts to delete Azure SQL databases failed because the attacker used an unsupported API version. Attempts to remove recovery protection locks also failed.

“The parallel targeting of Azure SQL databases and storage accounts suggests an effort to broaden the destructive impact across different data services rather than concentrating on a single resource type,” Microsoft said.

Roughly half an hour after the wipe attempts, Storm-3168 returned to perform more than 30 requests for storage account keys, most of which succeeded.

Microsoft could not determine exactly how the initial access occurred, but noted that credentials for one service principal appeared in a public GitHub issue before the attacks.

The researchers recommend several mitigation steps and guidance for system administrators, including activating cloud workload protections, checking for secrets in public repositories, and evaluating Azure RBAC permissions against least-privilege principles.