JadePuffer Azure Attack: Storm-3168 Hits Service Principals

Microsoft has linked new Azure destruction activity to JadePuffer. Sysdig first documented JadePuffer in July 2026 as an agent-driven ransomware operator. In the JadePuffer Azure attack, Microsoft observed two compromised service principals inside one tenant. The identities carried out reconnaissance, deleted cloud resources, and collected storage account keys. Microsoft tracks this activity as Storm-3168.

Service principals are machine identities. They hold Azure permissions without a human login to flag. Once an attacker controls one, it can enumerate resources, delete infrastructure, and pull credentials at machine speed. Microsoft’s findings describe a seven-minute destructive sequence. The sequence hit more than 100 storage accounts, plus Key Vaults, Function Apps, and an App Service plan.

This is not an isolated incident. JadePuffer already automated a ransomware attack against a production database server in July. Storm-3168’s Azure activity shows the same automation now targeting cloud identity and infrastructure.

How two service principals split the work

Microsoft found that both compromised service principals belonged to the same Azure tenant, and each carried a distinct job.

• The first service principal enumerated virtual machines, subscriptions, resource groups, and resources for roughly 15 hours and 30 minutes. It completed over 300 successful read operations, giving the attacker broad visibility into the environment.
• The second service principal started about 90 minutes later. It enumerated virtual machines and resource groups across two subscriptions in just five seconds.

Both identities used Storm-3168 linked infrastructure, the same network fingerprint, and the identical user agent string python-requests/2.34.2. That overlap points to scripted, coordinated execution rather than manual operator activity.

Sixteen hours after that enumeration, the second service principal probed Azure App Service configuration stores, likely searching for exposed credentials. It also tried and failed to locate Azure OpenSearch resources. Seventy seconds later, it attempted a ListKey operation against a storage account that did not exist. Destructive activity began less than one second after that failed call.

A seven-minute destructive sequence

The second service principal attempted more than 150 destructive or credential-related operations over 35 minutes. The core wipe itself took about seven minutes.

• It attempted 100+ storage account deletions. Most succeeded, but Azure resource locks and storage account-level deletion protection blocked a smaller number.
• It deleted a Key Vault, a Function App, and an App Service plan, all in the same resource group.
• It attempted to delete multiple Azure SQL databases in parallel with the storage deletions. Every attempt failed because the request used an unsupported API version for that resource type.
• It attempted to delete Azure Site Recovery locks and an Azure Backup protection lock. These attempts also failed.

Roughly 30 minutes after the destructive activity ended, the same service principal returned. It requested an inventory of storage accounts, then sent more than 30 successful ListKeys requests. Some of the targeted accounts were tied to Azure Site Recovery.

Microsoft’s analysis found that the attacker’s actions matched the service principal’s existing Azure RBAC assignments. A group-granted Storage Account Contributor role authorized the storage deletions. Direct Contributor access authorized the Key Vault, Function App, and App Service plan deletions. Direct SQL DB Contributor access authorized the SQL deletion attempts, which failed for the technical reason above rather than a permissions gap.

Why this looks like ransomware, not just a wiper

Microsoft assessed that the combination of destruction, recovery-lock targeting, and credential collection is consistent with tactics that support ransomware and extortion. Several details point in that direction:

• The attacker targeted storage accounts and Azure Storage assets with Terraform- and backup-themed names, suggesting an attempt to weaken recovery options.
• The attacker also targeted Azure SQL databases in parallel with storage deletions, broadening the destructive scope across data services rather than focusing on one type.
• The attacker collected storage account keys after the wipe, which could support data access or exfiltration in a later stage.

Public reporting does not confirm a ransom demand in this campaign. Microsoft also did not confirm data exfiltration in the activity it observed.

A leaked secret and an unresolved entry point

Microsoft could not determine exactly how the service principal was first compromised. Here is what investigators did find:

• The client ID, client secret, and tenant ID for one service principal appeared in plaintext in a public GitHub issue posted by an employee of the affected organization.
• Someone later edited the issue to remove the secret, but the credential remained visible through the issue’s public edit history.
• Microsoft could not confirm whether this specific secret enabled the observed activity.

Separately, Microsoft has tracked Storm-3168-linked infrastructure probing Azure App Service instances across multiple customers since the start of the year. That probing targeted paths associated with WordPress administration, PHP-CGI, and LangFlow’s code validation endpoint.

Microsoft found no overlap between those probed App Service targets and the affected subscriptions here, and no credential path from App Service to Azure Resource Manager for this tenant. The two activities appear related to the same actor’s broader operations, but the App Service probing is not confirmed as the entry point for this specific attack.

Featured resource

Building a cybersecurity framework for your enterprise

Explore major cybersecurity frameworks and how UEM strengthens compliance, visibility, and endpoint protection across organizations.

DOWNLOAD

Reducing the human side of machine-identity risk

The exposed credential in this case did not leak from Azure itself. It leaked from a developer’s GitHub activity, which puts part of the exposure squarely on endpoint and workflow hygiene. Hexnode UEM and Hexnode XDR can support that layer without touching Azure’s own control plane.

Hexnode UEM

• Enforces configuration management and application allowlisting/blocklisting across developer and admin workstations, with OS patch management for Windows, macOS, and Linux, and automated third-party app patching for Windows endpoints.
• Reports device compliance to Microsoft Entra ID for Android, iOS, and macOS devices, so device-aware access policies can block non-compliant devices from reaching sensitive resources.

Hexnode XDR

• Investigates suspicious activity on managed Windows and macOS endpoints, helping flag unusual local behavior around credential files, Git tooling, or configuration stores before a secret reaches a public repository.
• Lets admins kill a harmful process, quarantine flagged files, or isolate a suspicious endpoint, containing local risk while an investigation is underway.

None of this reaches into Azure Resource Manager, service principals, or storage accounts. Hexnode does not detect JadePuffer, patch Azure services, or monitor cloud-side API activity. It complements the credential rotation, RBAC review, and Defender for Cloud protections that Azure teams must still manage directly.

Conclusion

JadePuffer’s Azure activity shows ransomware tradecraft moving into cloud identity. Compromised service principals let an automated operator discover resources, delete infrastructure, and harvest credentials without a human account in sight.

Enterprises should treat workload identities as an attack surface, not background plumbing. Rotate exposed secrets immediately, apply least privilege to service principals, and monitor destructive cloud operations with the same urgency given to endpoint ransomware.