Hackers Use Compromised Service Principals to Delete Azure Storage and Steal Cloud Credentials
Microsoft links destructive Azure Storage deletions and storage key theft by Storm-3168 (JADEPUFFER) to compromised service principals with credentials leaked on GitHub.
Microsoft attributes an Azure destructive campaign to Storm-3168 (JADEPUFFER), first documented by Sysdig in July 2026 as an agentic ransomware operation. Compromised service principals, whose client ID, secret, and tenant ID were exposed in plaintext in a public GitHub issue, performed over 300 reconnaissance reads in roughly 15.5 hours and later attempted more than 100 Azure Storage deletions, removed a Key Vault, Function App, and App Service plan, and executed over 30 ListKeys operations to collect storage account keys. Azure resource locks and deletion protection blocked some destruction, while Azure SQL deletion attempts failed only due to an unsupported API version. Microsoft observed no ransom note or confirmed data theft, but the targeting of Site Recovery and Backup controls is consistent with ransomware and extortion objectives.
- Storm-3168 used two compromised service principals for recon, destruction, and key collection
- Credentials exposed in plaintext in a public GitHub issue's edit history
- Over 100 Azure Storage deletion attempts plus Key Vault and app component removal
- 30+ ListKeys operations collected storage keys, including Site Recovery keys
- No ransom note or confirmed exfiltration observed by Microsoft
Full article972 words · extracted from gbhackers.com · click to collapse
Microsoft has uncovered an Azure-focused destructive campaign linked to JADEPUFFER, a threat actor the company tracks as Storm-3168.
The group abused compromised service principals to map cloud resources, delete Azure Storage accounts and application components, attack recovery controls, and collect storage account access keys that could support later data theft.
The activity expands on research from Sysdig, which identified JADEPUFFER in July 2026 as the first documented agentic ransomware operation.
Microsoft identified two compromised service principals in the same Azure tenant. One identity carried out extensive reconnaissance, while the second was used for discovery, destructive actions, and credential collection.
In early June 2026, the first service principal performed more than 300 successful read operations over roughly 15 hours and 30 minutes.
It enumerated virtual machines, subscriptions, resource groups, and other Azure resources, providing the operators with a detailed view of the victim’s cloud estate.
Around 90 minutes later, the second service principal enumerated virtual machines and resource groups across two subscriptions in only five seconds.
Both identities used infrastructure associated with Storm-3168, shared the same network fingerprint, and submitted requests with the python-requests/2.34.2 user agent.
The destructive identity later queried Azure App Service configuration stores, likely searching for exposed secrets, and attempted to locate Azure OpenSearch resources.
Approximately 70 seconds after its final inventory action, it attempted a ListKey request against a nonexistent storage account then initiated its deletion sequence.
Less than one second after the failed key request, the compromised service principal began issuing destructive commands.
It generated more than 150 destructive or credential-collection-related operations in 35 minutes, including a concentrated seven-minute period of resource deletion.
The actor attempted more than 100 Azure Storage account deletions, successfully removing most of the targeted accounts.
Azure resource locks and storage-account deletion protection prevented deletion of several others, illustrating the value of recovery safeguards that remain enforced even when attackers compromise highly privileged identities.
Microsoft documents how Azure resource locks can prevent accidental or malicious removal of protected resources.
Storm-3168 also deleted an Azure Key Vault, Function App, and App Service plan associated with the same resource group.
In parallel, it tried to delete multiple Azure SQL databases. Those attempts failed because the threat actor used an unsupported API version for the Azure SQL Database resource type, rather than because the service principal lacked authorization.
The attackers also tried to remove Azure Site Recovery locks and Azure Backup protection locks.
Targeting storage, backup, and recovery controls is consistent with ransomware operators seeking to increase operational impact and reduce a victim’s ability to restore data.
About 30 minutes after its final destructive action, the same compromised identity made an Azure Storage inventory request and successfully executed more than 30 ListKeys operations.
These calls requested storage account access keys, including keys associated with Azure Site Recovery resources.
Azure Storage Deletion
Storage account keys can permit access to sensitive cloud data and services, making them valuable for potential exfiltration or follow-on intrusion.
Microsoft’s investigation provides the first detailed account, of the group’s Azure operations and shows how compromised workload identities can give attackers rapid, broad control over cloud environments.
Microsoft did not confirm successful data theft or observe a ransom note in the incident, but the combination of cloud resource deletion, recovery-system targeting, and credential collection is consistent with ransomware and extortion objectives.
Microsoft said the service principals operated within their existing role assignments. A group-assigned Storage Account Contributor role enabled storage deletion, while direct Contributor permissions allowed deletion of application resources and one successful key-retrieval action.
Direct SQL DB Contributor access authorized database deletion attempts, although the API error stopped those actions.
Microsoft could not conclusively establish the initial access vector. However, investigators found that a client ID, client secret, and tenant ID tied to one service principal had been published in plaintext in a public GitHub issue by an employee of the affected organization.
Although the issue was later edited to remove the secret, the credential remained visible in the public edit history. Microsoft stressed that deleting or redacting publicly exposed credentials does not invalidate them.
Secrets can persist in revision histories, logs, caches, archives, and cloned repositories; they must be revoked or rotated immediately.
The company also observed Storm-3168-linked infrastructure probing Azure App Services for WordPress administrative paths, PHP-CGI, LangFlow’s /api/v1/validate/code endpoint, and web-shell-like paths.
Those scans did not overlap with the impacted subscriptions, and Microsoft found no confirmed App Service-to-Azure Resource Manager credential path.
The campaign highlights how workload identities have become a high-value cloud attack surface.
Organizations should reduce service-principal permissions to the minimum required, continuously scan code and public repositories for secrets, rotate exposed credentials, and closely monitor unusual Azure Resource Manager activity.
Microsoft also recommends enabling relevant Defender for Cloud protections for Resource Manager, Storage, Key Vault, App Service, and database workloads.
Security teams should protect backup systems independently, enforce resource locks, and monitor attempts to weaken recovery protections.
As attackers increasingly automate cloud operations and use AI-assisted workflows to accelerate post-compromise activity, defenders will need automated investigation and response at comparable scale.
Microsoft pointed to Project Perception and Defender for AI Security as initiatives intended to help organizations detect, investigate, and contain threats across complex cloud environments.
Indicators of compromise
| Indicator | Type | Description |
| 45.131.66[.]106 | IPv4 | App Service probing and malicious ARM requests |
| 34.153.223[.]102 | IPv4 | App Service probing |
| 64.20.53[.]230 | IPv4 | 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.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC
Mayura Kathirhttps://gbhackers.com/
Mayura Kathir is a cybersecurity reporter at GBHackers News, covering daily incidents including data breaches, malware attacks, cybercrime, vulnerabilities, zero-day exploits, and more.