# Four Methods for Azure Blob Storage Ransomware: Client-Side Bulk Encryption, CPK, Encryption Scope, and CMK Abuse

> Datadog Security Labs documents four distinct ways attackers can render Azure Blob Storage data unrecoverable for ransom: bulk download/local-encryption/reupload, abuse of customer-provided encryption keys (CPK), abuse of Azure encryption scopes backed by Key Vault, and abuse of storage-account encryption with customer-managed keys (CMK) followed by key deletion. Two of the four are already confirmed in the wild: client-side bulk encryption by BlackCat/ALPHV's Sphynx encryptor (2023, 39 storage accounts) and encryption-scope abuse by STORM-0501 (reported by Microsoft, August 2025).

- **Published:** 2026-06-15T00:00:00Z
- **Last reviewed:** 2026-06-15T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-2191
- **ID:** TL-2026-2191
- **Severity:** HIGH
- **Category:** RANSOMWARE
- **Status:** ACTIVE
- **Actor:** ALPHV
- **Detections:** 9 · **IOCs:** 14 (full data via the Threadlinqs MCP server — Purple tier)

## Description

Datadog Security Labs' "Holding blobs for ransom: Four methods for Azure Storage ransomware" (published 2026-06-15) catalogs four techniques an attacker with sufficient Azure permissions can use to make Blob Storage data permanently inaccessible without paying for a decryption key, none of which require exploiting a software vulnerability -- all four abuse legitimate Azure Storage encryption features.

Method 1 (client-side bulk encryption) is the cloud analog of conventional ransomware: the attacker uses valid data-plane credentials to GetBlob every object in a container, encrypt it locally, and PutBlob the ciphertext back over the original, exactly as BlackCat/ALPHV's Sphynx encryptor did against 39 Azure Storage accounts in a March 2023 intrusion (publicly reported by Sophos X-Ops / BleepingComputer, 2023-09-16). Sophos found the attackers reached the victim's Azure key by first stealing a LastPass-vaulted OTP via a malicious Chrome extension, using it to disable Sophos Central Tamper Protection, then pivoting through AnyDesk/Splashtop/Atera RMM sessions and the Sphynx-embedded Remcom/Impacket tooling to reach a Base64-encoded Azure storage account key.

Method 2 (CPK abuse) uses PutBlob with attacker-supplied AES-256 keys in the x-ms-encryption-key / x-ms-encryption-key-sha256 / x-ms-encryption-algorithm headers; because the key never touches the victim's environment and Azure resource logs do not record the key-hash header, this method is both irrecoverable and effectively invisible in current SIEM telemetry. It has not yet been observed in the wild, but Datadog explicitly frames it as the Azure sibling of the Codefinger group's confirmed abuse of AWS S3 Server-Side Encryption with Customer-Provided Keys (SSE-C), reported by Halcyon on 2025-01-13 -- the first confirmed ransomware use of a cloud provider's own encryption API rather than malware.

Method 3 (encryption-scope abuse) is Datadog's characterization of the technique Microsoft attributed to STORM-0501 in its 2025-08-27 blog on the group's shift to cloud-native ransomware: create a Key Vault and key in the victim tenant, create a storage-account encryption scope bound to that key, encrypt the target blobs by re-uploading them with the x-ms-encryption-scope header (or setting the scope as the container default), then delete the key/vault. In the reported incident this followed a long hybrid-AD-to-Entra-ID chain -- Evil-WinRM and DCSync against an exposed Entra Connect Sync server, AzureHound-mapped privilege-escalation path to a non-MFA'd synced Global Administrator, an AADInternals-forged federated-domain backdoor for persistent SAML impersonation, Microsoft.Authorization/elevateAccess/action to self-grant User Access Administrator, AzCopy-driven exfiltration after exposing storage accounts to the internet, and mass deletion of snapshots, restore points, backup vault containers, resource locks, and immutability policies before the encryption-scope key was created and deleted. STORM-0501 then extorted the victim over compromised Microsoft Teams accounts. Microsoft's 90-day Key Vault soft-delete/purge-protection default blocked outright data loss in the reported case, which Datadog notes attackers can defeat by pre-configuring the vault's minimum seven-day retention before linking it to storage.

Method 4 (CMK abuse) is the most efficient of the four and requires no data-plane access at all: a single PATCH to Microsoft.Storage/storageAccounts pointing the account's encryption keySource at an attacker-controlled Key Vault key re-wraps the account's Azure-managed key, and deleting that key blocks unwrapping for the whole account in one call rather than a bulk re-encryption operation. Datadog additionally describes an evasion refinement -- cross-tenant CMK abuse -- where the attacker creates the Key Vault in their own Entra tenant and establishes a multi-tenant app registration / workload-identity federation trust so the victim's soft-delete protections in their own tenant never come into play, since the key never resided there. This variant requires Application Administrator or Global Administrator in both tenants and is visible only via Entra sign-in/audit-log Add application / Update Application events with FederatedIdentityCredentials changes. Neither Method 2 nor Method 4 has been reported as used in the wild as of the source article; Datadog notes AWS deprecated the SSE-C feature that enabled Codefinger's attack in April 2026, but Azure continues to support CPK.

Datadog's own Stratus Red Team open-source attack-emulation project ships purple-team scenarios for the encryption-scope, CPK, and CMK/vault-deletion variants so defenders can validate detections without touching production data.

## MITRE ATT&CK

- T1078 Valid Accounts
- T1078.004 Valid Accounts: Cloud Accounts
- T1098.001 Account Manipulation: Additional Cloud Credentials
- T1484.002 Domain or Tenant Policy Modification: Trust Modification
- T1548 Abuse Elevation Control Mechanism
- T1685 Disable or Modify Tools
- T1003.006 OS Credential Dumping: DCSync
- T1552.001 Unsecured Credentials: Credentials In Files
- T1580 Cloud Infrastructure Discovery
- T1526 Cloud Service Discovery
- T1021.006 Remote Services: Windows Remote Management
- T1219 Remote Access Tools
- T1530 Data from Cloud Storage
- T1537 Transfer Data to Cloud Account
- T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage
- T1485 Data Destruction
- T1490 Inhibit System Recovery
- T1657 Financial Theft

## Sources

- [Holding blobs for ransom: Four methods for Azure Storage ransomware](https://securitylabs.datadoghq.com/articles/azure-blob-storage-ransomware-four-methods/)
- [BlackCat ransomware hits Azure Storage with Sphynx encryptor](https://www.bleepingcomputer.com/news/security/blackcat-ransomware-hits-azure-storage-with-sphynx-encryptor/)
- [Storm-0501's evolving techniques lead to cloud-based ransomware](https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/)
- [Storm-0501, Group G1053](https://attack.mitre.org/groups/G1053/)
- [Abusing AWS Native Services: Ransomware Encrypting S3 Buckets with SSE-C](https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c)
- [Inside the attack chain: Threat activity targeting Azure Blob Storage](https://www.microsoft.com/en-us/security/blog/2025/10/20/inside-the-attack-chain-threat-activity-targeting-azure-blob-storage/)
- [Azure Blob Storage ransomware through Encryption Scope using client-managed Key Vault key (Stratus Red Team)](https://stratus-red-team.cloud/attack-techniques/azure/azure.impact.blob-ransomware-client-encryption-scope/)
- [Azure Blob Storage ransomware through Customer-Provided Encryption Keys (Stratus Red Team)](https://stratus-red-team.cloud/attack-techniques/azure/azure.impact.blob-ransomware-cpek/)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-2191