al-ice.ai

Seven Minutes, 100+ Storage Accounts: JADEPUFFER Goes Agentic Inside Azure

Agent & Supply Chain Security by al-ice.ai Editorial

On 25 September 2026 Microsoft Security Research published the first detailed view of what JADEPUFFER — the agentic ransomware operation Sysdig documented in July — does once it gets inside an Azure tenant. Tracked by Microsoft as Storm-3168, the actor ran an AI-orchestrated campaign of reconnaissance, bulk resource destruction, and credential collection using two compromised service principals in the same tenant. The destructive sequence lasted about seven minutes and included more than 100 storage-account deletion attempts — most of which succeeded.

Microsoft's assessment is careful: the operation looks ransomware-aligned, but no ransom note was observed and no successful data exfiltration was confirmed. What was confirmed is the shape of the new normal — post-compromise cloud operations coordinated at machine speed, where the defensive window opens long before the destruction starts.

Reconnaissance at two speeds

The campaign split its labor across two identities with the same network fingerprint and the user agent python-requests/2.34.2. In early June 2026, the first service principal spent about 15 hours and 30 minutes enumerating virtual machines, subscriptions, resource groups, and resources — 300+ successful read operations giving the actor visibility across the tenant. About 90 minutes into that slow enumeration, the second service principal enumerated virtual machines and resource groups across two subscriptions in five seconds.

Sixteen hours later the second identity came back for credentials-relevant inventory: it enumerated Azure App Service configuration stores — plausibly hunting exposed secrets — and probed for Azure OpenSearch resources unsuccessfully. Seventy seconds after that final inventory step it tried a ListKey against a non-existent storage account. Less than one second later, the destruction began.

The seven-minute sequence — and what stopped parts of it

The compromised identity attempted 150+ destructive or credential-collection operations in 35 minutes, with the destructive core compressed into roughly seven minutes:

  • 100+ storage-account deletion attempts; most succeeded. What saved the remainder was not identity controls — the identity had broad administrative permissions — but Azure resource locks and storage-level deletion protection, which Microsoft explicitly calls out as independent safeguards that held anyway.
  • A Key Vault, a Function App, and an App Service plan were deleted — all in one resource group, apparently supporting the same application. A similarly named storage account in that group was spared, then later hit with a successful ListKeys call.
  • Every Azure SQL database deletion failed — not because of a defense, but because the actor used an unsupported API version for the SQL resource type. Automation fails too; the defenders just cannot count on it.
  • Azure Site Recovery locks and an Azure Backup protection lock were targeted for deletion and survived. The actor also favored storage accounts with terraform- and backup-themed names — recovery impairment was part of the plan, not collateral.
  • About 30 minutes after the destruction, the same identity came back for keys: a fresh storage inventory plus 30+ successful ListKeys requests, including against Site Recovery–related storage — credentials that could open data access after the fires went out.

The operation ran on five unique tokens: four handled deletion, one handled inventory and key retrieval, with two deletion tokens active in the same 70-second window — one focused on storage, the other mixing storage and SQL. Everything followed the identity's existing role assignments: a group-granted Storage Account Contributor role, direct Contributor access, and direct SQL DB Contributor access. No privilege escalation was needed. The permissions were already there.

How the keys leaked: a GitHub issue's edit history

On initial access, Microsoft is blunt about the likeliest story even though it could not confirm the vector: the service principal's client ID, client secret, and tenant ID had been posted in plaintext in a public GitHub issue by an employee of the victim organization. The issue was later edited to remove the secret — but the secret stayed visible in the issue's public edit history. Redaction is not rotation: exposed credentials remain usable until revoked, and copies live on in caches, archives, and logs.

Separately, Microsoft reports Storm-3168-linked infrastructure has been probing Azure App Services since the start of the year — WordPress admin paths, PHP-CGI endpoints, LangFlow's /api/v1/validate/code endpoint, and other web-shell-like paths — across multiple customers. Those targets did not overlap the victim's subscriptions, and Microsoft found no App-Service-to-ARM credential path for this tenant. The LangFlow probe is a familiar face in this site's coverage: LangFlow endpoints keep appearing in both exploitation and KEV entries, most recently the origin-validation flaw CISA confirmed under active exploitation.

Why this matters for agent deployments

Three lessons land directly on teams running agents against cloud infrastructure. First, workload identities are the perimeter now. Service principals with standing Contributor rights are better targets than any model endpoint: they do not get phished, they get scraped from issues, configs, and chat logs — and they work until rotated. Second, destruction is the exfiltration shortcut. Deleting storage, Key Vaults, and the backup locks that would undo the deletion is faster than staging data out, and agentic tooling compresses it into minutes. Third, the controls that held were the ones outside the identity plane — resource locks, deletion protection, backup isolation. When the identity is compromised, only safeguards the identity cannot reach still count.

Microsoft maps the activity to ATT&CK T1190 (exploit public-facing application), T1078.004 (valid cloud accounts), T1526 (cloud service discovery), T1485 (data destruction), and T1490 (inhibit system recovery), and published three IOC addresses (45.131.66[.]106, 34.153.223[.]102, 64.20.53[.]230) tied to App Service probing and malicious ARM requests.

What to do

  • Treat every publicly exposed secret as compromised — including edited-away ones. Search GitHub issues, PRs, wikis, and edit histories for client secrets, storage keys, and connection strings; revoke and rotate, then investigate historical use. Deleting the disclosure fixes nothing.
  • Put resource locks and deletion protection on storage, Key Vaults, and backup resources now. In this campaign they were the only things that survived contact with a fully permissioned identity. Restrict who can remove the locks, and alert on attempts.
  • Strip standing privilege from service principals. Review Azure RBAC on every workload identity, keep Storage Account Contributor and Contributor grants scoped to the resources the application actually needs, and prefer short-lived credentials over long-lived secrets.
  • Isolate and monitor backup and recovery infrastructure as ransomware targets. Site Recovery locks and Backup protection locks were explicitly in the blast radius here; their modification attempts deserve their own alerts.
  • Hunt the precursors, not just the deletions. Slow, broad enumeration (hundreds of reads over hours) followed by a seconds-fast second pass, App Service configuration-store reads, and ListKeys bursts are the detectable shape of this operation — enable Defender for Cloud workload protections (Resource Manager, Storage, Key Vault, Databases) to catch it.

Sources: