Storm-3168 (JADEPUFFER): Azure Resources Mass-Deleted in Seven Minutes Using Compromised Service Principals

1. Overview

• Report Title: Storm-3168: Agentic-driven cloud attacks using compromised service principals
• Source: Microsoft Security Research
• Publication Date: September 25, 2026
• Original Report: Microsoft Security Research
• Related References: BleepingComputer, Dark Reading, Microsoft Learn: Azure Activity Log, Microsoft Learn: Azure resource locks, Microsoft Learn: workload identity CAE
• Related Malware, Threat Groups, CVEs, and Products: Storm-3168, JADEPUFFER, Microsoft Azure, Microsoft Entra ID, Azure Storage, Azure Key Vault, Azure SQL Database, Azure App Service

• Severity: Critical (Within a compromised Azure tenant, multiple storage account deletion attempts succeeded among over 100 attempts, along with the deletion of a Key Vault, a Function App, and an App Service plan. Attempts to disable recovery protections were also observed, confirming actual destructive impact.)

• Corrections: The timeline of concurrent enumeration and destruction, the denominator for ListKeys requests, the scope of Activity Log records, and the limitations of locks and token containment have been corrected. The confidence level of AI involvement and the observation scope of IP indicators were clarified.

2. Executive Summary

Microsoft observed parallel reconnaissance and destructive activity by two compromised service principals within a single victim tenant. The core destructive sequence took place over approximately seven minutes, followed roughly 30 minutes later by over 30 successful ListKeys requests. This count reflects successful requests rather than the total number of keys collected.

3. Attack Workflow

Enumeration, Destruction, and Key Acquisition by Compromised Service Principals

1. The attacker authenticated to the Azure Resource Manager (ARM) API using two compromised service principals. The exact initial vector used to obtain the credentials remains unconfirmed.
2. One service principal performed over 300 read and reconnaissance operations spanning approximately 15.5 hours. About 90 minutes after that activity began, the second service principal rapidly enumerated virtual machines and resource groups across two subscriptions in roughly five seconds (with both activities overlapping in time).
3. After an interval of approximately 16 hours following the initial enumeration, the second service principal conducted additional reconnaissance and abused existing Azure RBAC permissions to consecutively delete storage accounts, a Key Vault, a Function App, and an App Service plan. The core destructive sequence lasted about seven minutes, while the total destruction and credential-collection operations spanned roughly 35 minutes. Attempts to delete Site Recovery and backup protection locks were also made, but these failed.
4. Approximately 30 minutes after the destructive activity concluded, the same service principal re-enumerated the storage accounts and successfully issued over 30 ListKeys requests to gather access keys (representing successful requests rather than the total number of keys or accounts).

Compromised Service Principal	Primary Role and Activity	Execution Time and Interval	Target Resources and Results
Service Principal 1	Broad cloud resource reconnaissance (discovery)	Approx. 15.5 hours	Executed over 300 read operations (subscriptions, VMs, resource groups, etc.)
Service Principal 2 (Discovery)	Concentrated, rapid resource enumeration	Approx. 90 minutes after SP1 started; duration approx. 5 seconds	Rapidly enumerated VMs and resource groups across two subscriptions
Service Principal 2 (Destruction)	Bulk resource deletion and attempts to disable recovery protection	Approx. 16 hours after initial enumeration; destruction lasted ~7 min; total operation ~35 min	Most of over 100 storage deletion attempts succeeded. a Key Vault, a Function App, and an App Service plan deleted. SQL DB (API incompatibility) and protection lock deletions failed
Service Principal 2 (Credential Collection)	Collection of storage access keys	Approx. 30 minutes after the destruction sequence ended	Over 30 ListKeys requests succeeded (representing request count, not total keys). Successful data exfiltration unconfirmed

4. Attacker Infrastructure and Execution Location

• The attacker connected directly to the Azure Resource Manager (ARM) API from Storm-3168-related external infrastructure, utilizing access tokens from the compromised service principals.
• The target was internal to the victim organization's Azure tenant, and the accessible resource scope was limited by the Azure RBAC roles previously granted to each service principal.

5. Impact on Victims and Administrators

Victims

• The deletion of storage accounts and application runtime environments can lead to cloud service outages, loss of operational data, and unexpected termination of integrated applications.

Administrators

• The Azure Activity Log records events such as Microsoft.Storage/storageAccounts/delete, ListKeys operations, deletions of Key Vaults and Function Apps, and failed management lock deletion attempts densely within a short timeframe.

6. Conditions for Success and Failure

Prerequisites for Success

• Prior acquisition of service principal tokens or client secrets capable of authenticating to the Azure API.
• Assignment of Azure RBAC roles to the respective service principal that permit resource deletion, such as Storage Account Contributor or Contributor.
• Absence or insufficiency of independent protection features such as resource locks, soft delete, or immutable backups on the target resources.

Conditions for Failure and Risk Reduction

• Do not rely solely on repository deletion for exposed secrets; immediately revoke and rotate them within Entra ID. Treat commit histories, edit histories, web caches, and archives as potential exposure sources.
• Strictly limit service principal RBAC permissions to the minimum resources and actions required for operations, prioritizing Managed Identities and workload identity federation over long-lived static client secrets.
• Apply CanNotDelete resource locks to critical resources. However, because locks apply to control plane operations, they do not uniformly prevent file deletion or modification within the data plane of storage services. Combine data-level protections such as soft delete, versioning, and backups managed under a separate permission hierarchy.

7. Outcome Upon Success

• Most of the over 100 storage account deletion attempts succeeded, along with the deletion of a Key Vault, a Function App, and an App Service plan, causing severe damage to service availability and data integrity.
• Inference: Acquiring storage access keys (ListKeys) introduces the risk of subsequent access to remaining data and potential external exfiltration. However, no evidence confirming actual successful data exfiltration was observed.
• Inference: Successfully removing recovery protection locks could impede recovery from backups, but all lock deletion attempts observed in this incident failed.

8. Observable Logs

• Email: No evidence indicates that email was used as a primary initial access vector.
• Proxy / SWG / DNS: Because the threat actor connected directly from external infrastructure to the Azure management plane API, connections may bypass the victim organization's internal web proxy. IP address 45.131.66[.]106 was published as the source for malicious ARM requests and App Service discovery, while 34.153.223[.]102 and 64.20.53[.]230 were published as indicators of App Service discovery in other tenant environments.
• Endpoint / EDR: For cloud- and SaaS-centric incidents, do not rely solely on endpoint EDR conclusions; prioritize auditing management plane and application layer logs.
• Identity / IdP: Correlate service principal sign-in logs with management activity logs, analyzing source IPs, geographical locations, and requested permissions. Although Microsoft observed five access tokens, tenant-side standard logs alone may not fully reconstruct the usage of all tokens.
• SaaS / Cloud: Identify rapid bulk deletions, ListKeys execution, and failed lock deletions within the Azure Activity Log. Because standard read operations and resource enumeration are not recorded in the Activity Log by design, discovery activity cannot be determined solely from this log.
• Network: Check for access from unusual source IPs, concentrated and rapid bulk API operations, and communication history with known suspicious infrastructure.

9. Attack Success Assessment

• Malware Execution or Successful Authentication Confirmed: Public information confirms successful authentication to Azure ARM by two compromised service principals and the execution of numerous read operations (Target: One tenant environment observed by Microsoft).
• Subsequent Compromise Confirmed: Public information confirms that the majority of over 100 storage deletion attempts, the deletion of a Key Vault, a Function App, and an App Service plan, and more than 30 ListKeys requests succeeded (Target: Two subscriptions within the compromised tenant).

10. Investigation Playbook

• Investigation Triggers: Sudden bulk deletion events by service principals, concentrated execution of ListKeys, recovery protection lock removal attempts, and access from known IOCs serve as triggers.
• Initial Verification: Build a timeline of the execution identities (App ID/Object ID), access tokens, source IPs, assigned RBAC permissions, target resources, operation results, and the presence of resource locks.
• Endpoint and Server Investigation: Comprehensively search public repositories, GitHub issues, commit histories, edit histories, and CI/CD build logs to identify plain-text exposures of client IDs, client secrets, and tenant IDs.
• Authentication and Cloud Investigation: Immediately disable the affected service principals, revoke leaked client secrets, and audit role assignments and group memberships.
• Tracking Subsequent Activity: Trace the usage pattern of acquired storage keys, data access to Blob storage, external transfer records, and newly created credentials.
• Containment: Disable the compromised service principals, replace leaked secrets, and withdraw RBAC permissions. Do not assume that issued ARM access tokens become invalid immediately.; verify permission changes and access cessation via logs. Regenerate leaked storage keys after assessing the impact radius, and recover resources from independent protected backups.
• Determination Categories: Strictly distinguish and evaluate each phase: successful authentication, resource discovery, successful destructive operations, credential acquisition, data access, and external exfiltration.

11. Defense and Detection Ideas

• Single Events: Detect storage delete requests or ListKeys operations executed by service principals that do not normally perform resource deletions as high-priority alerts.
• Time-Series Correlation: Correlate available discovery traces, the ~7-minute bulk deletion sequence, and ListKeys operations occurring approximately 30 minutes after its conclusion. Note that an interval of about 16 hours existed between the initial 5-second discovery and the start of destruction.
• Threat Hunting: Comprehensively search all internal codebases and repositories for Azure credentials remaining in public GitHub issues or past edit histories.
• Log Limitations: Because the Activity Log alone cannot track data plane (e.g., Blob) access using acquired access keys, enabling continuous storage diagnostic logging (Storage logging) is essential.
• Prioritized Mitigations: Prioritize least-privilege enforcement for workload identities, regular secret rotation, application of deletion-prevention locks, deployment of immutable backups, and adoption of Defender for Resource Manager and Defender for Storage.

12. Facts, Inferences, and Hypotheses

Facts

• In early June 2026, Microsoft observed two compromised service principals belonging to the same tenant. One performed over 300 reads in approximately 15.5 hours, while the other executed rapid discovery, destruction, and credential collection.
• The service principal responsible for destruction attempted over 150 destructive or credential-collection operations within approximately 35 minutes, with its core destructive sequence lasting about 7 minutes. Microsoft reported more than 100 storage account deletion attempts. Most targeted storage accounts were successfully deleted.
• a Key Vault, a Function App, and an App Service plan were deleted. Azure SQL Database deletion failed due to an unsupported API version specification, and attempts to delete Site Recovery and backup protection locks also failed.
• Approximately 30 minutes after the destructive activity concluded, the same service principal successfully issued over 30 Storage ListKeys requests. This count reflects successful requests rather than the exact number of keys or accounts collected.
• Destructive operations were executed within the scope of Azure RBAC permissions previously granted to the target accounts, abusing roles such as Storage Account Contributor, Contributor, and SQL DB Contributor.
• The client ID, client secret, and tenant ID for one principal were posted in plain text by an employee of the victim organization in a public GitHub issue and persisted in edit histories even after editing. However, Microsoft has not confirmed whether this secret was directly used for initial intrusion.
• No ransom demands or successful external data exfiltrations have been confirmed in this incident.

Inference

• The combination of resource destruction, attempts to impair recovery protection features, and credential collection aligns with ransomware and double-extortion tactics, though no evidence of ransom demands or successful exfiltration was obtained in this case.
• Microsoft evaluates that the repeated reuse of multiple tokens and the clear division of roles strongly suggest execution via automated tools or scripts. However, this observation alone is insufficient to determine whether individual operational decisions were made by an autonomous AI agent (Agentic AI).

Hypotheses

No additional hypotheses. Unverified items are listed in "14. Open Questions and Further Investigation."

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1078.004	Valid Accounts: Cloud Accounts	high	Authenticated to the Azure Resource Manager API using compromised service principals.
T1526	Cloud Service Discovery	high	Enumerated cloud resources including subscriptions, VMs, resource groups, and storage accounts.
T1485	Data Destruction	high	Deleted core cloud assets including storage accounts, a Key Vault, a Function App, and an App Service plan.
T1490	Inhibit System Recovery	high	Attempted to delete protection locks for Site Recovery and backups (result: failed).

14. Open Questions and Further Investigation

• The exact initial access vector that led to the compromise of the two service principals.
• The exact number of storage access keys obtained via ListKeys operations, the target account count, and whether subsequent data access or external exfiltration occurred.
• The degree to which an autonomous AI agent was involved in individual attack decisions and operational steps.

15. Impact on SOCs and Organizations

Organizations using Azure must strictly manage workload identities, including service principals, as high-value assets equivalent to human privileged accounts. It is essential to enforce comprehensive secret scanning across public GitHub issues, commit histories, and past edit histories, adopt short-lived credentials, and strictly adhere to the principle of least privilege. Microsoft reported that Azure resource locks and account-level deletion protections prevented the deletion of certain storage accounts. This highlights the importance of independent protections that function even when broad administrative privileges are compromised, though it does not imply that recovery from independent backups has been verified.

16. Summary by Persona

• For SOCs: Correlate sudden bulk deletions, ListKeys execution, and lock operations by service principals, and establish a tracking framework that extends to storage data plane access.
• For Administrators: Immediately revoke leaked secrets, Reduce Azure RBAC permissions to the minimum required, and apply deletion-prevention locks and independent backup protections to critical resources.
• For Users: This incident did not stem from general end-user actions, but rather involved the compromise of application identities operated within the cloud.