Storm-3168 Deletes Azure Storage Accounts With Stolen Service Principals
Two compromised service principals drove a rapid Azure deletion campaign. Trace their ARM operations, rotate exposed secrets and verify recovery-resource locks.
A compromised Azure service principal deleted most of the storage accounts it targeted in a seven-minute burst in early June. A second compromised principal mapped the same tenant first. Microsoft Security Research’s September 25 account names the actor Storm-3168, also known as JADEPUFFER. The immediate question for an Azure operator is which workload identities can delete storage and recovery resources, and whether those identities’ credentials have escaped.
The destructive principal also made more than 30 successful ListKeys requests after the deletions. Some accounts tied to recovery were among them. Storage-account locks blocked a few deletion attempts. A deletion lock still permits ListKeys, so the later key requests need their own investigation: the identity retained a route to data through account keys.
Two principals split the work
The first principal made more than 300 successful read operations over about 15 hours and 30 minutes, enumerating virtual machines, subscriptions, resource groups and resources. Roughly 90 minutes after it began, the second principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both used Storm-3168-linked infrastructure, the same network fingerprint and the user agent python-requests/2.34.2.
Sixteen hours later, the second principal read App Service configuration stores. A failed ListKey request against a nonexistent storage account immediately preceded the destructive run. Microsoft observed five tokens issued for this principal: four supported deletion, and the fifth handled storage inventory and key retrieval. Two deletion tokens overlapped for 70 seconds, one focused on storage and the other on storage and SQL. The timing and division of work point to scripted coordination across valid cloud identities.
The permissions explain the reach. A group-granted Storage Account Contributor role allowed storage-account deletion; a direct Contributor assignment covered the Key Vault, Function App and App Service plan that were deleted together. Direct SQL DB Contributor permission allowed attempts against SQL databases. Those SQL requests failed because they used an unsupported API version. A compromised workload identity can carry the same operational reach as its application role assignments.
Seven minutes erased storage accounts
The principal attempted more than 100 storage-account deletions during the seven-minute sequence. Most targeted accounts were deleted. Resource locks and storage-account deletion protection stopped attempts against a few others. An Azure Key Vault, Function App and App Service plan in one resource group were deleted as well. Attempts to delete Azure Site Recovery and Azure Backup protection locks failed.
About 30 minutes after the last destructive action, the same principal inventoried storage accounts and made more than 30 successful ListKeys requests. Microsoft says these included accounts related to Azure Site Recovery. The actor also tried to remove databases and recovery protections, behavior consistent with a ransomware-aligned objective. Microsoft observed no ransom note or confirmed data exfiltration. Investigate subsequent use of retrieved keys as potential data access.
Figure details
A service principal with group and direct Azure RBAC grants has two outgoing paths. The upper arrow points to account deletion: locks blocked some attempts. The lower arrow points to ListKeys requests: more than 30 succeeded. Use principal and account IDs to relate each request to the affected resources; assess retrieved keys separately from resource deletion.
A client ID, client secret and tenant ID for a service principal had appeared in a public GitHub issue. The issue was edited, but its edit history retained the secret. Microsoft could not confirm whether that secret was used to enter the tenant. As Microsoft puts it: “Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure.” Revoke the exposed credential and trace the principal’s sign-ins and operations to investigate initial access.
Read the operation trail first
Start with Azure Resource Manager activity for the affected tenant: group the resource reads, storage deletions, SQL delete attempts, lock delete attempts and ListKeys calls by service principal, subscription and time. Correlate one principal’s enumeration with the second principal’s five-second inventory and seven-minute deletion burst to identify the coordinated sequence. Preserve the operation results, principal IDs, role assignments and token/sign-in history for response.
Microsoft lists 45.131.66[.]106 for App Service probing and malicious ARM requests; 34.153.223[.]102 and 64.20.53[.]230 are App Service probing indicators. Search for those addresses in the corresponding telemetry, then relate any hit to the principal and operations. Microsoft observed probing against other customers’ App Services, including /api/v1/validate/code; those targets were separate from the compromised Azure subscriptions. For a probe hit, identify the targeted App Service and check that tenant’s ARM operations for any subsequent deletion activity.
Defender for Resource Manager’s suspicious-proxy ARM operation alert and the relevant Defender for Storage, Key Vault, App Service and Databases protections can support this hunt. Microsoft recommends its own Defender products. With any monitoring stack, verify the principal, its role assignments and the ARM operation results.
Revoke secrets and protect recovery
Revoke or rotate exposed service-principal credentials now, including secrets removed from public pages after disclosure. Review group-granted Storage Account Contributor and direct Contributor or SQL DB Contributor assignments for workload identities, and narrow them to resources the application actually needs. Give backup and recovery resources separate privileges and deletion safeguards so an application identity with stolen credentials lacks permission to remove its recovery path.
Microsoft’s resource-lock documentation explains why CanNotDelete helped in this case: a lock restricts control-plane deletions across role assignments. In Azure’s Locks view or with az lock list --resource-group <resource-group>, verify the intended storage and recovery scope inherits the lock. Check who holds Microsoft.Authorization/locks/* permission, because that access can remove management locks. Test a planned management-plane deletion in a safe, disposable locked resource group and expect Azure to reject it.
Pair the deletion lock with data-plane protection: Microsoft’s documentation says blobs, queues, tables and files can still be changed or deleted through data-plane operations. CanNotDelete permits other resource modifications and key listing. For each successful ListKeys request, review subsequent data-plane access and plan rotation of the retrieved account keys with dependent application owners. Consider ReadOnly only where its blocked management operations, including key listing and some routine application operations, fit the workload. Confirm the secret is invalid, the service principal’s roles are reduced, and the recovery resource rejects the deletion path that worked for Storm-3168.