Microsoft Azure

Storm-3168 (JADEPUFFER): compromised Azure service principals enumerate a tenant for hours, then an automated burst destroys storage, Key Vault and app resources in about seven minutes

Microsoft Security Research has identified Azure resource-destruction activity it associates with JADEPUFFER, the threat actor Sysdig disclosed in July 2026 as the first documented agentic-ransomware operation, giving the first detailed view into the actor's cloud-native operations under Microsoft's own tracking designation Storm-3168 (Microsoft Security Blog, 2026-09-25). Two compromised service principals belonging to one tenant divided the work: the first spent roughly 15.5 hours running 300+ read-only enumeration calls across virtual machines, subscriptions and resource groups; the second, activated 90 minutes later, ran rapid parallel enumeration across two subscriptions in five seconds, then 16 hours later probed Azure App Service configuration stores and Azure OpenSearch resources, apparently hunting for exposed credentials. Within one second of a failed key-retrieval attempt against a non-existent storage account, the same service principal began a roughly seven-minute destructive sequence: 100+ storage-account deletion attempts, mostly successful, though Azure resource locks and storage-account-level deletion protection blocked deletion for a subset, plus deletion of a Key Vault, Function App and App Service plan belonging to the same resource group. Parallel attempts to delete Azure SQL databases failed only because the actor used an unsupported API version for that resource type. The actor also made repeated, unsuccessful attempts against Azure Site Recovery locks and Azure Backup protection locks, which Microsoft assesses as potentially intending to impair recovery, before pivoting roughly 30 minutes later to 30+ successful Storage-Account ListKeys credential-collection calls, including against Site-Recovery-related accounts, for possible future exfiltration.

Timing evidence drives Microsoft's automation assessment: five distinct OAuth tokens were issued for the destructive and collection work, with two active during the same 70-second window performing different resource-type deletions in parallel: "the timing between the different operations and the division of work using multiple service principals and overlapping token streams from the same service principal strongly indicates automated or scripted execution" (Microsoft Security Blog, 2026-09-25). No ransom note or confirmed data exfiltration was observed in this specific activity, but Microsoft assesses the destruction, recovery-mechanism targeting and credential harvesting together as consistent with a ransomware/extortion-aligned objective. Microsoft separately notes ongoing probing from Storm-3168-linked infrastructure since the start of the year against multiple Azure App Service customers, targeting WordPress-administration, PHP-CGI and LangFlow code-validation endpoints, but found no App-Service-to-ARM credential path connecting that probing to the tenant affected in this campaign.

Initial access to the compromised service principal is not confirmed: it is "unclear how the service principal was initially compromised," but its client ID, client secret and tenant ID had previously been posted in plaintext in a public GitHub issue by an employee of the affected organization. The issue was later edited to remove the visible secret, but the value remained retrievable through the issue's public edit history; Microsoft states plainly that "removing or redacting an exposed secret does not invalidate it," while also stating it "could not confirm whether this secret was used for the activity described here" (Microsoft Security Blog, 2026-09-25).

Detection and hunting. In Azure Resource Manager audit-log telemetry, the signal is volume and sequencing rather than any single call: dozens to hundreds of deletion or ListKeys operations against storage accounts, Key Vaults and Function Apps within minutes, especially when preceded by hours of broad read-only enumeration from the same or a paired service principal, and when it includes attempts against Site Recovery or Backup protection locks specifically, a combination with essentially no legitimate operational counterpart. The python-requests user agent Microsoft observed on both compromised principals (Microsoft Security Blog, 2026-09-25) is a further, if weak, signal worth correlating with the rest of the sequence rather than alerting on alone.

Triage: legitimate infrastructure-as-code teardown and disaster-recovery testing can also delete storage accounts and Key Vaults in bulk, so the discriminators are the attempt against recovery-protection locks specifically (a step with no purpose in routine teardown), the credential-harvesting ListKeys sweep that follows the destructive burst rather than preceding it, and multiple overlapping OAuth tokens performing different destructive operations in parallel from principals with no prior operational history of this pattern.