Storm-3168: Agentic-driven cloud attacks using compromised service principals

1. Executive summary

Microsoft Security Research has attributed an Azure resource-destruction campaign to Storm-3168, the actor it tracks in connection with JADEPUFFER, using two compromised service principals in a single tenant. The actor spent roughly 16 hours on reconnaissance, then ran a seven-minute destructive sequence of 100+ storage account deletion attempts plus Key Vault, Function App and App Service plan deletions, followed by 30+ successful ListKeys calls against storage accounts. No CVE is involved: this is abuse of legitimately assigned Azure role permissions, so there is no patch to apply and no CISA KEV entry to track. The exposure for EMEA financial services is workload-identity hygiene, because a leaked service principal secret with Contributor or Storage Account Contributor scope is directly usable for bulk destruction and key retrieval until the credential is revoked. Neither JADEPUFFER nor Storm-3168 has a MITRE ATT&CK profile in our reference data, so the attribution is unconfirmed.

2. Regulatory framing

No DORA incident-reporting article is engaged on the facts available: the source describes activity in one impacted tenant and does not state that any EMEA entity suffered a major incident. If a client confirms this activity in its own tenant, DORA Art. 17, Art. 18 and Art. 19 and NIS2 Art. 23 become live and the classification and reporting clocks start.

3. Technical analysis & attack chain

The campaign is a post-compromise cloud operation. There is no exploited vulnerability, no malware binary and no CVE. The actor held valid credentials for two service principals in the same Azure tenant and used the permissions already assigned to those identities.

Confirmed sequence, from the Microsoft account of the impacted tenant:

1. In early June 2026, 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.
2. About 90 minutes after that enumeration began, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both service principals used Storm-3168-linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2.
3. Sixteen hours later, the second service principal enumerated Azure App Service configuration stores, which Microsoft assesses as a possible search for exposed credentials. It also made an unsuccessful attempt to find Azure OpenSearch resources.
4. Seventy seconds after that inventory operation, the same service principal attempted a ListKey operation against a non-existent storage account.
5. Less than one second later, the destructive phase began. The second service principal attempted 150+ destructive or credential-collection operations over 35 minutes, with the destructive sequence itself lasting about seven minutes.
6. That sequence included 100+ storage account deletion attempts. Most targeted storage accounts were deleted. Azure resource locks and storage account-level deletion protection blocked deletion for a few of them.
7. An Azure Key Vault, a Function App and an App Service plan were deleted. All three belonged to the same resource group and appeared to support the Function App.
8. In parallel, the same service principal attempted to delete multiple Azure SQL databases. Every attempt failed because it used an unsupported API version for the Azure SQL database resource type.
9. Multiple deletion attempts against Azure Site Recovery locks and Azure Backup protection locks protecting storage accounts also failed.
10. About 30 minutes after the final destructive activity, the same service principal inventoried Azure Storage Accounts and made 30+ successful ListKeys requests, asking Azure Resource Manager to return each storage account's access keys. These included Azure Site Recovery-related storage accounts.

Permission model. The operations followed the identity's existing Azure role assignments. A group-granted Storage Account Contributor role authorized the storage deletions. Direct Contributor access authorized the three application-resource deletions and one additional successful key retrieval. Direct SQL DB Contributor access authorized the SQL deletion attempts, which failed on the unsupported API version rather than on authorization.

Automation evidence. Microsoft observed five unique tokens issued for the service principal used for destruction and credential collection: four supported deletion, the fifth handled storage inventory and key retrieval. Two of the deletion tokens were active during the same 70-second period, one focused on storage account deletion and the other on a mixture of storage and SQL deletion. The timing between operations, the division of work across two service principals, and the overlapping token streams from one service principal indicate automated or scripted execution.

Recovery targeting. The actor deleted resources while also targeting backup and recovery resources, including Azure Site Recovery locks and storage accounts with terraform and backup themed names. Microsoft assesses this as a possible intent to impair the victim's ability to recover. The parallel targeting of SQL databases and storage accounts suggests an intent to broaden destructive impact across data services rather than concentrate on one resource type.

Impact and what was not observed. Microsoft did not observe a ransom note and did not confirm successful data exfiltration in this activity. The resource destruction, attempts to interfere with recovery, and collection of credentials that could provide access to data are consistent with tactics that can support ransomware and extortion operations. That is an assessment of intent, not a confirmed extortion event, and it should be read that way.

Confidence caveats. This entire technical account is single-sourced to Microsoft Security Research. The JADEPUFFER link rests on Microsoft's tracking of the actor it discovered via Sysdig's July 2026 reporting; we have not independently corroborated the two identities as the same actor. Neither JADEPUFFER nor Storm-3168 has a MITRE ATT&CK profile in our reference data, so the attribution is unconfirmed and the actor naming should not be treated as settled. The source does not state how the service principal credentials were originally compromised, so the initial access vector is unknown.

4. Mitigation & containment

P1, within 24 hours:

• Inventory every service principal in every Azure tenant and subscription and identify any holding Contributor, Storage Account Contributor or SQL DB Contributor at subscription or resource group scope. These three roles are the ones the actor used. Reduce them to the narrowest scope that the workload needs, or replace them with a custom role that omits Microsoft.Storage/storageAccounts/delete, Microsoft.Storage/storageAccounts/listKeys/action and the SQL delete operations.
• Rotate the credentials of any service principal whose secret or certificate may have been exposed. Microsoft states plainly that publicly exposed credentials remain usable until revoked or rotated, and that removing the original disclosure does not remediate the exposure. Rotation, not takedown, is the fix.
• Enable Azure resource locks (CanNotDelete) and storage account-level deletion protection on production storage accounts, Key Vaults, Function Apps and App Service plans. These controls blocked deletion attempts in the impacted tenant even though the compromised identity held broad administrative permissions.
• Confirm that Azure Backup and Azure Site Recovery protection locks are in place on the storage accounts and recovery vaults that hold backups. The actor attempted to delete these locks; they held.

P2, within 72 hours:

• Hunt for the user agent python-requests/2.34.2 in Azure Activity Log, Entra ID sign-in logs and any ARM request logging, correlated with service principal authentication. This user agent is the single most distinctive artefact in the source.
• Hunt for the behavioural pattern rather than a signature: a service principal issuing a high volume of read operations across subscriptions, followed within hours by delete operations and then by listKeys calls. The source gives the shape of the sequence, not atomic indicators, so detection has to be built on operation type and volume.
• Restrict which identities can call listKeys on storage accounts. Where a workload can use Entra ID authentication to storage instead of account keys, remove the key-based path entirely.
• Enable the Microsoft Defender for Cloud plans the source names as coverage for this activity: Defender for App Services, Defender for Databases, Defender for DNS, Defender for Storage, Defender for Resource Manager and Defender for Key Vaults. The relevant alerts are listed in §6.

P3, within 7 days:

• Review Azure role assignments granted to groups rather than to individual identities. The storage destruction in this incident was authorized by a group-granted Storage Account Contributor role, which is the assignment pattern most likely to be over-broad and least likely to be reviewed.
• Test recovery from the destructive scenario: restore a storage account and a Key Vault from backup with the primary resource deleted, and confirm the recovery path does not depend on a credential the same identity could revoke.
• Where service principal secrets are stored in code repositories, configuration stores or App Service configuration, treat the configuration store itself as a credential store and restrict read access accordingly. The actor enumerated App Service configuration stores before the destructive phase, which Microsoft assesses as a possible search for exposed credentials.

5. Indicators of compromise

The three IP addresses are described by Microsoft as App Service probing and, for 45.131.66[.]106, malicious ARM requests. They are single-sourced; verify before enforcing a block, and note that all three are cloud-hosted addresses that may be reassigned.

ipv4  45.131.66[.]106
ipv4  34.153.223[.]102
ipv4  64.20.53[.]230
user-agent  python-requests/2.34.2

Behavioural indicators

6. Detection

The source provides no file hashes, no malware strings and no filenames, so a YARA rule would have nothing to match on. Detection here is log and behaviour based. The Sigma rule below targets the user agent, which is the one artefact specific enough to pivot on; the behavioural indicators in §5 need volume and sequence logic that is environment-specific and is better built as an Azure Monitor or Sentinel analytics rule against Activity Log.

title: Azure Service Principal Activity with python-requests User Agent
id: 8f2c1d64-3b7a-4e51-9c0d-5a6e7f8b1c22
status: experimental
description: Detects Azure Resource Manager or App Service requests carrying the python-requests/2.34.2 user agent associated with Storm-3168 cloud activity. Tune to expected automation in your tenant before alerting.
author: Adverse Trace
date: 2026-09-26
references:

  - https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/
logsource:
  product: azure
  service: activitylogs
detection:
  selection_ua:
    userAgent|contains: 'python-requests/2.34.2'
  condition: selection_ua
falsepositives:

  - Legitimate Python automation using the requests library at this exact version
level: medium

For the destructive and credential-collection phase, alert on the operation names rather than the user agent: Microsoft.Storage/storageAccounts/delete, Microsoft.Storage/storageAccounts/listKeys/action, Microsoft.KeyVault/vaults/delete, Microsoft.Web/sites/delete, Microsoft.Web/serverfarms/delete, and the SQL database delete operations. Correlate any of these against a service principal that has issued more than a threshold number of read operations in the preceding 24 hours.

Microsoft's own Defender for Cloud coverage for this activity, per the source: Defender for App Services (possible data exfiltration detected), Defender for Databases (abnormally large number of rows extracted from an SQL server, unusual volume of data extracted from Azure Cosmos DB, access from an unusual location), Defender for DNS (communication with suspicious domain identified by threat intelligence), Defender for Storage (unusual volume or number of blobs or files extracted, access from a known or suspicious IP address to a sensitive blob container or file share), Defender for Resource Manager (ARM operation from suspicious proxy IP address) and Defender for Key Vaults (unusual operation pattern, high volume of operations, unusual application access).

7. Sources

• Microsoft Security Blog, "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/, published 2026-09-25.

This is the only source supplied for this advisory. Every technical claim in §3, §4, §5 and §6 derives from it, and the JADEPUFFER attribution rests on Microsoft's reference to Sysdig's July 2026 discovery, which we have not seen directly.

8. Adverse Trace position

We assess this as a high-impact cloud identity abuse case with no patchable component, which changes the remediation shape entirely: the fix is credential rotation, role scoping and recovery protection, not a version upgrade. The absence of a CVE and of any CISA KEV entry means this will not appear on vulnerability-management dashboards, and firms that track cloud exposure only through CVE feeds will miss it. The destructive sequence was fast (seven minutes for 100+ deletion attempts) and the recovery safeguards that held were the ones configured independently of the compromised identity, so we treat resource locks, storage deletion protection and backup protection locks as the control that determines whether an incident of this type is recoverable. We flag that the attribution to Storm-3168 and the link to JADEPUFFER are unconfirmed in our reference data, that the whole account is single-sourced to Microsoft, and that the initial access vector is not stated in the source. We will monitor for further reporting that corroborates the actor identity or identifies the credential-compromise vector, and we will issue a follow-up if either emerges. Clients who want to check exposure now should start with the P1 role inventory and credential rotation in §4, because those two actions remove the actor's capability regardless of how the credentials were obtained.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.