Storm-3168 Uses Azure CLI Vulnerability to Delete Cloud Resources

Key Takeaways

• Threat actor Storm-3168 leveraged compromised Azure service principals to execute a rapid, destructive attack against an Azure cloud environment, deleting critical resources within minutes.
• The attack highlights the severe risks associated with exposed cloud credentials, which can grant extensive control over an organization’s cloud infrastructure.
• The incident is linked to JADEPUFFER agentic ransomware operations, suggesting an extortion motive, though no ransomware note or confirmed data exfiltration was observed.
• The campaign targeted Azure Storage accounts, SQL databases, Key Vaults, Function Apps, and App Services, along with attempts to disable recovery controls.
• Effective preventative measures include rigorous credential management, adherence to least privilege principles, and robust monitoring for unusual cloud activity.

Storm-3168 Executes Destructive Azure Cloud Attack

A sophisticated cyberattack orchestrated by the threat actor tracked as Storm-3168 has demonstrated the devastating potential of compromised cloud identities. Within a mere seven minutes, the attackers initiated a destructive operation targeting an Azure environment, underscoring how stolen application credentials can provide intruders with sweeping authority over cloud-hosted data, services, and crucial recovery mechanisms.

This incident also accentuates the escalating danger posed by automated cloud attack methodologies. Researchers have linked this activity to JADEPUFFER, an agentic ransomware operation previously documented in other intrusions. The attackers managed to compromise two distinct service principals within a single tenant. One of these identities was used to map the target environment, while the other was deployed for resource destruction and the collection of storage keys.

Microsoft’s security analysts, who track this actor as Storm-3168, confirmed the Azure activity. While the researchers did not definitively establish direct artificial intelligence control over these Azure operations, the speed and coordination observed suggest a high degree of automation. Microsoft said in a report that the campaign specifically targeted vital Azure components, including Storage accounts, SQL databases, Key Vaults, Function Apps, App Services, and their associated recovery controls. Although no ransom note or confirmed data theft was identified during the investigation, the combination of destructive actions and credential harvesting strongly indicates a likely extortion objective.

The Path to Compromise: Exposed Credentials

The root cause of this breach points to a fundamental cloud security vulnerability that predates the destructive phase: exposed credentials. The client ID, secret, and tenant ID for one of the compromised service principals were discovered in plaintext within a publicly accessible GitHub issue. While researchers could not definitively confirm that this specific exposed secret was utilized in the attack, the presence of such sensitive information in a public forum represents a critical security lapse. It is crucial to understand that merely removing a secret from a public post does not revoke its validity or erase its historical exposure.

Chronology of Destruction

The attack unfolded in early June 2026. The initial compromised identity engaged in extensive reconnaissance for approximately 15 hours and 30 minutes, successfully executing over 300 read operations. During this phase, it enumerated virtual machines, subscriptions, resource groups, and other critical cloud resources. Approximately 90 minutes after this discovery phase, a second compromised identity began its own rapid reconnaissance, checking virtual machines and resource groups across two subscriptions in a mere five seconds. This second service principal subsequently probed App Service configuration stores, likely searching for additional exposed credentials, and attempted to query Azure OpenSearch resources, though these attempts were unsuccessful.

The destructive sequence commenced with alarming speed. Seventy seconds after its last inventory action, the second service principal attempted to retrieve a key from a non-existent storage account. Less than a second later, the full-scale deletion operations began. Over a period of approximately seven minutes, Storm-3168 launched more than 100 attempts to delete storage accounts, successfully removing the majority of its targets. The attackers also managed to delete a Key Vault, a Function App, and an App Service plan, all linked to the same resource group.

Notably, some deletion attempts were thwarted by existing resource locks and account-level deletion protections, demonstrating the efficacy of independent safeguards in mitigating damage. The intruder also attempted to delete several Azure SQL databases concurrently, but these efforts failed due to the use of an unsupported API version. Furthermore, the attackers targeted Site Recovery and Azure Backup protection locks. Previous reports on Azure API role flaws underscore the necessity for meticulous permission reviews, even for seemingly narrowly defined cloud roles.

Stolen Identities Elevate Recovery Risks

Approximately 30 minutes after completing the destructive actions, the same identity executed over 30 successful ListKeys requests for various Azure Storage accounts, including those related to Site Recovery. Access keys can expose sensitive data and create pathways for subsequent data exfiltration. The targeting of storage accounts with “terraform” and “backup”-themed names further amplified the risk of severely impeding recovery efforts.

The coordinated timing and the utilization of multiple identities strongly indicate the presence of automated attack tools. Microsoft observed five distinct tokens associated with the service principal responsible for deletion and key collection. Four of these tokens were used for deletion operations, while one focused on storage inventory and key retrieval. During a 70-second window, two deletion tokens were active simultaneously, distributing destructive operations between storage and SQL targets, highlighting the efficiency of the automated approach.

What You Should Do

• Immediately Revoke and Rotate Exposed Credentials: Any credentials discovered in public repositories, logs, or other insecure locations must be instantly revoked and new credentials generated. Conduct a thorough investigation into the past usage of these compromised credentials.
• Implement Strict Secret Management: Ensure that sensitive information like client IDs, secrets, and tenant IDs are never hardcoded into source code, committed to version control systems, or stored in unprotected configuration files. Utilize secure secret management solutions like Azure Key Vault.
• Apply Least Privilege Principles: Grant workload identities and service principals only the absolute minimum permissions necessary to perform their intended functions. Regularly review and audit these permissions.
• Restrict Access to Backup and Recovery Controls: Implement stringent access controls for backup systems and disaster recovery mechanisms. Monitor for any attempts to modify, disable, or delete these critical protections.
• Proactive Threat Hunting: Security teams should actively hunt for anomalous activities, including unexpected resource discovery, high-volume key retrieval requests, and unusual or rapid deletion attempts within the cloud environment.
• Monitor for Indicators of Compromise (IoCs):
  • IPv4: 45.131.66[.]106 (App Service probing and malicious Azure Resource Manager requests)
  • IPv4: 34.153.223[.]102 (App Service probing)
  • IPv4: 64.20.53[.]230 (App Service probing)

  Note: IP addresses 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.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.