HIGH: Microsoft Azure Attack Used Leaked Service Principals to Delete Storage

Here is a fun way to ruin a Tuesday. Someone at your company pastes an Azure client ID, a client secret, and a tenant ID into a public GitHub issue while troubleshooting a deployment. A colleague notices, edits the issue, and deletes the secret. Everyone breathes a sigh of relief and moves on. Months later, an automated attacker pulls that secret straight out of the issue's edit history, logs in as your service principal, spends sixteen quiet hours mapping your cloud, and then deletes more than a hundred storage accounts in about seven minutes.

That is roughly the story Microsoft told on September 25, 2026, when its security research team published a detailed write-up of an intrusion it attributes to a group it tracks as Storm-3168. The activity lines up with JADEPUFFER, the crew Sysdig first documented in July as what it called the first ransomware operation run end to end with the help of a large language model. Microsoft describes the June 2026 Azure intrusion as an evolution of that group's tradecraft, and after reading the telemetry it is hard to disagree. This was not a person clicking around the Azure portal at 2 a.m. This was a script with a plan.

How the intrusion unfolded

The entire operation ran about 18 hours from start to finish, and it leaned on two service principals that lived in the same tenant. The first one did reconnaissance. Over roughly 16 hours it issued more than 300 successful read operations, listing virtual machines, subscriptions, resource groups, and resources. That is patient, boring work, and patience is exactly what most cloud alerting is not tuned to catch.

About 90 minutes after that first identity started poking around, the second service principal showed up and enumerated virtual machines and resource groups across two subscriptions in five seconds. Five seconds. No human types that fast, and Microsoft made the same point, noting that the division of work across multiple service principals and the tight timing between operations strongly indicates automated or scripted execution. Researchers also observed the destructive identity juggling five separate access tokens, four used for deletion and one for inventory and key retrieval, with two deletion tokens running at the same time for about 70 seconds. That is parallelism, not panic.

Around the sixteen hour mark, the second identity turned its attention to Azure App Service configuration stores, which Microsoft reads as a hunt for exposed credentials. Then came the part that matters most. Inside a 35 minute window the attacker fired off more than 150 destructive or credential collection operations, with the actual destruction compressed into about seven minutes. More than 100 storage account deletion attempts went out, and most of them succeeded. A Key Vault, a Function App, and an App Service plan went with them. The attacker also went after the things you would use to recover, trying to remove Azure Site Recovery and Azure Backup protection locks and prioritizing storage accounts whose names suggested Terraform state or backup data.

And because deleting your stuff apparently was not enough, the identity came back roughly 30 minutes later, inventoried the storage accounts that were still standing, and issued more than 30 successful ListKeys requests. If you have ever wondered why storage account access keys are a problem, that is why. Every one of those calls hands over a key that grants full data plane access to the account, no Entra ID sign in required.

No ransom note, but make no mistake about the intent

Microsoft did not observe a ransom note in this case and could not confirm data exfiltration. What it did see was destruction, deliberate interference with recovery, and the collection of keys, which is the same playbook any ransomware crew runs before it asks for money. Microsoft assessed the end goal as ransomware aligned, and the evidence supports that. When an attacker specifically targets your backup locks and your Terraform state, they are not vandalizing. They are removing your options.

The JADEPUFFER backstory makes this more interesting. Sysdig's July research described the group breaking into an exposed Langflow instance through CVE-2025-3248, a missing authentication bug in Langflow's code validation endpoint, and then letting an autonomous agent take it from there. That agent harvested and reused credentials, moved laterally, established persistence, encrypted Nacos configuration files, dropped database tables using MySQL's own AES_ENCRYPT() function, and left a Bitcoin ransom note, all while narrating its own reasoning. A follow on attack against the same Langflow host delivered ENCFORGE, a Go based ransomware strain that hunts for model checkpoints, embeddings, and training datasets across roughly 180 file extensions. Storm-3168 in Azure looks like the same operator graduating from a single vulnerable box to an entire cloud tenant.

The good news hiding in the telemetry

This story is not all doom, and the parts that failed are the most useful for defenders. Azure resource locks and storage account level deletion protection stopped the attacker cold on several storage accounts. The attempts to strip Site Recovery and Backup protection locks were unsuccessful. Every attempt to delete Azure SQL databases failed too, not because of any clever control but because the attacker's script called an API version Azure no longer supports. Automation is fast, but it is also dumb in very specific ways, and sometimes a stale API string is the only thing standing between you and a very long weekend.

The bigger lesson is that nothing in this attack required privilege escalation, malware on an endpoint, or a zero day. The service principals already had the permissions. The attacker simply used them, which means your EDR saw nothing and your firewall saw ordinary Azure Resource Manager traffic. Microsoft also noted repeated probing from Storm-3168 linked infrastructure against Azure App Services belonging to several different customers, so this is not a one tenant problem. Microsoft shared the infrastructure IP addresses 45.131.66[.]106, 34.153.223[.]102, and 64.20.53[.]230, along with the user agent string python-requests/2.34.2, which is worth a query in your sign in and activity logs today.

What to do right now

Start with the uncomfortable assumption Microsoft spelled out plainly. Publicly exposed credentials remain usable until they are revoked or rotated, and deleting the original post does not fix anything. GitHub issues, pull request comments, gists, wikis, and commit histories all keep edits, and attackers have scrapers that read them faster than you do. If a secret has ever touched a public surface, treat it as compromised and rotate it, then go back and confirm nothing used it in the meantime.

Next, take inventory of your service principals and app registrations, and be honest about how many of them have Contributor or Owner at the subscription scope because it was easier than figuring out the right role. Least privilege for workload identities is not glamorous, but it is the single control that would have shrunk this attack to a nuisance. Where you can, move away from client secrets entirely in favor of managed identities or workload identity federation, which eliminates the long lived secret that got pasted into GitHub in the first place. For the secrets you cannot kill yet, set short expirations and turn on credential scanning across your repositories, configuration files, and issue trackers. GitHub secret scanning with push protection costs you almost nothing and catches exactly this mistake.

Then protect the things an attacker wants to destroy. Put CanNotDelete resource locks on production storage accounts, Key Vaults, and anything holding Terraform state. Enable soft delete and deletion protection on storage accounts and Key Vaults. Turn on immutability for Azure Backup vaults and require multi user authorization for changes to backup protection, so a single compromised identity cannot quietly disable your safety net. Consider disabling shared key authorization on storage accounts that do not need it, which makes those ListKeys calls far less valuable.

On the detection side, Microsoft recommends enabling Defender for Cloud plans covering Resource Manager, Storage, Key Vault, App Service, and Databases. Beyond that, build alerts in Sentinel or whatever SIEM you run for a service principal performing bulk deletes, for multiple ListKeys operations in a short window, for enumeration across subscriptions at machine speed, and for any change or removal of resource locks and backup protection policies. Also watch for a workload identity that normally authenticates from one predictable Azure region suddenly signing in from somewhere new. Service principals are creatures of habit, and they make excellent canaries when you actually watch them.

Finally, test your recovery with the assumption that your primary subscription is gone. If your backups live in the same subscription, under the same identities, protected by the same locks an attacker can reach, you do not have backups. You have copies.

The MSP angle

Every Azure tenant you manage almost certainly has an old service principal with too much access and a secret that expires sometime after the heat death of the universe, which makes a workload identity and backup resilience assessment an easy conversation to start this week. Package service principal cleanup, credential scanning, resource locks, and immutable backup configuration into a fixed price cloud hardening engagement, then attach ongoing Defender for Cloud and SIEM monitoring as the recurring service that keeps it that way.