Storm-3168 Azure Attack: How Cloud Resources Vanished in Seven Minutes

Microsoft Security Research reported a cloud attack by Storm-3168, also associated with the name JADEPUFFER, on September 25. The attackers used two compromised Azure service principals: one mapped the environment, while the other searched for credentials and deleted resources.

The researchers place the activity within a broader shift toward automated and AI-orchestrated attacks. The published evidence directly establishes coordinated automation; it does not claim that an AI model independently selected every operation.

How the Storm-3168 attack unfolded

The first service principal spent about 15 hours and 30 minutes enumerating virtual machines, subscriptions, resource groups and other resources. Microsoft observed more than 300 successful read operations. The second principal enumerated virtual machines and resource groups across two subscriptions in only five seconds.

After more searches for configurations and keys, the destructive phase began. The attacker attempted more than 150 destructive or credential-collection operations over 35 minutes. The most concentrated destructive sequence lasted about seven minutes and included more than 100 attempts to delete Azure Storage accounts.

Most targeted storage accounts were deleted. A Key Vault, Function App and App Service plan in one resource group were also removed. Attempts to delete several Azure SQL databases failed because the attacker used an unsupported API version.

Why deleting a GitHub secret is not remediation

Microsoft found that the client ID, client secret and tenant ID for one service principal had previously appeared in plain text in a public GitHub issue. An employee later removed the secret from the issue, but it remained in the public edit history.

The researchers could not confirm that this exact secret enabled the observed attack. The operational lesson is still clear: a published key must be treated as compromised. Editing a page does not revoke it or erase copies from histories, caches, archives and logs.

Which safeguards worked

Resource locks and storage deletion protection blocked some requests even though the compromised identity had broad administrative permissions. The failed Azure SQL deletions resulted from an attacker error, not a defensive policy, so organizations cannot treat that failure as a dependable barrier.

Microsoft recommends immediately revoking and rotating exposed secrets, narrowing service-principal permissions, independently protecting backup and recovery systems, and monitoring unusual bulk operations. Where possible, organizations should replace long-lived secrets with managed identity mechanisms.

What organizations should check now

1. Search code, issues, configuration files and repository history for secrets.
2. Revoke any key that was ever public instead of merely deleting the text.
3. Review service-principal roles under the least-privilege principle.
4. Apply independent locks to critical data and recovery resources.
5. Alert on bulk enumeration, deletion attempts and key retrieval.

The research did not confirm a ransom note or successful data exfiltration. It is therefore more accurate to describe the event as destructive activity consistent with an extortion objective than as a confirmed completed ransomware attack.

Source

• Microsoft Security Research: technical analysis of Storm-3168

Technical figures and the incident timeline come from Microsoft’s September 25, 2026 report.