An Attacker Deleted Your Entire Azure Cloud in 7 Minutes. Here's What JADEPUFFER Means for Your Business.

On September 25th, Microsoft's security team published research that should reset how every business leader thinks about cloud risk.

A threat actor called JADEPUFFER — tracked by Microsoft as Storm-3168 — gained access to a company's Microsoft Azure environment using compromised service principals. What happened next wasn't a data breach in the traditional sense. There was no ransomware note. No encrypted files. No phishing email to blame.

The attackers simply deleted the company's cloud infrastructure. Storage accounts, SQL databases, Key Vaults, virtual machines, Function Apps, and critically, backup and recovery resources — gone. Over 100 deletion attempts in a seven-minute window, following 15 hours of quiet reconnaissance.

This is a new category of threat, and most businesses aren't prepared for it.

What Is a Service Principal — and Why Does It Matter?

Before we go further, a quick translation for non-technical leaders.

When your organization runs applications, automation tools, or IT management systems in Microsoft Azure, those tools need credentials to do their work. Rather than using a human employee's username and password, Azure uses something called a service principal — essentially an identity card for a machine or application.

Service principals can be granted sweeping permissions. An IT automation system might need the ability to read data, create resources, and delete old infrastructure. That's legitimate. The problem is that when a service principal's credentials are compromised, an attacker inherits everything that account was allowed to do — without triggering the kind of alerts that a human login anomaly might generate.

In the JADEPUFFER case, Microsoft's investigation found something particularly telling: the service principal credentials had been exposed in a public GitHub issue by an employee of the victim organization. The secret was removed once discovered — but it remained accessible through the edit history. The attackers likely found it through automated credential scanning. No sophisticated hacking required.

How the Attack Unfolded

The timeline is worth walking through, because it illustrates a level of patience and precision that most organizations are not equipped to detect.

Microsoft observed two compromised service principals operating in the victim's Azure tenant. The first spent approximately 15 hours conducting reconnaissance — over 300 successful read operations cataloging virtual machines, subscriptions, resource groups, and application configurations. Think of it as a detailed map drawn over the course of an entire business day, using legitimate cloud APIs in ways that look identical to normal administrative activity.

Then the second service principal activated. Within 35 minutes, it executed over 150 destructive or credential-collection operations. The destructive sequence itself lasted just seven minutes. More than 100 storage account deletion attempts. Azure SQL databases targeted. Key Vault contents sought. Backup and recovery infrastructure specifically prioritized — an attacker move designed to eliminate the victim's ability to recover.

Microsoft noted that Azure resource locks and storage-level deletion protection blocked some of the deletions. The backups that survived did so because someone had configured independent safeguards that remained effective even after the identity was compromised.

Everything else was gone.

Why This Is Different From a Ransomware Attack

Most executives have a mental model for ransomware: attackers encrypt your files, you can't access them, they demand payment. That model is familiar enough that it has shaped boardroom conversations about cyber risk for years.

JADEPUFFER represents an evolution. There was no ransom note in this incident. The goal, as Microsoft assessed it, was consistent with ransomware-aligned tactics — but the mechanism was different. Instead of encrypting data to hold it hostage, the attacker deleted the infrastructure itself. If your backups were also targeted and destroyed, you have no files to decrypt. You have no environment left to restore.

This matters because your recovery plan likely assumes your data exists somewhere. It assumes backups are intact. The JADEPUFFER playbook is specifically designed to invalidate those assumptions before you even know you've been attacked.

For business leaders, the question isn't whether you could pay a ransom to get your data back. The question is: if your entire cloud environment was deleted on a Monday morning, when would you have it operational again? And at what cost?

The Machine Identity Problem Is Getting Worse

JADEPUFFER was first documented by security firm Sysdig as the first known ransomware operation run end-to-end with the help of an AI large language model. The attack chain — exploiting a known software flaw, harvesting credentials, moving deeper into systems, causing destruction — was orchestrated by AI with minimal human direction.

Microsoft's expanded investigation shows the same actor is now targeting Azure specifically, using service principals as the entry point. And Microsoft observed repeated automated probing from Storm-3168 infrastructure against multiple Azure customers — not just the one organization whose environment was destroyed.

This is not an isolated incident. It's an operating pattern.

Every Azure deployment has service principals. Most organizations couldn't tell you exactly how many they have, what permissions each one holds, or when those credentials were last rotated. That gap is exactly what JADEPUFFER is designed to exploit.

Three Questions Every Business Leader Should Ask This Week

You don't need to become a cloud architect to take meaningful action. But you do need to ask your IT team or managed security provider three specific questions.

First: Can you give me a complete inventory of our Azure service principals, including their permission levels? A legitimate managed environment should have an up-to-date list. If the answer is uncertainty or hesitation, that's your first signal that this exposure exists in your organization.

Second: Are any of our service principal credentials exposed in code repositories, documentation, or version history? The JADEPUFFER victim's credentials were sitting in a GitHub edit history. Automated scanning tools can find these. If your team hasn't run one recently, the answer to whether you're exposed is effectively unknown.

Third: Are our cloud backups protected by independent resource locks, and have we tested recovery? The attacks that failed in the JADEPUFFER case failed specifically because backup resources had deletion protection configured separately from the administrative accounts. Backups that depend on the same credentials as production are not independent backups — they're a false sense of security.

The Bigger Picture

For the past several years, the dominant cyber narrative in boardrooms has been about data theft — attackers stealing customer records, financial data, intellectual property. That threat is real and ongoing.

But what JADEPUFFER illustrates is a parallel threat: attackers who aren't interested in stealing your data. They want to destroy your operational capability. They want to create a situation where recovery is so expensive, so time-consuming, and so uncertain that paying them — or accepting permanent damage — becomes the rational option.

For businesses running operations in Azure or any cloud platform, the identity layer is now the most valuable attack surface on the board. Not because cloud is inherently unsafe, but because most organizations have granted their machine identities far more permission than they need, far less monitoring than they deserve, and far weaker hygiene than they'd accept for human user accounts.

The good news from the JADEPUFFER investigation: the safeguards that worked, worked. Resource locks held. Deletion protection blocked attacks. Independent backups survived. None of that is exotic technology. It's disciplined configuration.

The businesses that will weather this new threat class are the ones that treat machine identities with the same rigor they apply to human ones — and that have tested their recovery assumptions before an attacker tests them first.

If you're not sure where your organization stands, that uncertainty is itself the answer. TrustPoint Cyber helps businesses audit their cloud identity posture, right-size service principal permissions, and build recovery architectures that survive worst-case scenarios. Start with a conversation.