The malware emerged in July and evolved quickly. Cloud security firm Sysdig flagged its use of AI agents to automate the entire attack chain, covering reconnaissance, credential theft, lateral movement, persistence, and data encryption in a single continuous run. JadePuffer later expanded its focus to AI assets, training datasets, and vector databases, often using a tool called EncForge.
Seven Minutes, Over 100 Storage Accounts
Microsoft Security Research tracks JadePuffer as Storm-3168 and observed two attacks in June. The group first mapped cloud resources and retrieved storage account keys before moving to the destructive phase, which took just seven minutes and hit over 100 storage accounts. Key Vaults, Function Apps, Virtual Machines, and App Services were also targeted.
Storm-3168 operated through two compromised service principals, the security identities that let applications and automated tools access Azure resources. Both belonged to the same tenant, with one handling reconnaissance while the other carried out discovery, destructive operations, and credential collection. Microsoft could not pinpoint the initial access method, though credentials for one service principal had appeared in a public GitHub issue before the attacks began.
Where Azure’s Defenses Held
The attacks were not entirely successful. Azure’s built-in defenses stopped several destructive attempts outright. Some targeted storage accounts survived because existing resource locks and storage account level protections were already in place. Attempts to delete Azure SQL databases also failed, and according to Microsoft, the attacker used an unsupported API version that the platform simply rejected. Attempts to remove recovery protection locks failed as well.
Microsoft noted that the parallel targeting of Azure SQL databases and storage accounts suggests an effort to broaden the destructive impact across different data services rather than concentrating on a single resource type.
Roughly half an hour after the failed wipe attempts, Storm-3168 came back and made over 30 requests for storage account keys, most of which succeeded.
Locking Down Azure Against Agent-Driven Attacks
System administrators can take several concrete steps to protect Azure resources from attacks like this one:
- Activate cloud workload protections with threat detection and response capabilities across all Azure workloads
- Check public repositories for exposed secrets regularly, and rotate any compromised service principal keys immediately
- Review Azure RBAC permissions to ensure every identity holds only the access it actually needs
- Apply resource locks to critical Azure resources to prevent accidental or malicious deletion
- Enable storage account protections including soft delete, versioning, and immutability policies
- Secure backup and recovery by locking Azure Site Recovery settings against unauthorized removal
Hashlytics Take
The headline here is “AI automates a ransomware attack,” but the more useful story is what stopped it. Every defense that actually held (resource locks, an outdated API rejection, storage protections) was a boring, pre-existing control that had nothing to do with AI. The attacker automated speed and scale, not sophistication. That’s a meaningful distinction for anyone deciding where to spend security budget right now. The fix for agentic attacks isn’t a new category of AI-defense tooling, it’s making sure the basic Azure hygiene checklist above actually gets done.
Follow Hashlytics on Bluesky, Facebook, LinkedIn , Telegram and X to Get Instant Updates
