Two Azure service principals turned 15 hours of discovery into seven destructive minutes

The destructive phase was short because the permissions were already in place

Microsoft Security Research has documented Azure activity associated with JADEPUFFER, which Microsoft tracks as Storm-3168. Two compromised service principals in one tenant divided the work. One performed broad discovery. The other discovered resources, deleted them and collected credentials.

The first identity enumerated virtual machines, subscriptions, resource groups and other resources for approximately 15 hours and 30 minutes, producing more than 300 successful read operations. About 90 minutes after that activity began, the second identity enumerated virtual machines and resource groups across two subscriptions in five seconds. Sixteen hours later it inspected App Service configuration stores and attempted to retrieve a key from a storage account that did not exist.

Less than one second after that failed request, destruction began. Microsoft counted more than 150 destructive or credential-related operations across 35 minutes. The central destructive sequence lasted approximately seven minutes. The speed is not the interesting part by itself. The permissions that made the speed effective are.

Discovery, destruction and credential collection formed one continuous sequence

The destructive identity attempted more than 100 Storage Account deletions and most of the targeted accounts were successfully deleted. It also deleted a Key Vault, a Function App and an App Service plan in the same resource group. Multiple SQL database deletions were attempted in parallel, but every one failed because the automation used an unsupported API version for that resource type.

The attacker also targeted Azure Site Recovery locks and Azure Backup protection locks. Some Storage Account deletions were stopped by Azure resource locks or account-level deletion protection. Around 30 minutes after the final destructive action, the same identity inventoried Storage Accounts and made more than 30 successful ListKeys requests, including requests involving Site Recovery storage.

That final phase matters because it prevents a simple description of the incident as deletion for deletion's sake. The actor destroyed resources, attempted to weaken recovery and continued collecting credentials that could permit access to remaining data.

A service principal is a workload identity, and its role assignments defined the blast radius

A service principal is the identity an application or automation uses to access Azure. It does not need a person to type a password into a browser. It receives tokens and acts within its assigned Azure roles. That makes it useful for reliable automation and dangerous when long-lived credentials are exposed.

Microsoft says the successful operations followed existing role assignments. A group-granted Storage Account Contributor role authorised the destructive storage operations. Direct Contributor access authorised deletion of the Key Vault, Function App and App Service plan, as well as an additional successful key retrieval. Direct SQL DB Contributor access authorised the database deletion attempts, which failed because the request used the wrong API version rather than because access was denied.

This is a permissions story before it is an AI story. The automation did not invent authority. It exercised authority that the tenant had already granted to the workload identity.

How existing permissions mapped to the observed operations

Role or control	What it permitted or prevented	Observed result
Storage Account Contributor through a group	Storage management operations	Most targeted Storage Accounts were deleted
Direct Contributor	Management of application resources	Key Vault, Function App and App Service plan deleted
Direct SQL DB Contributor	SQL database management	Deletion authorised but requests failed on API version
Resource and deletion locks	Independent denial of selected deletion operations	Some Storage Account deletions blocked

Removing a secret from a page does not revoke the secret

Microsoft found that a client ID, client secret and tenant ID associated with one service principal had previously appeared in plaintext in a public GitHub issue. An employee later edited the issue, but the secret remained accessible through public edit history. Microsoft could not confirm that this secret was the credential used in the observed incident, so it is a possible initial-access route rather than an established one.

The remediation principle does not depend on attribution. Once a credential appears in a public location, deletion or redaction changes the page but not the credential. Copies can remain in edit history, caches, archives, logs and local clones. The only reliable response is immediate revocation or rotation followed by a review of historical use.

Long-lived workload secrets make this failure mode persistent. Managed identities, workload identity federation and shorter credential lifetimes reduce reliance on static secrets, but they do not replace least privilege or monitoring of token use.

The Azure evidence strongly supports automation; the stronger agentic label comes from the wider campaign

Microsoft observed overlapping token streams, five unique tokens for the destructive identity and a division of labour across identities. Two deletion tokens were active during the same 70-second period, with one focused on Storage Accounts while another mixed Storage and SQL deletion. Microsoft says the timing and coordination strongly indicate automated or scripted execution.

JADEPUFFER had previously been described by Sysdig as an agentic ransomware operation. Microsoft uses that wider attribution and describes a broader shift towards AI-orchestrated attacks. The Azure telemetry in this incident proves coordinated automation. By itself it does not reveal which model, planner or agent framework selected each action.

That distinction is useful because defenders do not need to settle the marketing vocabulary before acting. Whether the loop was an agent, a script or a hybrid, it moved at machine speed through permissions that were valid. Controls must therefore constrain the identity and protect recovery resources independently, rather than depend on a person noticing each deletion in time.

The most valuable control was independent of the compromised identity

The resource locks that blocked some deletions did not prevent the compromise, stop discovery or save every resource. They did something narrower and more important: they denied selected destructive operations after a privileged identity was already acting inside the tenant.

That is the right design test for recovery. If the same identity can administer production, remove backups and delete the locks protecting those backups, recovery is another production permission. A resilient design separates those authorities, monitors attempts to change recovery controls and keeps evidence outside the blast radius.

Key facts