JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources

1. Executive summary

Between early June 2026, two compromised service principals in a single Azure tenant carried out an 18-hour intrusion that ended in bulk destruction of cloud resources: 100+ storage account deletion attempts, plus attempts against Azure SQL databases, Key Vaults, Function Apps, App Service plans, Virtual Machines and recovery protection locks. Microsoft tracks the activity as Storm-3168 and attributes it to JADEPUFFER, the actor Sysdig documented in July 2026 as the first ransomware operation run end to end by a large language model. The verified reference data holds no MITRE ATT&CK profile for JADEPUFFER, so the attribution is unconfirmed and clients should treat it as a working hypothesis, not an established fact. For EMEA financial services the exposure is workload identity: a leaked service principal secret is a standing credential that keeps working after the disclosure that exposed it is taken down, and the destructive phase here ran for seven minutes, which is faster than most manual incident response can react. No CVE is assigned to the Azure activity itself; the only CVE in the source material is CVE-2025-3248 in Langflow, which belongs to the earlier, separate JADEPUFFER intrusion and carries no CVSS, EPSS or CISA KEV entry in the verified reference data.

2. Regulatory framing

Article	Trigger (the fact in this item)	Practical impact
DORA Art. 28: ICT third-party risk, general principles	The destructive operations ran inside Microsoft Azure and were only partly stopped by Azure-native controls (resource locks and storage account deletion protection); the tenant's cloud provider is the third party whose platform hosted the loss.	The Azure dependency and the residual risk that provider-side controls did not stop must be captured in the ICT third-party risk register, not treated as an internal control failure alone.
DORA Art. 19: reporting of major ICT-related incidents to competent authorities	Bulk deletion of storage accounts, SQL databases, Key Vaults, Function Apps and App Service plans is a candidate major incident; classification under Art. 18 determines whether Art. 19 reporting is triggered.	If the deletion meets the major-incident threshold, the reporting clock runs from classification, so the timeline and the affected-resource inventory have to be assembled during response, not after.
NIS2 Art. 21(2)(d): supply chain security measures	The initial access vector is not established in the source material, and the compromised identity is a workload credential issued by the cloud provider's identity plane.	Where the entity is in NIS2 scope, the service principal lifecycle (issuance, storage, rotation, revocation) is a supply chain security control that has to be evidenced.

3. Technical analysis & attack chain

Microsoft observed two compromised service principals belonging to the same tenant. One performed reconnaissance and resource discovery. The second performed discovery, destructive operations and credential collection. Both used Storm-3168-linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2. The intrusion ran for about 18 hours in early June 2026.

Confirmed sequence, from Microsoft's account:

The first compromised service principal enumerated Azure Virtual Machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes, with 300+ successful read operations. The breadth gave the operator visibility across the tenant's Azure estate.
About 90 minutes after that enumeration began, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds.
Sixteen hours later, the second service principal successfully enumerated Azure App Service configuration stores, assessed as an attempt to find exposed credentials. It also made an unsuccessful attempt to look for Azure OpenSearch resources.
Seventy seconds after that final inventory operation, the same service principal attempted a ListKey operation against a storage account that did not exist.
Less than one second after that failed ListKey, the second service principal began destructive activity: 150+ destructive or credential-collection operations in 35 minutes.
The destructive sequence itself lasted about seven minutes and included 100+ storage account deletion attempts. Most targeted storage accounts were deleted successfully. Azure resource locks and storage account-level deletion protection blocked deletion attempts against a few storage accounts.
Also targeted: an Azure Key Vault, a Function App, an App Service plan, and multiple Azure SQL databases. Every Azure SQL database deletion attempt failed because the operator used an unsupported API version for the Azure SQL database resource type.

Two details matter for defenders more than the rest. First, the SQL database deletions failed for an operational reason, not a control reason: the attacker used the wrong API version. That is luck, not resilience, and it will not repeat. Second, the storage accounts that survived did so because of independent safeguards (resource locks, account-level deletion protection) that held even though the compromised identity had broad administrative permissions. Those controls are the difference between partial and total loss in this intrusion.

The source material does not state the initial access vector for the Azure activity. Microsoft observed the client ID, client secret and tenant ID of the compromised service principal, but how the secret was obtained is not established. Microsoft's own guidance notes that publicly exposed credentials remain usable until revoked or rotated, and that removing the original disclosure does not remediate the exposure. That is the most likely shape of the entry path, but it is not confirmed here.

The earlier JADEPUFFER intrusion, documented by Sysdig, is a separate event and should not be conflated with the Azure activity. In that operation the actor exploited CVE-2025-3248 in Langflow to break in, harvested credentials, moved laterally, encrypted Nacos service configuration files, dropped the original database tables, and left a ransom note demanding Bitcoin. Encryption used MySQL's built-in AES_ENCRYPT() function. The same Langflow instance was later hit a second time with a compiled Go-based ransomware strain codenamed ENCFORGE, which scans for nearly 180 file extensions covering model checkpoints, vector databases, training datasets and embedding indices, plus macOS-centric files including Keychain stores, Xcode project files, and Apple Pages and Numbers documents. The verified reference data gives no CVSS, EPSS or CISA KEV entry for CVE-2025-3248, so no exploitation state can be asserted for it from this advisory.

Confidence caveats. The Azure attack chain rests on a single vendor report (Microsoft Threat Intelligence, 25 September 2026). The Langflow and ENCFORGE detail rests on a single vendor report (Sysdig, July 2026, relayed here via The Hacker News). The JADEPUFFER attribution has no MITRE ATT&CK profile in the verified reference data and is unconfirmed. Treat the actor name as a tracking label, not an established identity.

4. Mitigation & containment

P1 within 24 hours

Inventory every service principal in every Azure tenant and subscription. For each, record client ID, owning application, secret and certificate expiry, and last sign-in. Any principal with no owner, no recent legitimate use, or broad subscription-level role assignments is a candidate for disablement.
Rotate or revoke secrets and certificates for any service principal whose credential has ever appeared in a public repository, paste site, log, ticket or chat export. Removing the disclosure does not remediate the exposure; only rotation does.
Enable Azure resource locks (CanNotDelete) on storage accounts, Key Vaults, SQL servers, Function Apps and App Service plans that hold production or recovery data. Enable storage account-level deletion protection (soft delete and container soft delete) where it is not already on. These are the controls that stopped deletion in this intrusion.
Confirm that recovery protection locks and backup immutability are configured and that the backup identity is separate from the identities that administer production. A compromised principal with broad administrative rights should not be able to delete the backups.
Hunt for the user agent python-requests/2.34.2 in Azure activity logs, Entra sign-in logs and any cloud proxy or egress logs. It is a legitimate library string, so treat it as a lead, not a verdict, and correlate it with service principal sign-ins from unexpected source IPs.

P2 within 72 hours

Apply least privilege to workload identities. Remove subscription-level Owner and Contributor from service principals that only need resource-group or resource-scoped roles. Where a principal needs to read configuration, grant reader roles rather than management roles.
Turn on Microsoft Defender for Cloud protections for the resource types named in this advisory (Storage, SQL, Key Vault, App Service, Resource Manager, Containers) so that anomalous deletion and credential-access operations generate alerts.
Restrict service principal sign-ins by IP range or trusted location where the workload's network egress is predictable, and require certificate-based authentication rather than client secrets for principals that support it.
Review Azure SQL database deletion permissions separately. The failed deletions in this incident were caused by an unsupported API version, not by a control, so verify that the permission itself is restricted.

P3 within 7 days

Build a service principal lifecycle process: issuance requires an owner and an expiry, secrets rotate on a schedule, and unused principals are disabled automatically. This is the control that prevents the next incident rather than responding to this one.
Test the destructive path. Attempt to delete a non-production storage account and a non-production SQL database with a service principal that has production-equivalent rights, and confirm that locks, soft delete and backup immutability stop it. Record the result.
Rehearse the seven-minute problem. The destructive phase here ran for about seven minutes. Any response playbook that assumes hours of attacker dwell time before damage needs to be rewritten around automated containment triggers.

5. Indicators of compromise

The source material contains no atomic indicators: no file hashes, no domains, no IP addresses, no file paths, no registry keys. What it does contain are observable behaviours. Those are listed below and are not suitable for the copyable block, which is reserved for machine-pivotable atomic indicators.

No indicators of compromise available in the source material.

Behavioural indicators

behaviour	where to observe	confidence
Service principal sign-in using user agent `python-requests/2.34.2`	Entra ID sign-in logs, Azure Activity Log, cloud egress/proxy logs	Medium. The string is a legitimate Python library default and appears in benign automation; single-sourced from Microsoft.
One service principal performing 300+ read operations across VMs, subscriptions, resource groups and resources over roughly 15.5 hours	Azure Activity Log, filtered to the principal's client ID	High for the pattern, single-sourced for the volume.
A second service principal enumerating VMs and resource groups across two subscriptions within five seconds	Azure Activity Log	High for the pattern, single-sourced.
Enumeration of Azure App Service configuration stores, consistent with hunting for exposed credentials	Azure Activity Log, App Service configuration read operations	Medium. Microsoft assesses the intent; the operation itself is observed.
`ListKey` operation against a non-existent storage account, immediately preceding destructive activity	Azure Activity Log, storage account key operations	High. Distinctive and single-sourced.
Burst of 150+ destructive or credential-collection operations within 35 minutes from one principal	Azure Activity Log	High for the pattern, single-sourced.
100+ storage account deletion attempts within a seven-minute window	Azure Activity Log, storage account delete operations	High for the pattern, single-sourced.
Azure SQL database deletion attempts failing with an unsupported API version error	Azure Activity Log, SQL database delete operations	High. The failure mode is distinctive.

6. Detection

The source material gives no file artefacts, no command lines, no mutexes and no registry keys, so a YARA rule would have nothing genuine to match on. The usable material is behavioural and log-based, which is what Sigma is for. The rule below targets the destructive burst pattern: a single service principal issuing a high volume of delete operations against storage accounts in a short window.

title: Azure Service Principal Bulk Storage Account Deletion Burst
id: 8f3c1a72-4d5e-4b91-9c2a-6e7f0b1d3a84
status: experimental
description: Detects a single Azure service principal issuing a high volume of storage account delete operations in a short window, consistent with the Storm-3168 destructive phase observed in June 2026.
author: Adverse Trace
date: 2026-09-28
references:

  - https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/
  - https://thehackernews.com/2026/09/jadepuffer-linked-attackers-used.html
logsource:
  product: azure
  service: activitylogs
detection:
  selection:
    operationName:

      - 'Microsoft.Storage/storageAccounts/delete'
      - 'Microsoft.Storage/storageAccounts/listKeys/action'
    status:

      - 'Succeeded'
      - 'Failed'
    identity:
      type: 'ServicePrincipal'
  timeframe: 10m
  condition: selection | count() by identity.claims.appid > 20
fields:

  - identity.claims.appid
  - callerIpAddress
  - operationName
  - resourceId
  - status
falsepositives:

  - Legitimate infrastructure-as-code teardown of ephemeral environments
  - Scheduled cleanup automation with broad storage permissions
level: high

Two supporting detections are worth building alongside it, both from the same log source. First, a service principal enumerating VMs, resource groups and subscriptions at a rate no human operator produces (the second principal here covered two subscriptions in five seconds). Second, a service principal reading App Service configuration stores, which is a low-volume operation that should almost never come from a workload identity. Neither is included as a rule because the source does not give the exact operation names, and inventing them would produce a rule that never fires.

7. Sources

Microsoft Threat Intelligence, "Storm-3168: Agentic-driven cloud attacks using compromised service principals", https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/, 2026-09-25.
The Hacker News, "JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources", https://thehackernews.com/2026/09/jadepuffer-linked-attackers-used.html, 2026-09-28.
Sysdig, JADEPUFFER ransomware operation analysis, July 2026. Referenced in both sources above; the primary Sysdig report was not supplied with this item and its URL is not available here.

8. Adverse Trace position

Adverse Trace assesses this as a high-impact destructive cloud incident with an unconfirmed actor attribution. The Azure attack chain is single-sourced to Microsoft and the Langflow and ENCFORGE detail is single-sourced to Sysdig; the JADEPUFFER name has no MITRE ATT&CK profile in our verified reference data, so we treat it as a tracking label rather than an established identity. No CVE in this item carries a CVSS, EPSS or CISA KEV entry in our reference data, and we will not assign one. The material risk to EMEA financial services clients is not the actor name, it is the control gap the incident exposes: a service principal secret that stays valid after the disclosure that leaked it is removed, and a destructive phase that completes in seven minutes. Clients should prioritise service principal inventory and rotation, resource locks and storage deletion protection, and a containment playbook that can act in minutes rather than hours. We will monitor for a primary Sysdig report and for any Microsoft update that establishes the initial access vector, and we will reissue this advisory if either changes the assessment.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.