Microsoft has linked a destructive Azure cloud campaign to JADEPUFFER, the threat actor it tracks as Storm-3168. The attackers used two compromised Azure service principals to map a victim’s cloud environment, delete resources and collect credentials that could provide access to stored data.
The activity represents a significant expansion of JADEPUFFER’s previously documented operations. The group was first publicly described by Sysdig in July 2026 as an agentic threat actor associated with an AI-driven ransomware operation. Microsoft’s latest investigation provides the first detailed look at JADEPUFFER-linked destructive activity inside Microsoft Azure.
JadePuffer Storm-3168 Azure Attack Used Compromised Service Principals
According to Microsoft Security Research, Storm-3168 compromised two service principals belonging to the same Azure tenant.
The two identities played different roles. One was primarily used for reconnaissance and resource discovery, while the second performed discovery, destructive actions and credential collection.
Azure service principals are non-human identities commonly used by applications, automation and cloud services to authenticate and access Azure resources. If one of these identities is compromised and holds excessive privileges, attackers can potentially operate across cloud infrastructure without needing a traditional employee account.
More Than 300 Reconnaissance Operations Before Destruction
Microsoft observed the first compromised service principal spending approximately 15 hours and 30 minutes enumerating the victim’s Azure environment.
During that period, it completed more than 300 successful read operations covering resources such as:
- Azure Virtual Machines
- Subscriptions
- Resource groups
- Other Azure resources
About 90 minutes after that reconnaissance began, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in approximately five seconds.
Microsoft reported that both service principals used infrastructure linked to Storm-3168, the same network fingerprint and the python-requests/2.34.2 user agent.
Storm-3168 Launched 150+ Destructive and Credential Operations
After the reconnaissance phase, the second compromised service principal moved rapidly into destructive activity.
Microsoft observed more than 150 destructive or credential-collection-related operations during a roughly 35-minute period.
A particularly intense destructive sequence began less than one second after an unsuccessful request for a storage account key and continued for approximately seven minutes.
The threat actor targeted multiple Azure services, including:
- Azure Storage Accounts
- Azure SQL databases
- Azure Key Vault
- Azure Function Apps
- Azure App Services
- Virtual Machines
- Azure Site Recovery protections
- Backup-related resources
Azure Storage Accounts and Recovery Resources Were Targeted
The destructive activity was not limited to production resources. Microsoft observed attempts to interfere with recovery mechanisms as well.
The actor targeted Azure Storage Accounts with names associated with Terraform and backups and attempted to remove recovery protection locks. Microsoft assessed that this activity could indicate an attempt to reduce the victim’s ability to recover from destructive operations.
Some deletion attempts were unsuccessful because protection mechanisms were in place.
The attempted deletion of Azure SQL databases also failed, but not because the attacker lacked privileges. Microsoft said the attacker used an unsupported API version for the Azure SQL Database resource type.
Storage Account Keys Were Collected After the Destructive Activity
The compromised identity also attempted to retrieve Azure Storage Account keys.
Successful ListKeys operations can provide access to storage data depending on the configuration and permissions associated with the account.
Microsoft said this credential collection could potentially support future data access or exfiltration.
However, the researchers did not confirm successful data exfiltration in the observed incident.
Was This a Ransomware Attack?
The activity showed characteristics that Microsoft described as consistent with tactics that could support ransomware or extortion operations.
The actor destroyed cloud resources, targeted recovery mechanisms and collected credentials capable of providing access to data.
However, Microsoft did not observe a ransom note and did not confirm that data was successfully exfiltrated.
For that reason, the Azure incident is more accurately described as a destructive cloud campaign linked to a threat actor previously associated with agentic ransomware rather than a confirmed ransomware event by itself.
How Was the Azure Service Principal Compromised?
Microsoft has not confirmed the initial access method.
Investigators found that the affected service principal’s client ID, client secret and tenant ID had previously been exposed in plaintext in a public GitHub issue posted by an employee of the victim organization.
The GitHub issue was later edited to remove the credentials, but the secret remained accessible through the issue’s public edit history.
Microsoft could not confirm whether the exposed secret was actually used during the Storm-3168 intrusion.
The incident nevertheless highlights an important cloud-security principle: deleting a leaked secret from a public page does not revoke it. Once credentials have been publicly exposed, organizations should assume they are compromised and rotate or revoke them immediately.
Microsoft Also Observed Storm-3168 Probing Azure Applications
Microsoft reported repeated probing from Storm-3168-linked infrastructure against Azure App Services belonging to multiple organizations.
The activity targeted paths associated with several technologies and administrative interfaces, including:
- WordPress administration
- PHP-CGI
- Langflow’s
/api/v1/validate/codeendpoint - Web-shell-like paths
This probing does not prove that those techniques were responsible for the Azure service-principal compromise described in Microsoft’s investigation.
JADEPUFFER Was First Documented by Sysdig
JADEPUFFER was originally documented by the Sysdig Threat Research Team in July 2026.
In that earlier incident, Sysdig observed what it assessed to be the first documented ransomware operation driven end-to-end by a large language model agent.
The operation exploited an internet-facing Langflow instance through CVE-2025-3248 and autonomously performed reconnaissance, credential discovery, lateral movement and destructive database extortion.
That earlier incident is separate from Microsoft’s Azure investigation. Microsoft linked the new activity to the same broader JADEPUFFER cluster and tracks the actor as Storm-3168.
Why Compromised Service Principals Are Dangerous
Service principals often operate quietly in the background and may hold permissions required for applications, automation pipelines or infrastructure management.
If those identities receive broad roles, one stolen credential can provide attackers with access to large parts of a cloud environment.
In the Storm-3168 case, Microsoft found that the destructive operations largely followed permissions the compromised identities already possessed.
A group-granted Storage Account Contributor role allowed destructive storage operations, while Contributor and SQL DB Contributor permissions enabled access to additional resources.
The attack therefore did not require Storm-3168 to bypass Azure authorization controls. The compromised identities already had powerful privileges.
How Organizations Can Reduce Storm-3168-Type Risk
Microsoft recommends reducing exposure by protecting workload identities and secrets, enforcing least privilege and safeguarding recovery resources.
- Rotate exposed secrets immediately: Removing credentials from GitHub or another public location is not enough.
- Reduce service-principal privileges: Review direct and group-inherited role assignments.
- Use managed identities where possible: Reduce reliance on long-lived application secrets.
- Protect backup and recovery resources: Use deletion safeguards and recovery controls that are independent of normal workload identities.
- Monitor unusual service-principal activity: High-volume resource enumeration followed by delete operations should trigger investigation.
- Audit storage-key access: Unexpected
ListKeysoperations may indicate credential collection. - Enable appropriate Microsoft Defender for Cloud protections: Prioritize Storage, Key Vault, App Service, databases and Resource Manager monitoring where relevant.
Agentic Threats Are Moving Into Cloud Infrastructure
The Storm-3168 activity highlights how automated or agentic attack workflows can operate at cloud scale once powerful credentials are compromised.
More than 300 discovery operations and a burst of destructive actions across multiple Azure services demonstrate how quickly cloud infrastructure can be affected when workload identities have excessive permissions.
The security problem is therefore not only whether an attacker uses artificial intelligence. Identity exposure, excessive privileges, weak secret management and insufficient recovery protections remain fundamental weaknesses.
For broader coverage of AI-driven cyber threats, see the CyberUpdates365 AI-Era Threats & Agentic Security hub.
Organizations running exposed AI infrastructure should also review our coverage of the critical Langflow vulnerability, which is relevant to JADEPUFFER’s earlier publicly documented activity.
Security Summary
Microsoft’s investigation shows how a pair of compromised Azure service principals allowed Storm-3168, linked to JADEPUFFER, to perform extensive reconnaissance and rapidly launch destructive operations against cloud resources.
The actor targeted storage, application infrastructure, recovery protections and databases while also collecting storage credentials. Microsoft did not observe a ransom note or confirm successful data exfiltration, so the incident should not be described as a confirmed ransomware attack.
The key defensive lesson is straightforward: workload identities should be treated with the same security discipline as privileged human accounts. Exposed secrets must be revoked, permissions should be minimized and backup protections must remain resilient even if an application identity is compromised.
