Threat intel

On September 25, Microsoft published an investigation into an attack on an Azure tenant in early June 2026. The actor, which Microsoft tracks as Storm-3168 and links to the JADEPUFFER operation, logged in with two stolen service principals, mapped the environment, and then spent about seven minutes trying to delete more than 100 storage accounts. Most of those deletions succeeded. A Key Vault, a Function App and an App Service plan went with them.

No exploit was involved. The first credential came from a public GitHub issue, and the roles the service principals already held were enough for everything that followed. If your automation signs in to Azure with a client secret and holds Contributor on a subscription, your tenant can be attacked the same way.

How the attack worked

A service principal is the identity an application or script uses to sign in to Microsoft Entra ID, the identity service behind Azure. It usually authenticates with three values: a tenant ID, a client (application) ID and a client secret. Anyone holding those three can get tokens for Azure Resource Manager (ARM), the API that creates and deletes every Azure resource, with the identity's roles. Multifactor authentication does not apply to workload identities, so the secret alone is enough.

An employee of the victim organisation had pasted the client ID, client secret and tenant ID in plaintext into a public GitHub issue. The issue was later edited to remove the secret, but GitHub keeps the edit history of issues and comments, and the old revision stayed public for anyone who clicked on it.

The second identity held Storage Account Contributor through a group, plus direct Contributor and SQL DB Contributor assignments. Microsoft notes that no privilege escalation was needed. Contributor can delete almost any resource in its scope and can call the ListKeys operation, which returns a storage account's access keys. Those keys give full data access to the account without any further sign-in.

What the attackers did

The first service principal spent about 15 hours and 30 minutes enumerating virtual machines, subscriptions, resource groups and resources, with more than 300 successful read operations. About 90 minutes after that started, the second identity listed resources across two subscriptions in five seconds. Around the 16-hour mark, it probed App Service configuration, where connection strings and app secrets tend to sit.

The deletion burst followed. Microsoft counted five tokens issued for the second service principal: four used for deletion and one for storage inventory and key retrieval. Two deletion tokens were active in the same 70-second window, one working on storage accounts and the other on a mix of storage and SQL. Microsoft reads that timing, and the split of work across identities sharing one network fingerprint and the user agent python-requests/2.34.2, as a strong sign of automated, agent-driven execution. That fits JADEPUFFER, which Sysdig documented on July 1, 2026 as the first ransomware operation run end to end by a large language model, after it broke in through the Langflow flaw CVE-2025-3248.

Not everything went. The SQL deletions failed only because the tool called an unsupported API version, which is luck. The locks that saved some storage accounts and the Site Recovery and Backup protection are controls the victim had set up in advance.

About 30 minutes after the deletions stopped, the same identity made more than 30 successful ListKeys requests, including against storage accounts used by Azure Site Recovery. A similarly named storage account in the same resource group as the deleted Key Vault and Function App had been skipped during the wipe, and its keys were taken in this phase. Microsoft saw no ransom note and did not confirm data theft, though attacking recovery infrastructure is the usual groundwork for a ransom demand.

Microsoft published three IP addresses: 45.131.66[.]106, 34.153.223[.]102 and 64.20.53[.]230.

What to do

1. Find leaked secrets and rotate them. Treat any secret that was ever public as compromised, even if it was removed minutes later. GitHub secret scanning is on by default for public repositories and checks issue titles, descriptions and comments, including past revisions. After you rotate the secret, delete the old revision too: open the issue, click "edited", pick the revision, then Options and "Delete revision from history". List each app's credentials with az ad app credential list --id <appId> and remove any you cannot account for.

2. Move automation off client secrets. Use managed identities for workloads running in Azure and workload identity federation for GitHub Actions and other CI systems. Neither leaves a long-lived secret that someone can paste into an issue.

3. Cut service principal roles down to size. Run az role assignment list --assignee <appId> --all -o table for each automation identity. A deployment pipeline rarely needs Contributor on a whole subscription, and very few need ListKeys. Where an app only reads blobs, give it Storage Blob Data Reader on one account and turn off shared key access on that account.

4. Put CanNotDelete locks on what you cannot lose. Recovery Services vaults, Site Recovery storage, Key Vaults and production storage accounts are the obvious candidates: az lock create --name no-delete --lock-type CanNotDelete --resource-group <rg>. Deleting a lock needs Microsoft.Authorization/locks/delete. Among built-in roles only Owner and User Access Administrator have it, while Contributor's role definition excludes Microsoft.Authorization/*/Delete. Microsoft did not say why the locks held here, but that exclusion is the likely reason. Never give automation Owner.

5. Turn on purge protection for Key Vaults. Soft delete has been mandatory on every vault since February 2025, with 7 to 90 days of retention. Purge protection is still optional, and without it an attacker with enough rights can purge a soft-deleted vault for good. Run az keyvault update --name <vault> --enable-purge-protection true; it cannot be switched off afterwards. A deleted vault comes back with az keyvault recover --name <vault>. Deleted storage accounts can be restored from the portal within 14 days, as long as nobody has created a new account with the same name, but Microsoft calls that best effort.

Check whether it already happened

The Activity Log keeps 90 days by default; send it to Log Analytics to keep more and to query it. This looks for bursts of successful deletions by one caller:

AzureActivity
| where TimeGenerated > ago(90d)
| where OperationNameValue endswith "/DELETE" and ActivityStatusValue in~ ("Success", "Succeeded")
| summarize deletes = count(), types = make_set(ResourceProviderValue) by Caller, bin(TimeGenerated, 10m)
| where deletes > 10

Run the same query with OperationNameValue =~ "microsoft.storage/storageaccounts/listkeys/action" and count distinct _ResourceId per Caller. One identity pulling keys for dozens of accounts in an hour needs an explanation. Failed attempts on microsoft.authorization/locks/delete are just as telling. For service principal sign-ins from the published IPs, search AADServicePrincipalSignInLogs on IPAddress.

Where this leaves cloud teams

An alert that pages someone during a seven-minute deletion burst arrives after the damage. The 15 hours of reconnaissance before it are where a defender can realistically step in: one service principal making hundreds of reads across subscriptions it never normally touches, from a new IP address. Locks and purge protection cover the minutes after that without anyone awake.

We review Entra ID workload identities, role assignments and locks in our cloud and Kubernetes security work, and alert on deletion bursts and key listing in security operations. If you want to know what your automation identities could delete today, open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Microsoft Security Blog, BleepingComputer, The Hacker News, The Register, Security Affairs, Sysdig on JADEPUFFER, Microsoft Learn: resource locks, Microsoft Learn: Key Vault soft delete, Microsoft Learn: recover a deleted storage account, GitHub changelog: secret scanning in issues, GitHub Docs: comment edit history.