JADEPUFFER Used Compromised Principals to Delete Azure Storage

Microsoft has published new details about a destructive cloud attack in which the threat actor known as JADEPUFFER, tracked internally as Storm-3168, used compromised service principals to delete resources from an Azure environment. The incident happened in early June 2026 and lasted about 18 hours. A service principal is an identity used by an application or automated process to access cloud resources, similar to a set of login credentials for software rather than for a person. According to researchers Yossi Weizman, Tushar Mudi and the Microsoft Security Research team, the attackers targeted Azure Storage Accounts, relational databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines and App Services.

JADEPUFFER first came to public attention through research by Sysdig, which described it as the first known ransomware operation run end-to-end with the help of a large language model, the technology behind AI systems that can understand and produce text. The earlier attack exploited CVE-2025-3248, a known security vulnerability in Langflow, an open-source tool used to build AI applications. After breaking in, the attacker harvested credentials, moved deeper into the network, encrypted Nacos service configuration files, dropped the original database tables and left a ransom note demanding payment in Bitcoin. The encryption step used the relational database engine's built-in AES encryption function. The same Langflow instance was later targeted a second time with a compiled Go-based ransomware strain called ENCFORGE. ENCFORGE is designed specifically for AI infrastructure and scans nearly 180 file extensions, including model checkpoints, vector databases, training datasets and embedding indices. It also looks for macOS-related files such as Keychain stores, Xcode project files and Apple Pages and Numbers documents. Sysdig noted that the AI agent appeared to make its own decisions about targets, re-used stolen credentials, moved between systems, set up ways to keep access and destroyed a database, all while narrating its intentions. The company said the individual techniques were not new or sophisticated, but the model combined them into a complete ransomware attack against internet-facing systems that had not been properly maintained.

Microsoft's analysis of the June 2026 incident found two compromised service principals linked to the same tenant. One was used for reconnaissance and resource discovery, while the second was used for destructive operations and credential collection. The enumeration activity targeted Azure Virtual Machines, subscriptions, resource groups and resources for close to 16 hours, during which the attackers performed more than 300 read operations. The second compromised service principal also carried out some discovery of its own about 90 minutes later, enumerating virtual machines and resource groups across two subscriptions within five seconds. After those 16 hours, the second principal successfully enumerated Azure App Service configuration stores, likely in an attempt to find exposed credentials. Soon after, it conducted more than 150 destructive or credential collection-related operations in 35 minutes. The destructive sequence itself lasted about seven minutes and involved over 100 storage account deletion attempts. The attackers also targeted an Azure Key Vault, a Function App, an App Service plan and multiple cloud-based relational database instances. The database deletion attempts all failed because the attackers used an unsupported API version for the cloud-based relational database resource type. An API version is a specific release of a programming interface, and using one that is not supported causes commands to fail.

Most of the Azure Storage accounts targeted by the threat actor were successfully deleted. However, Azure resource locks and storage account-level deletion protection blocked deletion attempts for a few accounts. Microsoft highlighted that these independent safeguards proved useful even when an attacker controlled an identity with wide administrative rights. A resource lock is a setting that prevents a cloud resource from being deleted accidentally or maliciously, and deletion protection serves the same purpose on a storage account. It is unclear how the service principal was compromised, but Microsoft said it observed that its client ID, client secret and tenant ID had been previously exposed in plaintext in a public GitHub issue by an employee of the impacted organization. Although the secret was removed, it remained accessible through the public edit history. Microsoft also detected repeated probing from Storm-3168-linked infrastructure against several Azure App services belonging to different customers. The division of work across multiple service principals and the timing between operations suggest the attacks are likely automated or scripted.

The end goal of the attack is assessed to be ransomware-aligned, because it led to the deletion of numerous Azure resources in addition to backup and recovery-related resources. This suggests the threat actor wanted to impair the victim's ability to recover from the destructive activity. However, no ransom note or successful data exfiltration was observed in connection with this intrusion. Exfiltration means stealing data out of a network. Microsoft said the attack highlights a broader move toward AI-orchestrated attacks, where attackers can coordinate complex post-breach operations across cloud environments faster and at larger scale, and that defenders should also use AI to investigate and respond. AEU-I, which provides security-first IT and consulting, can help organizations review exposed credentials and apply independent safeguards such as deletion protection and backup isolation.