The latest activity linked to JADEPUFFER shows how ransomware-style attacks are expanding from individual servers and databases into the cloud control plane itself. Microsoft says the threat actor, which it tracks as Storm-3168, compromised Azure service principals and used them to enumerate a victim’s cloud environment, collect credentials, delete storage accounts, remove application infrastructure, and attempt to interfere with backup and recovery resources. The intrusion took place over roughly 18 hours in early June 2026, with the most destructive activity compressed into only a few minutes.

That progression is important because the attacker did not need to compromise every workload individually. Once a sufficiently privileged cloud identity was under attacker control, Azure Resource Manager became the mechanism through which the destruction was carried out. This is one of the most important differences between traditional infrastructure ransomware and cloud-native destructive operations: compromising the control-plane identity may provide the attacker with the authority to delete or manipulate large numbers of resources without ever logging into the underlying virtual machines.

Microsoft observed two compromised service principals belonging to the same Azure tenant. One was used mainly for reconnaissance and resource discovery, while the second conducted additional discovery, destructive operations, and credential collection. The first identity spent around 15.5 hours enumerating subscriptions, resource groups, virtual machines, and other Azure resources, performing more than 300 successful read operations. The second service principal later enumerated multiple subscriptions in seconds before eventually accessing App Service configuration stores, possibly searching for additional credentials.

This long discovery phase was followed by an abrupt destructive sequence. Microsoft says the second compromised service principal launched more than 150 destructive or credential-related operations in approximately 35 minutes, while the core deletion sequence lasted about seven minutes. More than 100 storage-account deletion attempts were made, and most of the targeted storage accounts were successfully deleted. An Azure Key Vault, Function App, and App Service plan were also deleted.

The attackers also attempted to delete multiple Azure SQL databases. Those attempts failed, not because a defensive control explicitly stopped them, but because the attackers used an unsupported API version for the Azure SQL resource type. That detail is revealing because it demonstrates that even highly automated attack workflows remain capable of making technical mistakes. Automation increases speed and scale, but it does not magically make every attack step correct.

The operators additionally targeted Azure Site Recovery locks and Azure Backup protection locks, which suggests an effort to impair the victim’s ability to recover. That behavior is especially important because modern ransomware and destructive campaigns increasingly target recovery infrastructure before or during encryption and deletion. A company with strong backups can recover from many incidents; a company whose attacker can delete both production data and recovery mechanisms is in a dramatically worse position.

Some of the deletion attempts failed because Azure resource locks and storage-account-level deletion protection remained effective even though the compromised identity had broad administrative rights. This is one of the strongest defensive lessons from the incident. Independent safeguards can still work after an identity has been compromised. Least privilege is important, but organizations should also implement technical controls that require an attacker to defeat additional protection layers before critical data can be destroyed.

The compromised identity also performed more than 30 successful ListKeys operations against Azure Storage accounts after the destructive activity. Storage-account keys can provide direct access to underlying data outside the normal Azure RBAC path. This is particularly concerning because rotating or disabling the compromised service principal would not necessarily invalidate storage-account keys that had already been collected.

The combination of destructive activity and credential collection suggests the attackers were interested in maintaining options. They were not simply deleting resources. They were also collecting credentials that could potentially allow continued access to surviving data or support later exfiltration. Microsoft says it did not observe successful data exfiltration in this incident and did not see a ransom note, so the operation should not be described as a confirmed extortion event. However, Microsoft assesses the behavior as ransomware-aligned because of the resource destruction, attacks on recovery mechanisms, and credential collection.

One of the most significant aspects of the incident is the possible source of the compromised Azure credentials. Microsoft 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 created by an employee of the victim organization. The secret was later removed from the issue, but remained visible through GitHub’s public edit history. Microsoft could not confirm that this exact exposure was the initial access vector, so that connection should remain an assessment rather than a proven cause.

Nevertheless, the finding illustrates an extremely important secret-management principle: deleting or editing an exposed credential does not make the credential safe again. Once a secret has appeared publicly, it may exist in repository history, issue revisions, caches, search indexes, screenshots, archives, security scanners, attacker databases, or automated secret-harvesting systems. The only safe response is to revoke or rotate it immediately.

Service principals are particularly sensitive because they are workload identities rather than ordinary human users. They are frequently used by automation, applications, Terraform deployments, CI/CD workflows, cloud services, and integration platforms. As a result, organizations sometimes treat them as plumbing rather than identities requiring the same governance applied to user accounts. That is becoming increasingly dangerous.

A compromised service principal can be more valuable than a compromised employee account if it has broad Contributor rights, access to multiple subscriptions, or permission to retrieve sensitive secrets. It may also evade controls designed around human behavior, such as impossible-travel detection, MFA prompts, or normal interactive sign-in monitoring.

The JADEPUFFER activity therefore highlights a broader shift from human identity security to workload identity security. Organizations need continuous inventory and governance of service principals, managed identities, application registrations, API keys, secrets, certificates, and machine-to-machine credentials. Every non-human identity should have a clear owner, known purpose, tightly scoped privileges, monitored usage pattern, and defined credential lifecycle.

The Azure permissions assigned to the compromised identity directly enabled much of the destruction. Microsoft says group-granted Storage Account Contributor privileges authorized the storage deletions, while direct Contributor permissions enabled deletion of application resources. SQL DB Contributor permissions allowed database deletion attempts. In other words, the attacker did not need to bypass Azure authorization controls after compromising the identity. The identity already possessed the authority required.

This is why least privilege needs to be evaluated in terms of blast radius, not merely whether an application technically requires a permission. A workload identity used for normal automation may have accumulated privileges over time because granting broad Contributor access is easier than maintaining granular role assignments. That convenience can become catastrophic when the credential is stolen.

The attack also illustrates why cloud-resource deletion should be treated as a high-risk operation deserving separate controls. Large-scale deletion of storage accounts, databases, recovery locks, or Key Vaults is unusual in most environments. Organizations should alert aggressively on bursts of destructive Resource Manager operations, particularly where one service principal suddenly begins deleting resources across multiple services or subscriptions.

Cloud security monitoring should therefore focus on behavioral changes in identities, not just suspicious IP addresses. A legitimate service principal calling the Azure API from an unusual source and suddenly transitioning from normal deployment operations into subscription-wide enumeration and deletion should be considered highly suspicious even if the credentials are valid.

The activity associated with JADEPUFFER is also notable because of its earlier connection to agentic ransomware. Sysdig previously documented the actor using an autonomous AI agent to exploit a vulnerable Langflow instance, harvest credentials, move laterally, establish persistence, encrypt database content, delete original tables, and leave a ransom note. Microsoft says the latest Azure activity represents an evolution of that same threat actor’s tradecraft.

However, the exact role of AI in this specific Azure incident should be described carefully. Microsoft says the timing, overlapping token streams, and division of activity between compromised service principals strongly indicate automation or scripting. The company also places the activity in the wider context of AI-orchestrated attacks. But the published evidence does not mean that every individual Azure API call has been proven to have been autonomously selected by an LLM.

That distinction matters because the key security lesson does not depend on whether every action was AI-generated. The speed and coordination are already enough to create a serious defensive problem.

More than 150 destructive or credential-related actions occurred within 35 minutes. Two service principals were used for different functions. Multiple tokens were active simultaneously, with separate token streams handling deletion and credential retrieval. Defenders operating manually may simply not have enough time to investigate one alert at a time while the attacker is executing parallel cloud operations.

This represents one of the most important challenges posed by increasingly automated attacks: defender reaction time becomes part of the attack surface. If a SOC needs 20 minutes to validate an alert but an attacker can delete most of a tenant’s storage accounts in seven minutes, detection without automated containment may be insufficient.

Organizations should therefore consider automated response controls for certain high-confidence cloud events. Examples include temporarily disabling a service principal when it suddenly performs large-scale destructive actions, blocking credentials exhibiting previously unseen behavior, or requiring stronger controls before backup protections and large numbers of resources can be deleted.

The challenge is to implement such automation carefully enough to avoid causing the same outage the attacker is attempting to create. Still, the direction is becoming difficult to ignore: highly automated cloud attacks increasingly require highly automated defensive responses.

Backup architecture deserves separate attention. Backups and recovery resources should not inherit the same identity and permissions used for ordinary application operations. If the identity capable of modifying production workloads can also disable or delete recovery protections, compromise of that identity defeats both production and recovery layers simultaneously.

Organizations should therefore isolate backup privileges, use resource locks, deletion protection, immutable storage where appropriate, separate administrative identities, and alert on any attempt to weaken those controls. The fact that some Azure resource locks successfully prevented JADEPUFFER-linked deletion attempts provides real-world evidence that these controls are more than compliance decoration.

Credential discovery from App Service configuration is another important lesson. Application environments frequently contain connection strings, API credentials, database passwords, storage keys, and third-party secrets in configuration stores. Once an attacker controls a sufficiently privileged cloud identity, these configurations can become a secondary source of credentials for lateral movement.

Secrets should therefore be moved wherever possible into dedicated vaults with narrow access policies, short lifetimes, and detailed auditing. Simply placing a secret inside cloud application configuration should not be considered secure merely because the application itself is not publicly readable.

Organizations should also inspect public repositories, GitHub issues, CI logs, support tickets, documentation, and collaboration systems for historical credential exposure. Secret scanning should include not just current source files but also commit history, issue edit history, pull requests, build logs, and archived artifacts. Attackers increasingly automate collection of such material, which means a credential may be stolen within minutes of becoming public.

If a service principal secret has ever appeared publicly, security teams should treat it as compromised regardless of whether there is evidence somebody used it. Rotate first and investigate second. Waiting for proof of abuse leaves the attacker holding a valid credential while the organization debates probabilities.

The broader cybersecurity lesson from this incident is that cloud ransomware may increasingly look very different from traditional ransomware. There may be no ransomware executable deployed to hundreds of endpoints. There may be no encryption routine running locally on every virtual machine. Instead, an attacker can compromise a cloud identity and use legitimate management APIs to delete or alter the resources themselves.

The attack chain becomes:

service principal compromised → Azure-wide reconnaissance → configuration and credential discovery → parallel Resource Manager operations → storage and application deletion → recovery protections targeted → additional credentials collected

Every step can be performed through legitimate cloud APIs with valid authentication.

That makes identity the real perimeter.

The JADEPUFFER-linked activity therefore reinforces three priorities: protect workload identities, restrict their privileges, and make destructive cloud actions independently difficult even after an identity is compromised.

The most important lesson is probably the simplest one: a cloud identity with broad permissions is effectively administrative code.

If its credential leaks, the attacker does not need to “break into” each Azure resource individually.

Azure will perform the destruction for them, because the compromised identity is already authorized to ask.

The threat actor known as JADEPUFFER has been observed orchestrating destructive actions within a Microsoft Azure environment using compromised service principals. Microsoft, which is tracking the activity under the name Storm-3168, has called it an evolution of the threat actor's tradecraft. The attack took place in early June 2026 over a period of about 18 hours. "The destructive operations

Source: JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources via The Hacker News — published 28 Sep 2026.