Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

Storm-3168: A Leaked Azure Secret Turned Into a 7-Minute Data-Wiping Spree

A plaintext credential left in a public GitHub issue gave attackers a foothold that ended in the mass deletion of Azure storage accounts, a Key Vault and a Function App — in under seven minutes.

4T4Tify Team4Tify
Sep 29, 2026·6 min read
Storm-3168: A Leaked Azure Secret Turned Into a 7-Minute Data-Wiping Spree

A leaked secret, and seven minutes to wipe it all

A single leaked credential — a client ID, secret and tenant ID posted in plaintext inside a public GitHub issue — was enough to hand a threat actor tracked as Storm-3168 a path into a victim's Azure environment. What followed is a textbook lesson in how fast automation turns a credential leak into a destructive incident: in roughly seven minutes, the attacker deleted dozens of storage accounts, along with a Key Vault, a Function App and an App Service plan.

What happened

Storm-3168 didn't rush in. The first compromised service principal spent about 15.5 hours quietly mapping the environment — more than 300 read operations across virtual machines, subscriptions, resource groups and other resources, part of an ARM activity window spanning roughly 18 hours.

About 90 minutes later, a second identity picked up the reconnaissance, scanning VMs and resource groups across two subscriptions in just five seconds, then moving on to Azure App Configuration stores — likely hunting for more exposed secrets — and probing Azure OpenSearch resources, which came back empty.

Roughly 16 hours after the first reads began, that same identity ran a final pre-impact inventory, then attempted to pull a key from a storage account that didn't exist. Less than a second after that failed probe, the destructive phase began: over about seven minutes, the attacker made more than 100 attempts to delete storage accounts, successfully removing most of them, along with a Key Vault, Function App and App Service plan tied to the same resource group.

Parallel attempts to delete Azure SQL databases all failed — they relied on an unsupported API version — and the actor separately went after Site Recovery and Azure Backup protection locks, a clear sign the goal was to make recovery as hard as possible, not just to cause damage. Resource locks and account-level deletion protection blocked a number of the delete attempts, which is the clearest evidence in the whole timeline that layered safeguards still work even after an identity is fully compromised.

About 28 minutes after the destruction ended, the same identity returned and issued more than 30 successful key-retrieval requests against the storage accounts that survived — several with Terraform- and backup-themed names — handing the attacker a path to ongoing access even after the deletion spree. Telemetry showed five distinct tokens tied to the service principal behind the destruction and key collection, with two deletion tokens active in the same 70-second window, a pattern that points to scripted, coordinated tooling rather than a manual operator working by hand.

No ransom note or confirmed data theft has been tied to the intrusion, but the combination of mass deletion, targeted access-key harvesting and attacks on backup and recovery controls points toward an extortion play: destroy first, then use the stolen keys as leverage or a re-entry path.

Why it matters

This incident is a reminder that in the cloud, the gap between "a secret leaked somewhere public" and "production data is gone" can be measured in hours, not weeks — and the destructive phase itself can be measured in minutes. It also shows that identity is the real perimeter: nothing about this attack required a vulnerability in Azure itself, just a valid, over-permissioned service principal that nobody rotated after it was exposed. The deliberate targeting of Site Recovery and Azure Backup shows attackers increasingly understand that wiping the primary environment isn't enough on its own — if the victim can just restore from backup, the backup becomes the next target.

What to do

  • Treat every exposed secret as compromised, immediately. Revoke and rotate any credential found in a public repository, ticket, log, or config file the moment it's discovered — removing the post doesn't erase it from history or from anyone who already copied it.
  • Apply least privilege to workload identities. Service principals used for automation should hold only the permissions their job actually requires — that's what limits how far a single leaked token can reach.
  • Lock down backup and recovery infrastructure separately. Restrict who can modify or remove resource locks, Site Recovery configurations and Backup protection, and alert on any attempt to change them.
  • Hunt for the pattern, not just the payload. Long, quiet discovery activity followed by a burst of rapid deletions and mass key retrieval is a recognizable signature — build detections around unusual enumeration volume, high-speed ListKeys bursts, and deletion attempts against protected resources.
  • Use resource locks and deletion protection everywhere they're supported. They won't stop a determined attacker with the right permissions, but this case shows they measurably reduce the blast radius even after full identity compromise.
SHARE