Microsoft’s latest Storm-3168 reporting is a clean warning for cloud-heavy organizations: workload identities can become ransomware infrastructure. The incident Microsoft described did not start with a flashy endpoint payload. It centered on compromised Azure service principals that were used for discovery, destructive actions, and credential collection inside a victim cloud environment.

That matters for small businesses and government contractors because service principals often sit outside the normal user-focused security program. They may not have MFA. They may carry broad permissions for automation. Their secrets may live in scripts, repositories, issue trackers, CI/CD systems, or old configuration files. When one of those identities is exposed, attackers can move at machine speed.

What Microsoft reported

Microsoft tracks the activity as Storm-3168 and associates it with JADEPUFFER, a threat actor previously reported by Sysdig as an agentic ransomware operation. In the Azure activity Microsoft analyzed, two compromised service principals belonging to the same tenant were used in coordinated cloud operations.

One identity performed extended reconnaissance for roughly 15 and a half hours, including hundreds of successful read operations across virtual machines, subscriptions, resource groups, and other Azure resources. A second identity then moved much faster, enumerating resources across two subscriptions in seconds before attempting destructive operations and credential collection.

The most important detail is the timing. Microsoft observed a destructive sequence lasting about seven minutes, with more than 100 storage account deletion attempts. The same identity also deleted supporting application resources such as a Key Vault, Function App, and App Service plan, attempted to delete Azure SQL databases, and tried to interfere with recovery-related locks. Later, it issued more than 30 successful storage account key retrieval requests.

Why this matters

This is the cloud version of pre-ransomware tradecraft. Instead of first landing on endpoints and then pushing an encryptor, the attacker used cloud control-plane permissions to discover assets, delete resources, target recovery safeguards, and collect keys that could expose data.

For defenders, the lesson is not “watch for Storm-3168 only.” The lesson is that service principals, managed identities, API tokens, storage keys, and automation accounts are Tier-0 assets when they can delete production resources or retrieve data-access keys. If those identities are treated as background plumbing, they become quiet blast-radius multipliers.

Defensive takeaways for SMBs and contractors

  • Inventory workload identities like privileged users. Track every service principal, app registration, managed identity, client secret, certificate, and storage key with an owner, purpose, expiration date, and approved permission scope.
  • Remove standing delete permissions where possible. Automation identities that only need read, deploy, or limited write access should not have broad Contributor rights across subscriptions or recovery resources.
  • Protect recovery controls from the same blast radius. Resource locks, backup vaults, recovery services, immutable storage, and break-glass paths should not be removable by the same identities used for routine operations.
  • Treat exposed secrets as compromised, not cleaned up. Deleting a GitHub issue, editing a ticket, or removing a leaked value from a repository does not revoke the credential. Rotate it and review historical use.
  • Alert on cloud control-plane bursts. Rapid subscription enumeration, mass storage delete attempts, repeated ListKeys operations, failed backup-lock deletions, and unusual API user agents deserve high-priority review.
  • Prefer short-lived and federated credentials. Where possible, move away from long-lived client secrets toward workload identity federation, certificate-backed authentication with lifecycle controls, and just-in-time privileged access.

What to hunt

Microsoft’s report calls out behaviors defenders can translate into cloud detections: unusual Azure Resource Manager activity from suspicious infrastructure, high-volume storage key access, unusual Key Vault operation patterns, large storage or database extraction, and operations against backup or recovery protections.

Organizations should also look for service-principal activity that does not match the identity’s job. A deployment identity suddenly listing storage keys, deleting resource groups, probing recovery locks, or touching subscriptions it rarely uses is not normal automation noise. It is a potential cloud incident.

Bulwark Black assessment

Storm-3168 is a useful marker for where cloud attacks are going: faster, more automated, and less dependent on traditional malware. The identity layer is the battlefield. If an attacker can take over a service principal with broad permissions, they may not need to compromise many endpoints to cause major damage.

The practical answer is boring but effective: least privilege, secret rotation, workload identity inventory, deletion protection, immutable recovery paths, and cloud activity monitoring that treats automation accounts as privileged actors. For government contractors, this also ties directly into auditability and resilience expectations. You need to know which machine identities can touch regulated data, who owns them, and how quickly you can revoke them when they leak.

Original source: Microsoft Security Blog — Storm-3168: Agentic-driven cloud attacks using compromised service principals.