In an incident observed in early June 2026, attackers used two compromised service principals application identities used to access cloud resources to map a victim’s environment, delete storage accounts and collect access keys. They also tried to remove protections tied to backup and recovery.
Sysdig first reported JADEPUFFER in July 2026, describing a separate database-extortion attack that it assessed as the first documented agentic ransomware operation.
Microsoft’s findings add the first detailed account of the actor’s Azure activity. However, Microsoft said the timing and parallel operations in this incident strongly indicate automation or scripting; its report does not establish that AI directed every Azure action.
Storm-3168 Targets Azure Cloud Assets
The first compromised service principal spent about 15 hours and 30 minutes discovering virtual machines, subscriptions, resource groups and other resources.
It completed more than 300 successful read operations. A second service principal also surveyed the environment before carrying out the destructive activity.
Both used Storm-3168-linked infrastructure, the same network fingerprint and the python-requests/2.34.2 user agent.
The second identity then attempted more than 150 destructive or credential-related operations over 35 minutes. The main deletion sequence lasted about seven minutes and included more than 100 attempts to delete Azure Storage accounts.
Most targeted accounts were deleted, but resource locks and storage account-level deletion protection stopped some attempts. The attacker also deleted a Key Vault, a Function App and an App Service plan in the same resource group.
Attempts to delete multiple Azure SQL databases failed because the attacker used an unsupported API version. Attempts to remove Azure Site Recovery and Azure Backup protection locks also failed.
About 30 minutes after the last destructive action, the same identity sent more than 30 successful ListKeys requests to retrieve storage account access keys, including keys for accounts associated with Azure Site Recovery. Microsoft did not confirm that data was stolen.
Microsoft could not establish how the service principals were compromised. It found that a client ID, client secret and tenant ID had previously appeared in a public GitHub issue posted by an employee of the affected organization.
The secret remained visible in the issue’s edit history after the post was changed, but Microsoft could not confirm that it was used in this attack.
The activity fits a ransomware-aligned objective widespread deletion, attempts to interfere with recovery and collection of keys that could allow access to surviving data. Still, Microsoft observed no ransom note and confirmed no successful exfiltration in this Azure incident.
Indicators of Compromise
| Indicator | Type | Reported activity |
|---|---|---|
45.131.66[.]106 | IPv4 | Azure App Service probing and malicious Azure Resource Manager requests |
34.153.223[.]102 | IPv4 | Azure App Service probing |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Join 16,000+ SOC teams using ANY.RUN to streamline threat investigations and reduce manual effort. Explore for your team
