How Did Storm-3168 Target 100+ Azure Storage Accounts?

In early June 2026, a Storm-3168 operation used two compromised Azure service principals to map a cloud environment for over 15 hours, then attempt more than 100 storage-account deletions in roughly seven minutes. Microsoft says most targeted storage accounts were deleted, but does not give an exact confirmed-deletion count. Microsoft attributes the activity to JADEPUFFER and says the timing strongly indicates automated or scripted execution, while earlier Sysdig research on the same actor documented genuine agentic ransomware behavior. For enterprise security and governance leaders, the incident is a clear signal to audit non-human cloud identities, tighten independent recovery controls, and treat exposed credentials as permanently compromised until revoked.

What happened

Microsoft's September 25 disclosure describes an incident that began in early June 2026 when two Azure service principals were compromised. The first identity spent approximately 15 hours and 30 minutes conducting reconnaissance, completing more than 300 successful read operations across virtual machines, subscriptions, and resource groups. A second principal then enumerated VMs and resource groups across two subscriptions in roughly five seconds.

The destructive phase began less than one second after a failed ListKey request against a nonexistent storage account. Over the next 35 minutes, the second principal attempted more than 150 destructive or credential-collection operations. This included more than 100 storage-account deletion attempts concentrated into a roughly seven-minute window, and most of the targeted storage accounts were deleted. The actor also deleted an Azure Key Vault, a Function App, and an App Service plan, and attempted to delete multiple Azure SQL databases. The SQL deletions failed only because the attacker used an unsupported API version, while some storage deletions were blocked by resource locks and deletion protection.

Approximately 30 minutes after the destructive burst, the same principal issued more than 30 successful ListKeys requests to retrieve storage-account access keys. Microsoft explicitly states it did not observe a ransom note and did not confirm successful data exfiltration, though it characterizes the pattern as consistent with a ransomware or extortion objective because the operation combined destruction, recovery-impairment, and credential collection.

Microsoft says the timing, multiple identities, and overlapping token streams "strongly indicates automated or scripted execution." The company does not claim that a large language model directly directed this specific Azure activity. However, the actor is the same JADEPUFFER group that Sysdig documented in July 2026 as the first observed case of agentic ransomware, in which an LLM drove reconnaissance, lateral movement, encryption, and extortion. CyberScoop's reporting noted that a human still established infrastructure and victim selection, but the model closed operational loops that previously required skilled operators. This distinction matters: the Azure incident proves the actor can achieve machine-speed destruction in the cloud, even if the exact decision-making layer in this instance was scripted rather than LLM-orchestrated.

Why it matters for CISOs and GRC teams

The attack is notable less for a novel exploit than for the weaponization of legitimate cloud permissions at a speed no human team can match. The compromised service principals already held roles sufficient to delete storage and application resources and retrieve storage keys. There was no vulnerability to patch - only identity governance to fix.

For governance teams, the incident highlights how non-human identities often escape the scrutiny applied to human users. Service principals, automation accounts, and workload identities accumulate permissions over time and are rarely subject to the same access reviews or termination workflows. When these credentials are compromised, the blast radius is determined entirely by the permissions they hold. A governance dashboard that tracks non-human identity sprawl and privilege drift is no longer optional for organizations operating at scale.

The targeting of recovery mechanisms is equally significant. The actor attempted to remove Azure Site Recovery and Azure Backup protection locks, a hallmark of modern ransomware operations that understand cloud architecture. If your backup strategy lives inside the same identity plane and subscription as production, it is a target, not a guarantee.

Finally, the JADEPUFFER lineage shows that agentic AI capabilities are already in the hands of threat actors. Even if this Azure event was scripted, the same group has demonstrated LLM-driven adaptation that corrected a failed login approach in 31 seconds during an earlier campaign. The gap between scripted automation and agentic AI is narrowing, and security teams should prepare for both.

Key risks and open questions

Several uncertainties should shape how leaders interpret this disclosure. First, Microsoft was careful not to label the Azure activity as LLM-directed, yet media coverage has quickly folded it into the agentic ransomware narrative. Security leaders must separate the proven facts - high-speed automated destruction using compromised principals - from the broader JADEPUFFER attribution, which includes stronger AI evidence in a separate incident. Overstating AI involvement in this specific event could lead to misallocated resources.

Second, the absence of confirmed data exfiltration does not mean data is safe. The attacker retrieved storage access keys roughly 30 minutes after the destructive phase. Those keys could enable future access or exfiltration if they are not rotated and if associated signatures are not invalidated. Organizations should assume these credentials remain compromised until explicitly revoked.

Third, the 15.5-hour reconnaissance window suggests detection opportunities were missed. A principal executing 300+ read operations across subscriptions should trigger anomaly detection. The fact that it did not - or that the alerts were not acted upon - raises questions about cloud detection engineering and the signal-to-noise ratio in modern SIEM pipelines.

Fourth, the failed SQL deletions and blocked storage deletions show that technical controls work, but only where they are applied. Inconsistent coverage across resources is what allows partial destruction to succeed.

What security and governance teams should do now

1. Audit non-human identities and enforce least privilege. Inventory every service principal, managed identity, and automation account across your cloud estates. Remove unused credentials, scope roles to specific resources rather than subscriptions, and implement recurring access reviews for non-human identities just as you do for human users.
2. Harden recovery controls independently. Place backup and disaster recovery infrastructure in separate subscriptions or tenants with distinct identity planes. Use immutable backups, air-gapped recovery options, and resource locks that require break-glass approval. If your recovery controls can be reached by the same compromised principal that owns production, they will be deleted.
3. Revoke and rotate all potentially exposed credentials. Treat any credential accessible to a compromised principal as breached until proven otherwise. Rotate storage access keys, regenerate service principal secrets and certificates, and review key vault access policies. Do not wait for confirmed exfiltration.
4. Enforce resource locks and deletion protection broadly. The only reason some storage accounts survived was resource locks and deletion protection. Apply these by default to critical data stores, key vaults, and backup resources, and govern them through policy-as-code to prevent manual override.
5. Monitor API velocity and identity behavior. Build detections for anomalous API call volumes, especially sequences that move from hundreds of read operations to destructive actions within minutes. Monitor ListKeys and similar credential-retrieval calls as high-severity events when they follow destruction or occur outside expected automation windows.
6. Correlate AI governance with cloud security posture. If your organization is deploying agentic AI tools, ensure they cannot inherit overprivileged cloud identities or access sensitive APIs without oversight. Tools like Walled AI help govern employee AI use across browsers, desktop apps, and APIs, reducing the risk that agentic tools become shadow cloud administrators.

The bigger picture

The Storm-3168 Azure incident is a template for what comes next. Cloud environments are managed by APIs, and APIs can be driven by scripts, playbooks, or increasingly by AI agents. The defensive margin is shrinking because the offensive tempo is no longer limited by human typing speed or sleep cycles. Data loss prevention strategies must now account for automated credential theft and rapid exfiltration alongside traditional endpoint and network controls.

Regulators are also watching. Under frameworks like the EU AI Act, organizations must document AI risk management and ensure human oversight of high-risk automated systems. While the Act targets deployers of AI systems, the underlying principle - that automated decision-making at scale requires governance guardrails - applies directly to cloud security. A service principal with Owner rights is, in effect, an automated system with the power to destroy your data.

The precursor JADEPUFFER campaign observed by Sysdig exploited CVE-2025-3248 in Langflow to reach a production server, then used an LLM to adapt in real time. The Azure operation used compromised credentials to achieve similar speed against cloud-native resources. Together, they show that threat actors are integrating AI-driven adaptation with cloud identity compromise to create hybrid campaigns that span on-premises, SaaS, and infrastructure-as-a-service targets.

Enterprise leaders should not treat this as a Microsoft-specific problem. The same identity-centric attack path exists in AWS IAM roles, Google Cloud service accounts, and SaaS automation workflows. The question is not whether your cloud can be mapped in 15 hours and wiped in 7 minutes - it can. The question is whether your identity governance, detection engineering, and recovery architecture can withstand a machine-speed adversary. The time to close those gaps is before the next reconnaissance session begins.