JADEPUFFER Azure Attack

A threat actor called JADEPUFFER, which Microsoft tracks as Storm-3168, ran a destructive campaign inside a Microsoft Azure environment over about 18 hours in early June 2026, and the operation shows how far an attacker can get with nothing more than a leaked service principal secret.

Microsoft published the analysis, saying the destructive operations were facilitated by compromising service principals and targeting Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services.

The activity is an evolution of JADEPUFFER's tradecraft, and it fits a pattern we have seen before, because JADEPUFFER was first documented by Sysdig as the first ransomware operation run end to end with the help of a large language model.

Quick Summary

How the Attack Started

The attack leveraged two compromised service principals linked to the same tenant, with one used for reconnaissance and resource discovery and the second used for destructive operations and credential collection.

Microsoft said the enumeration activity targeted Azure Virtual Machines, subscriptions, resource groups, and resources for close to 16 hours, carrying out over 300 read operations during that time.

The second compromised service principal also engaged in discovery of its own about 90 minutes later, enumerating virtual machines and resource groups across two subscriptions within five seconds, which is the kind of speed that suggests automation rather than manual work.

So the attacker spent most of the time looking around, mapping the environment, and identifying what was worth destroying.

The Destructive Phase

After 16 hours, the second service principal successfully enumerated Azure App Service configuration stores, likely looking for exposed credentials, and soon after, it conducted more than 150 destructive or credential collection related operations in just 35 minutes.

The destructive sequence itself lasted about seven minutes and involved over 100 storage account deletion attempts, and the attacker also targeted an Azure Key Vault, a Function App, and an App Service plan, along with multiple Azure SQL databases.

Most Azure Storage accounts targeted by the threat actor were successfully deleted, according to Microsoft, but Azure resource locks and storage account level deletion protection blocked deletion attempts for a few of the storage accounts.

That detail matters, because it demonstrates the value of independent safeguards that remain effective even when a compromised identity has broad administrative permissions, and it is a reminder that not every protection lives inside the identity system.

Interestingly, each of the database deletion attempts ended up failing due to the use of an unsupported API version for the Azure SQL database resource type, which is the kind of mistake that suggests the attack was scripted and not carefully tested.

The GitHub Exposure That Started It

It is unclear exactly how the service principal was compromised, but Microsoft said it observed 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 from the issue, it remained accessible through the public edit history, which is a painful reminder that deleting something from a post does not delete it from the record.

Microsoft said it also detected repeated probing from Storm-3168 linked infrastructure against several Azure App services for different customers, adding that the attacks are likely automated or scripted given the division of work using multiple service principals and the timing between operations.

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, suggesting the threat actor was looking to impair the victim's ability to recover.

But no ransom note or successful data exfiltration was observed in connection with the intrusion, so the motivation is inferred from the destruction rather than confirmed by a demand.

The AI-Orchestrated Shift

Microsoft framed this activity as part of a broader shift toward AI-orchestrated attacks, where threat actors can coordinate complex post-compromise operations across cloud environments with greater speed and scale.

And as these capabilities evolve, defenders must similarly use AI to investigate and respond across large environments, which is an uncomfortable symmetry but an honest one.

The earlier JADEPUFFER activity that Sysdig documented used a known security flaw in Langflow, tracked as CVE-2025-3248, to break in, harvested credentials, burrowed deeper into the network, encrypted Nacos service configuration files, dropped the original database tables, and left a ransom note demanding a Bitcoin payment.

That attack used MySQL's built-in AES_ENCRYPT function for the encryption step, and the same Langflow instance was subsequently targeted a second time using a compiled Go based ransomware strain codenamed ENCFORGE.

ENCFORGE is built specifically for AI infrastructure, scanning for nearly 180 file extensions spanning model checkpoints, vector databases, training datasets, and embedding indices, along with macOS-centric files like Keychain stores, Xcode project files, and Apple Pages and Numbers documents.

Sysdig noted at the time that an autonomous agent reasoned about its targets, harvested and reused credentials, moved laterally, established persistence, and destroyed a database, narrating its own intent the entire way, and that none of the individual techniques were novel or sophisticated, but the AI model strung them together into a complete ransomware operation against neglected internet-facing infrastructure.

What Defenders Should Do

• Hunt for exposed service principal secrets in public repositories, including edit history, because deleting a secret from a post does not remove it.
• Apply resource locks and deletion protection to storage accounts and other critical resources, because they blocked some deletions in this attack.
• Monitor for abnormal service principal activity, especially large volumes of read operations followed by destructive actions.
• Look out for the usage of unsupported API versions since that can point to the presence of a scripted attack that was not properly tested.
• Keep backups and the recovery resources isolated from the primary environment, because the attacker targeted recovery protection locks specifically.
• Utilize AI-powered incident investigation tools so as to keep pace with AI-driven attacks.
• View any service principal with broad administrative permissions as a valuable target and change its secrets frequently.

The Bottom Line

The JADEPUFFER Azure attack shows how a leaked service principal secret can turn into a destructive campaign that deletes storage accounts, targets databases and Key Vaults, and attempts to impair recovery, and while some safeguards held, the operation is a reminder that cloud identities are as valuable as passwords and deserve the same level of protection.

Quick Reference

What to Do

• Hunt for exposed service principal secrets
• Apply resource locks and deletion protection
• Monitor service principal activity
• Watch for unsupported API versions
• Keep backups separate
• Use AI-assisted investigation
• Rotate service principal secrets

FAQ Section

What is JADEPUFFER?

It is a threat actor tracked by Microsoft as Storm-3168, and it was first documented by Sysdig as the first ransomware operation run end to end with the help of a large language model.

How did the attacker get in?

Microsoft said the service principal's client ID, client secret, and tenant ID had been exposed in plaintext in a public GitHub issue, and the secret remained accessible through the public edit history.

What did the attacker target?

Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services.

What type of protection helped?

Indeed, the Azure resource lock and the deletion protection of the storage accounts worked on preventing some types of deletion, and deleting the databases failed due to the unsupported API version.

Was there a ransom note?

There was no ransom note or exfiltration of data observed, but the ultimate goal is considered ransomware-oriented in regard to the elimination of recovery capabilities.

What should I do if I use Azure?

Hunt for exposed service principal secrets, apply resource locks and deletion protection, monitor service principal activity, keep backups separate, and rotate secrets regularly.

Source: The Hacker News