Azure Blob Storage Ransomware: Four Storage-Encryption Abuse Methods (BlackCat/ALPHV, STORM-0501)
Azure Blob Storage Ransomware (TL-2026-0810), also tracked as Holding blobs for ransom, is a high-severity ransomware operation, first published 2026-06-15. It is attributed to STORM-0501 with high confidence, affects Microsoft Azure Blob Storage, maps to 15 MITRE ATT&CK techniques (T1078, T1098, T1136), and is covered by 9 detection rules and 16 indicators of compromise.
Key facts for TL-2026-0810
- Threat ID
- TL-2026-0810
- Also known as
- Holding blobs for ransom, Azure Storage encryption ransomware, Cloud-based ransomware
- Severity
- HIGH
- Status
- ACTIVE
- Category
- RANSOMWARE
- First published
- 2026-06-15
- Last reviewed
- 2026-06-15
- Attribution
- STORM-0501
- Attribution confidence
- HIGH
- Motivation
- FINANCIAL
- Target sectors
- government, education, healthcare, manufacturing, technology, enterprise
- Target regions
- North America, Europe, Global
- Detection rules
- 9
- Indicators of compromise
- 16
Malware and tooling in Azure Blob Storage Ransomware
Malware and tooling: Sphynx (BlackCat/ALPHV encryptor), AzCopy, AzureHound, Stratus Red Team
Threat actors abuse native Azure Storage encryption mechanisms to render victim blobs inaccessible and extort ransom without any CVE or malware payload. Datadog Security Labs documents four methods: client-side encryption (used in the wild by BlackCat/ALPHV in 2023), customer-provided encryption keys (CPK), attacker-controlled encryption scopes (used in the wild by STORM-0501), and storage-service encryption with customer-managed keys (CMK), including cross-tenant CMK variants that place the unwrap key in an attacker-controlled Entra tenant.
How Azure Blob Storage Ransomware works
This threat covers a class of cloud-native ransomware that weaponizes Azure Storage's own encryption features rather than deploying a traditional binary encryptor. Because the abuse relies on legitimate Azure REST API operations and headers, there is no CVE to patch; defense is a matter of configuration hardening, least privilege, and log-driven detection.
Method 1 — Client-side encryption: With only storage data-plane permissions (e.g. a compromised storage account access key or SAS token), an actor downloads blobs in bulk (GetBlob), encrypts them locally, and overwrites the originals (PutBlob). No Azure-native encryption feature is required. BlackCat/ALPHV used this approach in 2023 via its Sphynx encryptor against compromised Azure Storage accounts (reported by Sophos X-Ops).
Method 2 — Customer-provided encryption keys (CPK): The actor reuploads blobs supplying their own AES-256 key in HTTP request headers (x-ms-encryption-key, x-ms-encryption-key-sha256, x-ms-encryption-algorithm: AES256). The key never enters the victim tenant, so the data cannot be decrypted without the attacker. No public in-the-wild Azure reporting exists, but it is directly analogous to the AWS SSE-C abuse by the 'Codefinger' actor (Halcyon, January 2025). Critically, Azure resource logs do not record the x-ms-encryption-key-sha256 header, making CPK abuse nearly indistinguishable from normal writes.
Method 3 — Encryption scopes (most prevalent / observed): The actor creates a new Azure Key Vault and key in the victim tenant, creates an encryption scope bound to that key, reuploads blobs specifying x-ms-encryption-scope (or seeds a new container/account with the scope as default and uses CopyBlob), then deletes the key/vault to deny access. STORM-0501 used this technique (Microsoft, August 27 2025) — described as the most widely reported Azure Storage ransomware tactic. Encryption-scope usage on individual blob operations is not logged in storage resource logs, creating a detection gap; control-plane and Key Vault logs are the primary signal.
Method 4 — Storage Service Encryption with Customer-Managed Keys (CMK): A single control-plane PATCH points the storage account's encryption keySource to an attacker-controlled Key Vault key (Microsoft.Keyvault), requiring a SystemAssigned managed identity; deleting that key then makes Azure unable to unwrap its own storage key. This needs no data-plane operations and is the most efficient method. No public in-the-wild reporting yet.
Cross-tenant variants of Methods 3 and 4 host the encryption key in a separate attacker-controlled Entra tenant, linked via a multi-tenant application registration and federated identity credentials (FederatedIdentityCredentials) trusting the victim storage account's managed identity. This defeats Key Vault soft-delete/purge-protection recovery because the key lives outside the victim's control entirely. Soft-delete (90-day default, purge protection auto-enabled for storage-linked vaults) can also be circumvented by setting a 7-day minimum retention before linking and waiting for natural purge.
STORM-0501 more broadly pivots from on-prem Active Directory to Entra ID, abusing Directory Synchronization (Entra Connect) and registering malicious federated domains for persistent backdoor impersonation, using AzureHound/AzureHound-style discovery and AzCopy for mass exfiltration before destruction.
MITRE ATT&CK techniques used in TL-2026-0810
Initial Access
Persistence
T1098 Account Manipulation; T1136 Create Account
Privilege Escalation
T1484 Domain or Tenant Policy Modification
Impact
T1485 Data Destruction; T1486 Data Encrypted for Impact; T1490 Inhibit System Recovery; T1657 Financial Theft
Discovery
T1526 Cloud Service Discovery; T1580 Cloud Infrastructure Discovery
Collection
Exfiltration
T1537 Transfer Data to Cloud Account
Credential Access
defense-impairment
T1578 Modify Cloud Compute Infrastructure; T1685 Disable or Modify Tools
Affected products and versions in Azure Blob Storage Ransomware
- Microsoft — Azure Blob Storage
Vulnerable versions: all tiers supporting encryption (CPK, encryption scopes, CMK) - Microsoft — Azure Key Vault
Vulnerable versions: used as attacker key store for encryption scopes / CMK - Microsoft — Microsoft Entra ID
Vulnerable versions: multi-tenant app + FederatedIdentityCredentials enable cross-tenant CMK
Remediation for Azure Blob Storage Ransomware
Immediate actions
- Audit Azure Activity Log for Microsoft.Storage/storageAccounts/encryptionScopes/write, Microsoft.KeyVault/vaults/write and /delete, and Microsoft.Authorization/roleAssignments/write events
- Alert on storage account encryption keySource changes to Microsoft.Keyvault, especially pointing to unfamiliar or external-tenant Key Vaults
- Rotate and minimize storage account access keys and SAS tokens; revoke any long-lived credentials
- Review Entra ID for new multi-tenant app registrations and FederatedIdentityCredentials added to storage managed identities
- Hunt for rapid Key Vault KeyCreate followed by KeyDelete cycles
Workarounds
- Enable resource locks (CanNotDelete) on critical storage accounts and Key Vaults
- Enable blob immutability (time-based or legal-hold WORM) policies on critical containers
- Enable blob versioning and soft-delete on storage accounts and blobs
- Enforce purge protection and extended soft-delete retention on all Key Vaults
- Disable storage account public network access and shared-key authorization where feasible
Longer-term hardening
- Enable Microsoft Defender for Storage (formerly Azure Defender for Storage) for behavioral detection
- Enforce least privilege; remove standing Owner/Contributor and Storage Account Key Operator roles
- Prefer short-lived Entra ID token-based access over storage access keys and SAS tokens
- Deploy immutable WORM backups and cross-region/cross-account copies isolated from production identities
- Monitor Entra Connect / Directory Synchronization Account abuse and federated domain registrations
Weaknesses (CWE) in Azure Blob Storage Ransomware
CWE-284, CWE-269, CWE-522, CWE-668, CWE-863
Timeline of Azure Blob Storage Ransomware
- Sophos X-Ops incident responders discover a new BlackCat/ALPHV 'Sphynx' encryptor variant — adding support for custom credentials to target Azure Storage — during a breach investigation.
- Sophos X-Ops publicly reports BlackCat/ALPHV using the Sphynx encryptor with stolen Microsoft/Azure credentials to download, client-side encrypt, and overwrite blobs across 39 Azure Storage accounts — the first documented in-the-wild Azure Storage ransomware (Method 1).
- The U.S. DOJ/FBI announce a disruption operation against ALPHV/BlackCat, seizing infrastructure and releasing a decryption tool to victims.
- ALPHV/BlackCat conducts an exit scam and shuts down its operation following the Change Healthcare ransom, fragmenting affiliates into successor operations.
- Halcyon reports the 'Codefinger' actor abusing AWS SSE-C (customer-provided keys) to ransom S3 buckets — the direct analog to Azure CPK abuse (Method 2).
- Microsoft publishes its Storm-0501 cloud-based ransomware report: the actor creates Key Vaults/encryption scopes in victim tenants and deletes keys to render Azure Storage data inaccessible (Method 3).
- AWS announces deprecation of SSE-C (effective April 2026) citing low usage and security concerns; Azure continues full CPK support.
- AWS's SSE-C deprecation deadline: SSE-C disabled by default for new and select existing buckets; Azure customer-provided encryption keys remain supported and abusable.
- Datadog Security Labs publishes 'Holding blobs for ransom: Four methods for Azure Storage ransomware,' documenting all four methods, cross-tenant CMK variants, and storage-log gaps disclosed to Microsoft.
Sources cited for Azure Blob Storage Ransomware
- Holding blobs for ransom: Four methods for Azure Storage ransomware
- Storm-0501's evolving techniques lead to cloud-based ransomware
- Storm-0501 hackers shift to ransomware attacks in the cloud
- Microsoft details Storm-0501's focus on ransomware in the cloud
- Codefinger: Abusing AWS native services SSE-C for ransomware
- Stratus Red Team — cloud attack emulation (Azure ransomware techniques)
- Azure Storage encryption for data at rest (CPK, encryption scopes, CMK)
Threats related to Azure Blob Storage Ransomware
- Former Ransomware Negotiator Angelo Martino Sentenced to 70 Months for Colluding with BlackCat/ALPHV Operators to Extort $75.3M from Five Victims
- Cloud Bucket Hijacking — Global Namespace Risk: Silent Data-Stream Redirection via Statically-Named Storage Buckets (AWS / Google Cloud / Azure)
- Human-Operated Ransomware via GPO Abuse — Domain-Wide Encryption Through Group Policy Weaponization
- Global Namespace Bucket Hijacking: Universal Cloud Data Exfiltration via Storage Bucket Name Reclamation (AWS S3 / GCP Cloud Storage / Azure Blob)
- Lone Attacker Uses AI-Assisted Workflows to Breach Large AWS Cloud Environment in 72 Hours (Sygnia Investigation)
Detection coverage for TL-2026-0810
As of 2026-06-15, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0810 across Splunk SPL, Microsoft KQL and Sigma, covering 16 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.