"The entire attack took about 18 hours, with the discovery piece lasting about 15 hours and 30 minutes." That timeline, reported by Microsoft researchers Yossi Weizman and Tushar Mudi, frames a concentrated cloud assault in early June that combined reconnaissance, credential harvesting and rapid resource destruction inside a single Azure tenant.
Storm-3168 and the JadePuffer link
Microsoft says the actor it tracks as Storm-3168 — the same criminal group linked to JadePuffer, the first documented agentic ransomware infection discovered in July — compromised two Azure service principals belonging to the same tenant and used them for separate roles: one for reconnaissance and resource discovery, the other for destructive operations and credential collection. The connection follows Sysdig threat hunters’ earlier reporting on JadePuffer, an LLM-driven extortion operation described in July.
Reconnaissance: more than 300 successful reads and rapid cross-subscription queries
Over roughly 15½ hours, the reconnaissance service principal completed more than 300 successful read operations. The researchers wrote that these reads gathered detailed information about Azure Virtual Machines, subscriptions, resource groups, and resources — activity that “would give the threat actor visibility across the organization’s Azure environment.”
About 90 minutes after the first machine identity began gathering information, the second compromised service principal began querying resources too, reading Azure VMs and resource groups across two subscriptions in just five seconds. Both service principals used infrastructure Microsoft linked to Storm-3168, shared the same network fingerprint, and reported the user agent python-requests/2.34.2.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadDestructive sprint: storage accounts, key vaults, and attempts to cripple recovery
Sixteen hours after initial reads began, the destructive phase escalated. The second service principal discovered Azure App Service configuration stores — likely searching for exposed credentials — and then launched a tightly timed deletion campaign. Over a 35-minute window the attacker performed more than 150 destructive or credential-stealing attempts; the intense deletion activity itself lasted about seven minutes.
During that seven-minute span the machine identity attempted to delete more than 100 Azure Storage accounts. Most deletions succeeded, although some were blocked by Azure resource locks and storage account-level protections. The actor also deleted an Azure Key Vault, a Function App, and an App Service plan, all belonging to the same resource group and likely supporting the Function App.
Parallel deletion attempts targeted multiple Azure SQL databases but failed because the actor used an unsupported API version for the Azure SQL database resource type. The attacker also attempted a ListKey operation against a non-existent storage account and unsuccessfully searched for Azure OpenSearch resources.
Credential harvesting and targeting backup-related storage
About 28 minutes after the destructive activity concluded, the same service principal made inventory requests for Azure Storage Accounts and executed more than 30 successful ListKeys requests, asking ARM to return each storage account’s access keys. Microsoft noted these storage accounts included Azure Site Recovery-related accounts. Multiple unsuccessful deletion attempts were made against Azure Site Recovery locks and Azure Backup protection locks that were protecting storage accounts.
Microsoft characterized the combination of widespread deletion, targeting of backup and recovery mechanisms, and collection of credentials as consistent with tactics that “can support ransomware and extortion operations.” Yet researchers emphasized a key caveat: “We did not observe a ransom note or confirm successful data exfiltration in the activity described here.”
What this means for technologists and affected enterprises
- Technologists and security teams: this incident shows dual-use of service principals — one for broad environment visibility and another for short, destructive bursts — and flags toolchain identifiers (python-requests/2.34.2) and repeated probing as useful telemetry for detection, according to Microsoft’s account.
- Affected enterprises and recovery teams: attackers targeted backup- and recovery-related storage and attempted to remove protection locks; the activity underscores the value of resource locks, supported API versions, and monitoring of ListKeys and similar key-access operations that Microsoft observed following the deletions.
The record Microsoft researchers provide is specific and unsettling: a single tenant’s two compromised service principals gave an attacker hours of reconnaissance followed by minutes of destructive action that removed core resources and probed backups, yet left no publicly observed ransom demand and no confirmed exfiltration. The sequence — probing, rapid deletion, then key harvesting — maps to a ransomware posture, even as a full extortion campaign was not observed in this case.
Microsoft’s write-up, by Yossi Weizman and Tushar Mudi, adds one practical trace: an earlier employee mistake had exposed client IDs, client secrets and tenant IDs in plaintext in a public GitHub issue for the same organization — a detail Microsoft notes but did not connect definitively to the initial hijack of the service principals.
For now, the incident leaves a narrow set of certainties: Storm-3168 leveraged two hijacked service principals to achieve visibility and destruction inside Azure, deleted storage and other resources at scale in a matter of minutes, and harvested storage account keys that could facilitate later access — yet no ransom note or confirmed exfiltration was observed.
