Key Takeaways

  • Storm-3168 used two compromised Azure service principals to enumerate and delete cloud resources.
  • Microsoft observed more than 300 successful read operations during roughly 15.5 hours of enumeration.
  • Excessive machine-account privileges can turn one stolen credential into a broad cloud outage.

The cloud attack documented by Microsoft shows how quickly a trusted machine identity can become a destructive access channel. Storm-3168, Microsoft’s tracking name for JADEPUFFER, used two compromised Azure service principals to conduct reconnaissance, collect credentials, and delete resources across a victim’s cloud environment.

According to the Microsoft Security Blog, the attacker completed more than 300 successful read operations during roughly 15.5 hours of enumeration. That activity appears to have helped Storm-3168 map the environment before moving against Azure Storage, SQL, Key Vault, virtual machine, Function App, and App Service resources.

The result was not merely a compromised account. It was a cloud control-plane attack capable of removing applications, data services, secrets, and supporting infrastructure through legitimate administrative interfaces.

Microsoft did not confirm data exfiltration or the delivery of a ransom note. Although the resource destruction resembled the impact stage of some ransomware operations, the available evidence does not establish a conventional encrypt-and-extort campaign. Storm-3168 may have pursued disruption, coercion, or another objective that remains unclear.

Service principals are not ordinary user accounts. Microsoft Entra ID uses them to give applications, automation processes, and services access to Azure resources. They often operate without direct human interaction, and their activity can blend into expected API traffic. If one has broad permissions, a compromised credential may provide an attacker with the same reach as the associated workload.

That helps explain the deliberate reconnaissance. More than 300 read operations gave Storm-3168 time to identify accessible subscriptions, resources, secrets, and potential deletion targets. Because the requests came through valid identities, simple authentication-success monitoring would have offered limited protection. The relevant question is not just whether access succeeded, but whether the identity was behaving as expected.

The scale of machine-account exposure extends beyond this incident. Research summarized by the Non-Human Identity Management Group found that 93% of organizations had at least one overprivileged service account, while 78% had an IAM role unused for more than 90 days. Wiz reported in 2026 that 97% of non-human identities had excessive privileges, and that machine identities can outnumber human accounts 100:1 in highly automated environments.

Those numbers point to a quiet governance gap. Enterprises have spent years improving multifactor authentication and conditional access for employees, but service principals, API identities, and automation credentials may retain standing privileges for months. Some are created for a deployment and then forgotten. Others accumulate permissions as applications evolve.

Agentic systems raise the stakes further. The Cloud Security Alliance notes that such systems can invoke APIs, execute code, spawn sub-agents, and chain actions across multiple services. That autonomy can improve productivity, but it can also increase the blast radius when an underlying credential is stolen or misused.

A separate Entra Agent ID Administrator flaw illustrated another possible escalation route. As described by the Cloud Security Alliance, a compromised service principal could have been used to add an attacker-controlled owner and issue fresh credentials, potentially creating a tenant-takeover path. Microsoft patched that issue across clouds by April 9, 2026.

Defenders can respond by reducing standing permissions, removing dormant roles, rotating credentials, and preferring short-lived or managed identities where practical. High-impact actions such as deleting Key Vaults, storage accounts, databases, or application services also warrant stronger controls and rapid alerts. Backup design deserves scrutiny too, particularly whether recovery assets sit outside the permissions available to production automation.

Zero-trust principles apply to workloads as much as people: verify each request, constrain access, and assume a trusted identity may be compromised. Storm-3168 demonstrates why. In cloud environments, destruction may arrive through valid credentials and ordinary APIs, without malware ever touching a traditional endpoint.