Data Breaches

Storm-3168 Attack Deletes Azure Storage via Stolen Accounts

September 25, 20264 min read

By Lina Petrov — 8 years reviewing consumer technology

Storm-3168 Attack Deletes Azure Storage via Stolen Accounts

Storm-3168 Azure Attack: What Happened

Microsoft has disclosed a campaign it tracks as Storm-3168 in which attackers compromised Azure service principals, the identity objects that applications and automated services use to authenticate to Azure, and used that access to delete storage accounts. According to Microsoft's own account, the activity looks less like a smash-and-grab data theft operation and more like ransomware preparation or active disruption. Notably, Microsoft has not confirmed that extortion or data exfiltration occurred in this particular incident, even though the tactics resemble the early stages of a ransomware attack.

That distinction matters. Deleting storage accounts can be just as damaging as encrypting them, especially if there's no backup, but it's a different threat model than an attacker quietly copying files before disappearing. For organizations relying on Azure, the takeaway is that an attacker didn't need to steal data to cause serious harm. Gaining control of the right identity was enough.

Why Service Principals Are a Prime Target

Service principals are easy to overlook because they aren't human user accounts. They're the credentials that let one Azure service or application talk to another, often with elevated permissions and minimal day-to-day oversight. That makes them an attractive target for attackers: compromise one, and you may inherit broad access to storage, databases, or infrastructure without ever touching a person's login screen.

This is part of a broader pattern security researchers have been flagging across Microsoft's cloud ecosystem. Attackers increasingly go after the credentials and trust relationships that sit behind the scenes rather than targeting end users directly. It's a similar logic to campaigns like Storm-3032's voice phishing operation targeting BYOD devices for Microsoft 365 access, where the goal isn't to trick a person into handing over a password on the spot, but to find the weakest link in an identity chain and ride it into a much larger environment.

A Related Warning: The Ransom Note Hidden in a Database

While the Storm-3168 Azure incident hasn't (as documented so far) escalated to extortion, a separate case reported by security firm Sysdig shows where this kind of access can lead if left unchecked. In that incident, summarized by SOCFortress, an attacker who gained access to a database environment encrypted data, dropped database tables, and left behind a ransom demand. Researchers found that the attacker had created a table named README_RANSOM containing a Bitcoin wallet address and a Proton Mail contact for negotiating payment.

Microsoft's Storm-3168 activity didn't reach that stage, but the parallel is instructive. Both cases started the same way: an attacker got hold of credentials or access that should have been tightly controlled, and used that foothold to threaten the integrity of stored data. Whether the end result is deletion, encryption, or a ransom note, the root cause is the same. Someone got into an account that shouldn't have been reachable.

What This Means For You

If your organization or personal projects rely on Azure or similar cloud platforms, this campaign is a reminder that identity security, not just perimeter defense, is where these attacks are won or lost. A few practical steps apply whether you're managing enterprise infrastructure or a small business's cloud storage:

Audit service principal permissions regularly. Many organizations grant broad access when setting up automation and never revisit it. Scope permissions down to only what's needed.
Enable multi-factor authentication everywhere it's supported, including for administrative and service accounts, not just standard user logins.
Review access logs for unusual authentication patterns, especially sign-ins from unexpected locations or at odd hours tied to service accounts.
Back up storage accounts independently of the primary environment so that deletion or encryption doesn't mean permanent loss.
Rotate credentials and secrets on a schedule, rather than leaving service principal keys valid indefinitely.

Credential theft remains one of the most common paths into cloud environments, and strong authentication combined with careful access management does more to stop these attacks than any single tool. Using a VPN to protect the networks your admins and remote staff connect from adds another layer, but it works best alongside, not instead of, solid identity hygiene.

Takeaways

The Storm-3168 Azure attack shows that attackers don't need to exfiltrate data to cause damage; deleting storage accounts through compromised service principals is disruptive enough on its own. Combined with the Sysdig case's ransom note detail, it's a clear signal that cloud identity management deserves the same scrutiny organizations give to firewalls and endpoint security. Reviewing who and what has access to your cloud storage, tightening permissions, and enabling multi-factor authentication across every account type are practical steps you can take today to reduce the risk of becoming the next case study.

// FAQ

What did the Storm-3168 attackers do after compromising Azure service principals?

They used the access to delete storage accounts. Microsoft describes the activity as resembling ransomware preparation or active disruption rather than data theft.

Did Microsoft confirm any data exfiltration or extortion in the Storm-3168 incident?

No, Microsoft has not confirmed that extortion or data exfiltration occurred in this particular incident. The tactics resemble the early stages of a ransomware attack, but that stage wasn't reached.

What are Azure service principals and why are they targeted?

Service principals are identity objects that applications and automated services use to authenticate to Azure. Attackers target them because they often have elevated permissions and minimal day-to-day oversight, so compromising one can grant broad access without touching a human login.

What was the separate database ransom incident reported by Sysdig?

An attacker gained access to a database environment, encrypted data, dropped database tables, and left a ransom demand. Researchers found a table named README_RANSOM containing a Bitcoin wallet address and a Proton Mail contact for negotiation.

What is the key lesson from the Storm-3168 Azure attack?

An attacker doesn't need to steal data to cause serious harm—gaining control of the right identity can be enough. Deleting storage accounts can be just as damaging as encrypting them, especially without backups.