Deletion or credential-collection operations attempted by the second service principal in 35 minutes: 150+ (Source: Microsoft Security Research, Storm-3168 analysis)
What Microsoft observed
Microsoft Security Research has published findings about Storm-3168, its tracking name for JADEPUFFER. Sysdig discovered the actor in July 2026 and reported it to be the first documented agentic ransomware operation. Microsoft's account covers a different layer: the actor's Azure activity in one compromised tenant.
Two compromised service principals, which are non-human workload identities, divided the work. One performed reconnaissance. In early June 2026 it enumerated virtual machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes, with 300+ successful read operations. The second performed discovery, resource deletion and credential collection.
Microsoft says the timing between operations, the division of work across identities and overlapping token streams "strongly indicates automated or scripted execution." Both identities used the same network fingerprint and the user agent python-requests/2.34.2.
Where safeguards held, and where they did not
The deletion sequence lasted about seven minutes. Most of the targeted Azure Storage accounts were deleted. A Key Vault, a Function App and an App Service plan were also removed. The actor also made unsuccessful attempts to remove Azure Site Recovery and Azure Backup protection locks, and it targeted storage accounts with terraform- and backup-themed names. Microsoft says this was potentially aimed at impairing recovery.
Some attempts failed. Azure resource locks and storage account-level deletion protection blocked deletion of a few storage accounts. Microsoft says this shows the value of independent safeguards that remain effective even when a compromised identity has broad administrative permissions. The attempts to delete Azure SQL databases all failed because the actor used an unsupported API version.
The actor did not exceed the identity's permissions. Microsoft reports that the operations followed existing role assignments. A group-granted Storage Account Contributor role authorized the storage deletions, and direct Contributor access authorized the application-resource deletions. About 30 minutes after the final deletion activity, the same identity sent 30+ successful ListKeys requests for storage account access keys.
The credential question
Microsoft found that the service principal's client ID, client secret and tenant ID had been posted in plaintext in a public GitHub issue by an employee of the affected organization. The issue was later edited to remove the secret, but the secret stayed visible in the issue's public edit history. Microsoft states that it could not confirm this secret was used in the activity it describes, and that it is unclear how the identity was initially compromised.
Microsoft's guidance on the exposure is direct: removing or redacting a secret does not invalidate it. Credentials exposed in any public location should be treated as compromised and revoked or rotated.
What is not established
Microsoft did not observe a ransom note or confirm data exfiltration. It describes the combination of resource deletion, recovery interference and key collection as consistent with tactics that can support ransomware and extortion. It also describes the activity as part of a broader shift toward AI-orchestrated attacks. Microsoft's account documents automated or scripted execution; the agentic characterization comes from Sysdig's reporting on JADEPUFFER.
What to ask your team
1. Which service principals in our tenants hold Contributor or Storage Account Contributor roles, including roles granted through groups? What is the minimum each application needs?
2. Do backup and recovery resources carry resource locks and deletion protection that a broadly permissioned identity cannot remove? In this incident, those controls blocked some deletions.
3. Have we searched public repositories, issues and their edit histories for client secrets, storage keys and connection strings? If we find one, is it rotated rather than only redacted?
4. If one identity issued 100+ deletion attempts in seven minutes in our environment, which alert would fire, who would receive it, and how quickly could that identity be disabled?
