Threat reportRansomwareTL-2026-2191
Four Methods for Azure Blob Storage Ransomware: Client-Side Bulk Encryption, CPK, Encryption Scope, and CMK Abuse
Four Methods for Azure Blob Storage Ransomware (TL-2026-2191), also tracked as Holding Blobs for Ransom, is a high-severity ransomware operation, first published 2026-06-15. It is attributed to ALPHV with high confidence, affects Microsoft Azure Blob Storage, maps to 18 MITRE ATT&CK techniques (T1003.006, T1021.006, T1078), and is covered by 9 detection rules and 14 indicators of compromise.
- Severity
- HIGHAssessed severity
- CVEs
- 0None referenced
- Techniques
- 18MITRE ATT&CK
- Actors
- 2ALPHV
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 14Indicators of compromise
Key facts for TL-2026-2191
- Threat ID
- TL-2026-2191
- Also known as
- Holding Blobs for Ransom, Azure Storage Ransomware
- Severity
- HIGH
- Status
- ACTIVE
- Category
- RANSOMWARE
- First published
- Last reviewed
- Attribution
- ALPHV, STORM-0501
- Attribution confidence
- HIGH
- Motivation
- FINANCIAL
- Target sectors
- all sectors using azure blob storage, cloud-hosted enterprises, finance, health, government administration
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 14
Malware and tooling in Four Methods for Azure Blob Storage Ransomware
Malware and tooling: AnyDesk, BlackCat (Windows), BlackCat - S1068, BlackCat/ALPHV, RemCom, Sphynx, AADInternals - S0677, Atera, AzCopy, AzureHound, Evil-WinRM, Impacket - S0357
How Four Methods for Azure Blob Storage Ransomware works
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).
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 techniques used in TL-2026-2191
Credential Access
T1003.006 OS Credential Dumping: DCSync; T1552.001 Unsecured Credentials: Credentials In Files
Lateral Movement
T1021.006 Remote Services: Windows Remote Management
Initial Access
T1078 Valid Accounts; T1078.004 Valid Accounts: Cloud Accounts
Persistence
T1098.001 Account Manipulation: Additional Cloud Credentials
Command and Control
defense-impairment
T1484.002 Domain or Tenant Policy Modification: Trust Modification; T1685 Disable or Modify Tools
Impact
T1485 Data Destruction; T1490 Inhibit System Recovery; T1657 Financial Theft
Discovery
T1526 Cloud Service Discovery; T1580 Cloud Infrastructure Discovery
Collection
Exfiltration
T1537 Transfer Data to Cloud Account; T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage
Privilege Escalation
Affected products and versions in Four Methods for Azure Blob Storage Ransomware
- Microsoft — Azure Blob Storage
Vulnerable versions: All storage accounts with data-plane access, customer-provided encryption keys (CPK), encryption scopes, or customer-managed key (CMK) encryption enabled
Fixed in: N/A -- feature abuse, not a patchable vulnerability; mitigated via Key Vault purge protection, resource locks, immutability policies, and RBAC restriction of encryption control-plane operations - Amazon Web Services — Amazon S3 (Server-Side Encryption with Customer-Provided Keys)
Vulnerable versions: S3 buckets accessible via compromised IAM credentials while SSE-C was supported
Fixed in: AWS deprecated SSE-C in April 2026 following the Codefinger campaign
Remediation for Four Methods for Azure Blob Storage Ransomware
Immediate actions
- Enable Azure Key Vault soft-delete and purge protection (90-day retention) on every vault, and alert on any vault created with a reduced retention period
- Enable Microsoft Defender for Storage and Microsoft Defender for Key Vault on all subscriptions
- Apply resource locks and blob immutability policies to business-critical storage accounts and alert on their removal
- Restrict who can call Microsoft.Storage/storageAccounts/encryptionScopes/write, Microsoft.Storage/storageAccounts/write (encryption.keySource changes), and Microsoft.KeyVault/vaults/(write|delete) via RBAC
Workarounds
- Where CPK/CMK/encryption-scope usage is not a business requirement, restrict or deny the corresponding control-plane permissions at the subscription/management-group level
- Ingest Key Vault resource logs (KeyCreate/KeyDelete) and Azure Activity Log encryptionScopes/storageAccounts write events into the SIEM, since storage resource logs do not record CPK or encryption-scope usage
Longer-term hardening
- Move off long-lived storage account keys and SAS tokens in favor of Azure AD / managed identities with least-privilege, container-scoped RBAC
- Enforce phishing-resistant MFA for every account capable of Entra Global Administrator or storage-account control-plane operations, including synced/non-human identities
- Monitor and restrict multi-tenant app registrations and federated identity credential changes (Add application / Update Application in Entra sign-in and audit logs)
- Harden and monitor Entra Connect / Entra Connect Sync servers as Tier-0 assets; treat DCSync-capable accounts as high-value targets
- Maintain geo-redundant, access-isolated backups (Azure Backup with immutable vaults) that cannot be deleted by the same identity that manages production storage
Timeline of Four Methods for Azure Blob Storage Ransomware
- Sophos X-Ops begins an incident response investigation in which BlackCat/ALPHV's Sphynx encryptor is found to have encrypted 39 Azure Storage accounts via bulk client-side download/encrypt/reupload after the attacker obtained a Base64-encoded Azure storage account key.
- Sophos X-Ops findings on the Sphynx encryptor's Azure Storage capability are publicly reported (BleepingComputer), documenting the LastPass OTP theft, Tamper Protection bypass, and RMM-tool (AnyDesk/Splashtop/Atera) lateral movement that preceded the storage encryption.
- Halcyon discloses the Codefinger group's ransomware campaign abusing AWS S3 Server-Side Encryption with Customer-Provided Keys (SSE-C) -- the first confirmed ransomware use of a cloud provider's native encryption API, and the direct analog Datadog cites for Azure CPK abuse.
- Microsoft publishes reporting on STORM-0501's shift to cloud-based ransomware, detailing the group's abuse of Azure Storage encryption scopes -- creating a Key Vault and key, binding an encryption scope to it, encrypting victim blobs, and deleting the key -- following a hybrid AD-to-Entra-ID compromise chain and extortion over Microsoft Teams.
- Microsoft publishes a broader attack-chain analysis of threat activity targeting Azure Blob Storage across the full ATT&CK kill chain, reinforcing AzCopy, AzureHound, and AADInternals as recurring tooling in Azure Storage compromises.
- AWS deprecates the SSE-C feature that enabled the Codefinger campaign, citing security concerns; Datadog notes Azure continues to support the equivalent CPK feature with no comparable deprecation.
- Datadog Security Labs publishes "Holding blobs for ransom: Four methods for Azure Storage ransomware," consolidating the two confirmed in-the-wild techniques (client-side bulk encryption, encryption-scope abuse) with two novel, not-yet-observed techniques (CPK abuse, CMK abuse including a cross-tenant variant), and releasing Stratus Red Team emulation scenarios for all three server-side variants.
Sources cited for Four Methods for Azure Blob Storage Ransomware
- Holding blobs for ransom: Four methods for Azure Storage ransomware
- BlackCat ransomware hits Azure Storage with Sphynx encryptor
- Storm-0501's evolving techniques lead to cloud-based ransomware
- Storm-0501, Group G1053
- Abusing AWS Native Services: Ransomware Encrypting S3 Buckets with SSE-C
- 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)
- Azure Blob Storage ransomware through Customer-Provided Encryption Keys (Stratus Red Team)
Detection coverage for TL-2026-2191
As of 2026-06-15, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-2191 across Splunk SPL, Microsoft KQL and Sigma, covering 14 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.