Stolen Azure App Identities Let JadePuffer Turn Cloud Access Into Destruction

Microsoft has attributed destructive activity inside Azure tenants to JadePuffer, an actor the company tracks as Storm-3168. In a detailed incident, the attacker controlled two service principals and used them to discover resources, collect credentials, delete cloud services, and interfere with recovery protections.

Microsoft published its account on September 25, 2026, describing activity in early June. Separate reporting says Microsoft observed two attacks in June, although the detailed account principally documents one sequence.

The operation caused substantial damage without exploiting a disclosed software vulnerability. Instead, JadePuffer acted through compromised application identities whose permissions allowed operations that could resemble legitimate cloud administration.

Two service principals divided the attack workload

Azure service principals are application identities used by software and automated processes to authenticate and access resources. They can be assigned Azure role-based access control permissions without requiring an interactive user account.

JadePuffer compromised two such identities in the same tenant. One was primarily used to map the environment over roughly 15.5 hours, completing more than 300 successful read operations against virtual machines, subscriptions, resource groups, and other Azure assets.

The second identity moved far faster. About 90 minutes after the broader reconnaissance began, it enumerated virtual machines and resource groups across two subscriptions in only five seconds.

That separation suggests an organized workflow: one identity built a broad inventory, while the other performed concentrated discovery and destructive actions. However, the available evidence does not establish whether this division was controlled by AI, conventional automation, or direct operator instructions.

Microsoft researchers Yossi Weizman and Tushar Mudi said this level of discovery could give an attacker visibility across a victim’s Azure environment. The operation was not limited to identifying individual workloads.

The second service principal also queried Azure App Service configuration stores, potentially looking for credentials embedded in application settings. It unsuccessfully searched for Azure OpenSearch resources and attempted a ListKey operation against a storage account that did not exist.

Less than one second after that failed request, deletion activity began.

Storage accounts and supporting services were deleted within minutes

The attacker made more than 100 attempts to delete Azure Storage accounts, and most of those operations succeeded. An Azure Key Vault, Function App, and App Service plan in the same resource group were also removed.

According to reporting on the observed Azure attacks, the destructive phase lasted approximately seven minutes and targeted virtual machines and App Services alongside storage accounts, Key Vaults, and Function Apps. Microsoft’s more detailed description covers VM discovery but does not report confirmed deletion of virtual machines.

JadePuffer also tried to delete multiple Azure SQL databases. Those attempts failed because the actor supplied an unsupported API version, showing that even a fast, automated sequence can break when its requests do not match the target service.

The operation then shifted back to storage. About 30 minutes after the deletion phase, the compromised service principal requested an inventory of Azure Storage accounts, including accounts associated with Azure Site Recovery.

It subsequently completed more than 30 successful ListKeys requests, obtaining storage access keys. These keys can provide direct access to storage accounts independently of the service principal’s original Azure RBAC permissions, depending on how the accounts are configured.

The attacker also attempted to weaken backup and recovery measures. Attempts to remove Azure Site Recovery locks failed, while resource locks and storage-account-level protections prevented the deletion of some targeted accounts.

Those controls made a measurable difference. They did not stop the operation, but they limited its reach.

A GitHub secret may explain access, but attribution remains incomplete

Microsoft could not determine exactly how the two service principals were compromised. It did find a significant potential exposure involving one of the identities.

An employee of the affected organization had posted the service principal’s client ID, client secret, and tenant ID in plaintext in a public GitHub issue. The issue was later edited to remove the secret, but the original value remained available through the public edit history.

Microsoft could not confirm that JadePuffer obtained or used that exposed credential. The finding therefore represents a plausible access path, not proven initial access.

The distinction matters because deleting a secret from the current version of a post does not invalidate copies, cached content, repository history, or platform edit records. Once a credential has entered a public system, defenders must treat it as compromised and rotate it rather than relying on content removal.

As Ross Filipek, CISO at Corsica Technologies, observed, operations performed through an application identity may also look like normal cloud administration. That can complicate detection when monitoring emphasizes failed logins or suspicious human sessions instead of unusual API behavior by workload identities.

Microsoft has also observed JadePuffer-linked infrastructure probing Azure App Services across multiple customers since the beginning of the year. Tested routes included WordPress administration paths, PHP-CGI, LangFlow’s code-validation endpoint at /api/v1/validate/code, and paths resembling web-shell locations.

It is not known whether those probes led to the compromise described here.

The ransomware pattern is clear, but the AI claim is less certain

Microsoft characterized the activity as consistent with ransomware or extortion tactics. The deletion of production resources, efforts to obtain storage keys, and attempts to interfere with recovery all fit a destructive pressure strategy.

However, investigators found no ransom note, confirmed no financial demand, and did not establish successful data exfiltration. Calling the incident ransomware therefore describes the apparent operational pattern, not a completed and verified extortion exchange.

Sysdig identified JadePuffer in July as the first documented ransomware operation driven by a large language model, according to coverage of Microsoft’s findings and the actor’s earlier activity. Its analysis described AI agents automating stages including reconnaissance, credential theft, lateral movement, persistence, and encryption.

JadePuffer reportedly later expanded its targeting to AI assets, training datasets, and vector databases, using a tool named EncForge.

The Azure incident does demonstrate highly coordinated automation. It does not independently prove that an AI agent selected or directed every API call.

Nick Tausek, lead security automation architect at Swimlane, drew that distinction while agreeing with Microsoft’s broader warning: agentic AI could allow attackers to execute operations faster and across more resources, but rapid coordination alone is not evidence that AI controlled the entire sequence.

For defenders, the practical risk is similar either way. Cloud identities can execute hundreds of discovery and deletion requests much faster than a human response team can review them manually.

Defenders should rotate exposed credentials and constrain application identities

Organizations using Azure should first identify service principals with broad access to storage, recovery systems, Key Vaults, application configuration, and resource deletion operations. Azure RBAC assignments should be reviewed against least-privilege requirements, especially where one identity can act across multiple subscriptions.

Microsoft recommends several measures:

• Enable appropriate Microsoft Defender for Cloud plans for critical Azure workloads.
• Continuously assess application credentials and secrets for exposure.
• Rotate any credential immediately when it is published or otherwise suspected of compromise.
• Establish lifecycle controls covering secret creation, storage, expiration, and revocation.
• Reduce service-principal and workload-identity permissions to the minimum required.
• Inspect public repositories, issues, comments, and revision histories for exposed credentials.

Resource locks and storage-account protections should also be applied where operationally appropriate. In this incident, they directly prevented some deletion attempts, including attacks against protected storage and recovery resources.

Monitoring should account for sequences rather than isolated events. Useful warning signs include rapid subscription-wide enumeration, access to App Service configuration stores, bursts of storage ListKeys requests, and large numbers of deletion operations performed by a service principal.

Microsoft cited Project Perception and MDASH as initiatives intended to help defenders investigate and respond across large environments using AI-supported workflows. Whatever technology supports the response, the immediate challenge is straightforward: application identities must be monitored as privileged actors, not treated as trusted background processes.