One of an organization's Azure service principals, the kind of non-human account that lets an application talk to the cloud, spent about 15 and a half hours reading its way across the company's Azure estate. A second one then tried to delete more than 100 storage accounts in roughly seven minutes. Microsoft Security Research, with researchers Yossi Weizman and Tushar Mudi, has tied that activity to JADEPUFFER, the operation Sysdig documented in July and which has been reported as the first agentic ransomware operation. Microsoft tracks it as Storm-3168.
The report is the first detailed look at the group inside Azure. It also shows how much a couple of independent safeguards can matter.
Hours of reconnaissance, minutes of deletion
In early June 2026, Microsoft says, two compromised service principals in the same tenant went to work. The first enumerated virtual machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes, with more than 300 successful read operations. Around 90 minutes in, the second enumerated virtual machines and resource groups across two subscriptions in five seconds. Both used Storm-3168 linked infrastructure, the same network fingerprint and the user agent python-requests/2.34.2.
Sixteen hours later the second identity enumerated App Service configuration stores, possibly hunting for exposed credentials. Less than a second after a failed key request against a storage account that did not exist, it started deleting. Over 35 minutes it attempted more than 150 destructive or credential-collection operations, including more than 100 storage account deletion attempts, and most of the targeted storage accounts were deleted. A Key Vault, Function App and App Service plan went too. Every attempt to delete Azure SQL databases failed because the attacker used an unsupported API version, and attempts to remove Azure Site Recovery and Azure Backup protection locks also failed. About 30 minutes after the destruction ended, the same identity sent more than 30 successful ListKeys requests, asking Azure to hand over storage account access keys, including for Site Recovery related storage.
Scripted speed, but no ransom note
Microsoft says the timing, the split of work across two identities and overlapping token streams "strongly indicates automated or scripted execution". The company frames the case as part of a broader shift toward AI-orchestrated attacks, though the evidence in this report is the automation pattern itself. It also stops short of calling this incident ransomware: the deletions, the attacks on recovery resources and the key collection are consistent with ransomware and extortion, but Microsoft did not observe a ransom note or confirm data exfiltration.
A secret edited out of GitHub was still public
How the service principals were compromised is unclear. Microsoft found that the client ID, client secret and tenant ID for one of them had been posted in plaintext in a public GitHub issue by an employee of the victim organization. The issue was later edited to remove the secret, but the secret stayed readable in the issue's public edit history. Microsoft could not confirm that this secret was used in the attack. Separately, Storm-3168 infrastructure has probed other customers' App Service sites this year, including Langflow's code validation endpoint, though not this tenant. Langflow is familiar ground: JADEPUFFER's first documented intrusion came through an exposed Langflow instance.
Rotate leaked secrets and lock the backups
- Treat any credential that has ever been public as compromised, even after the post is edited or deleted, and revoke or rotate it.
- Cut service principal permissions to what the application needs. Here, ordinary role assignments (Storage Account Contributor through a group, plus direct Contributor and SQL DB Contributor) authorized everything the attacker did.
- Use Azure resource locks and storage account deletion protection. They blocked deletion of some storage accounts even though the attacker held broad administrative permissions.
- Restrict and monitor access to backup and recovery resources.
Indicators (defanged): 45[.]131[.]66[.]106 (App Service probing and malicious ARM requests), 34[.]153[.]223[.]102 and 64[.]20[.]53[.]230 (App Service probing).
The lesson here is less about AI than about identity. One leaked secret on a non-human account could hand an automated operator everything it needs, and the only things that slowed this one down were controls that did not trust that identity.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.