Microsoft Security Research has documented a destructive intrusion into an Azure tenant by Storm-3168, its name for the actor Sysdig calls JADEPUFFER, carried out with compromised service principals. A secret for one of them had been exposed on GitHub, but Microsoft could not confirm it was used.
What happened
In a September 25 post, Microsoft tied the activity to JADEPUFFER, which Sysdig discovered in July 2026 and has described as the first documented agentic ransomware operation. Microsoft says it is unclear how the service principal was initially compromised. An employee had earlier posted its client ID, client secret and tenant ID in plaintext in a public GitHub issue; the issue was later edited, but the secret stayed visible in the edit history. Microsoft could not confirm whether that secret was used in this activity.
Microsoft's timeline of the activity, which began in early June 2026:
- Reconnaissance: the first compromised service principal spent about 15.5 hours enumerating the environment and made 300+ successful read operations. A second service principal from the same tenant became active about 90 minutes after the first.
- Destruction: roughly 70 seconds after a final inventory, the second service principal began a sequence of deletions that lasted about seven minutes. It made 100+ storage account deletion attempts and deleted an Azure Key Vault, a Function App and an App Service plan. Attempts to delete Azure SQL databases failed.
- Recovery targeting: it made several failed attempts to remove Azure Site Recovery locks and Azure Backup protection locks on storage accounts. The actor also targeted storage accounts with "terraform"- and "backup"-themed names.
- Credential collection: about 30 minutes after the last deletion, the same service principal listed storage accounts again and made 30+ successful ListKeys requests, which return each account's access keys.
Most targeted storage accounts were deleted; a few survived because Azure resource locks and storage account-level deletion protection blocked the attempts. Microsoft saw no ransom note and could not confirm exfiltration, but says the pattern fits ransomware and extortion activity. It adds that the timing, the split of work across two service principals and overlapping token streams strongly indicate automated or scripted execution.
Removing or redacting an exposed secret does not invalidate it. — Microsoft Security Research
Why it matters
This is a non-human identity failure. Whatever the initial access route, the compromised service principals had the rights to enumerate virtual machines, subscriptions, resource groups and resources, delete production resources and pull storage keys. Broad role assignments on service principals tend to go unreviewed, and a secret left in a public edit history makes one easy to take over, whether or not it was the route here.
Speed is the other lesson. The 15 hours of reads were the window to catch this; the deletions took about seven minutes. The controls that saved resources, resource locks and deletion protection, were set up in advance. The actor also tried to remove backup and recovery locks and singled out backup-themed storage, which suggests it goes after recovery options on purpose.
What to check in your environment
- Rotate anything that was ever public. Microsoft recommends treating any publicly exposed secret as compromised even after removal. Search public repositories, issues and edit history for client IDs, tenant IDs and secrets, and rotate every hit.
- Inventory service principals with secrets and broad roles. Flag any that authenticate with client secrets and hold write or delete rights at subscription or resource-group scope, or can list storage account keys.
- Cut RBAC down to what the app needs. Microsoft recommends limiting service principal permissions to the resources and operations the application actually uses.
- Apply resource locks and deletion protection to storage accounts, Key Vaults and anything holding backups or Terraform state. In this incident, those controls stopped some deletions.
- Separate backup management from workload management. Restrict access to backup and recovery resources and alert on attempts to change or remove Azure Backup or Site Recovery protection.
- Watch for slow reconnaissance by service principals. Hundreds of reads across many resource types by a non-human identity is the early warning. Microsoft lists Defender for Cloud plans (Resource Manager, Storage, Key Vault, App Service, Databases) whose alerts cover parts of this activity, and publishes IP indicators.
- Plan to move off client secrets. Not in Microsoft's guidance, but where a workload can use a managed identity or federated credential, there's no secret to leak.