Storm-3168: Hijacked Service Principals Hit Azure Storage

On 25 September 2026 Microsoft published an account of an Azure intrusion from early June. The actor, Storm-3168, used two compromised service principals to attempt more than 100 storage account deletions, and most succeeded. Microsoft notes that an employee had earlier posted one principal's client ID, client secret and tenant ID in plaintext in a public GitHub issue, but says it could not confirm that secret was used.

The useful part isn't the actor's name. It's what a service principal with a live secret can do in under an hour, and which of your resources would still be standing afterwards.

What happened

Storm-3168 is Microsoft's name for the actor Sysdig calls JADEPUFFER. Sysdig documented it in July 2026 and assessed it as the first ransomware operation driven end to end by an LLM agent. That was a different victim (a Langflow flaw, CVE-2025-3248). Microsoft attributes the Azure activity to the same actor.

Access: two service principals in one tenant. How they were compromised is unclear. The GitHub issue was later edited to remove the secret, but it stayed readable in the public edit history.
Timing: about 18 hours total. Roughly 15.5 were quiet discovery (300+ successful reads), then a destructive burst of about 7 minutes.
Keys: 30+ successful ListKeys requests against storage accounts, including ones tied to Azure Site Recovery.
Damage: 100+ storage account deletion attempts, most successful. One Key Vault, one Function App and one App Service plan were deleted.

No ransom note and no confirmed data exfiltration were seen. Call it destructive activity consistent with ransomware preparation, not a finished ransomware attack.

What held, and what was luck

What worked: Azure resource locks and storage account deletion protection blocked deletion of a few storage accounts. Attempts against Site Recovery and Backup protection locks also failed.

What was luck: Azure SQL deletions failed because of an unsupported API version. That isn't a defense. Don't list it as a mitigation.

The pattern matches Why Ransomware Waits for Friday Night: long quiet reading, then a very short destructive window. Alerting has to work on the first phase. For the wider problem of ownerless non-human accounts, see AI Agent Identities.

Checklist

Search public repos, issues and their history for secrets. Assume anything ever public is burned, and rotate it. A deleted post is not a rotated secret.
Cut service principal roles down. List principals with Owner, Contributor or User Access Administrator at subscription scope and scope them to what they touch.
Put CanNotDelete locks on what you can't rebuild: production storage accounts, Key Vaults, Recovery Services vaults. Anyone with Microsoft.Authorization/* or Microsoft.Authorization/locks/* (Owner, User Access Administrator) can remove them, so limit who holds those.
Turn on blob and container soft delete, versioning and Key Vault purge protection. Key Vault soft delete is already on by default. None of these bring back a deleted storage account. Azure may restore one within 14 days, best effort only, so don't plan on it.
Disable shared key access where you can, so keys returned by ListKeys can't read data. That holds only while the attacker can't turn shared key back on, which any role with storageAccounts/write (Contributor, Owner) can do. Otherwise rotate keys on a schedule.
Alert on bursts of storageAccounts/delete or listKeys/action events from one principal in a few minutes.

What a SecValley scan covers, and where it stops

We scan Azure read-only, so this is about blast radius and recovery posture. It would not have seen the GitHub issue, and we don't claim it would have prevented or detected this intrusion.

Recovery: Container Soft Delete (STR-018), Blob Versioning (STR-019), Key Vault Recoverable (KV-005).
Keys: Access Keys Periodically Regenerated (STR-004), Key Rotation Reminders (STR-003), Storage Account Key Access Disabled (STR-024).
Service principals: No Expired SP Credentials (SP-002) flags expired secrets only, not a leaked live one. Credential Expiry Appropriate (AP-004) flags credentials that expire more than a year out.
Locks: Resource Locks on Critical Resources (MISC-001) lists storage accounts, Key Vaults and Recovery Services vaults that have no CanNotDelete or ReadOnly lock, at resource, resource group or subscription scope. It warns, it doesn't fail. IAM-017 checks that a custom lock-administrator role exists, but no control checks who holds it.
Privileged roles: Between 2 and 3 Subscription Owners (IAM-022) fails above three Owners, service principals included. User Access Administrator at root scope fails IAM-021. No control yet flags a service principal holding Contributor.

See SecValley Security Posture to run a read-only scan.

Frequently Asked Questions

Was this a ransomware attack?

Not a completed one. Microsoft and The Register report no ransom note and no confirmed exfiltration.

Do resource locks stop this?

They stopped a few deletions here. They are one layer: limit who can remove locks and scope service principal roles down.

Does soft delete protect a deleted storage account?

No. It covers containers and blobs. Azure may restore a deleted account within 14 days, best effort only. A CanNotDelete lock protects the account itself.