Researchers Detail Four Methods for Ransoming Azure Blob Storage
Summary
Datadog Security Labs details four ways attackers could make Azure Blob data inaccessible, including two methods reported in the wild. The article explains permissions, logging gaps, Key Vault protections, and defensive monitoring.
Key points
- Client-side encryption and encryption scopes have been reported in Azure Storage ransomware attacks; customer-provided keys and service encryption with customer-managed keys have not been publicly observed.
- Client-side encryption, customer-provided keys, and encryption scopes can involve downloading and reuploading blobs; customer-provided keys can leave data inaccessible because the key is not stored in the victim's Azure environment.
- Encryption scopes can encrypt blobs using a Key Vault key, which attackers may delete to block access; the method requires both control-plane and data-plane permissions.
- Changing storage service encryption to use a customer-managed key could make data inaccessible through a single API call without storage data-plane permissions, but the article reports no in-the-wild use.
- Azure logs do not clearly distinguish PutBlob requests using customer-provided keys or encryption scopes from ordinary uploads, limiting detection.
- The article describes Key Vault soft-delete protections and a cross-tenant key approach that could prevent victims from recovering deleted keys.
- Recommended defenses include Azure Defender for Storage, resource locks, immutability policies, versioning, limiting long-term credentials, and monitoring unusual blob activity and Key Vault or CMK changes.
Article Details
- Attack Vectors
- Client-side encryption: download victim blobs in bulk, encrypt them with Sphynx encryptor, and reupload them to overwrite the originals; a compromised storage account access key can provide the required data-plane access.
- Customer-provided keys: reupload blobs encrypted with an attacker-known customer-provided key, making them inaccessible to the victim without that key. The article says this method has not been observed in public reporting for Azure.
- Encryption scopes: create a Key Vault key and storage encryption scope, then use the scope to encrypt victim blobs; deleting the key or vault can make the data inaccessible. The article reports this method exploited in the wild and attributes reported activity to STORM-0501.
- Service encryption with customer-managed keys: configure storage service encryption to use a customer-managed Key Vault key, then delete the key or vault to prevent Azure from unwrapping its managed key. The article says this method has not been publicly reported in the wild.
- Cross-tenant customer-managed key abuse: configure the victim storage account to use a key in an attacker-controlled Entra tenant, then delete that key or remove the service principal so the victim cannot recover the key.
- Key Vault protections may be circumvented by setting soft-delete retention to the seven-day minimum before linking the vault, or by keeping the key in an attacker-controlled tenant.
- Defensive Notes
- Enable Azure Defender for Storage, resource locks, immutability policies, and versioning to detect or prevent storage data from being destroyed or overwritten.
- Where possible, avoid long-term storage access keys and SAS tokens, which can provide persistent data-plane access without control-plane permissions.
- Monitor for unusual blob upload and download patterns and rapid creation, use, or deletion of Key Vault keys.
- Flag customer-managed key configurations that point to Key Vaults in unfamiliar or external tenants.
- Monitor for deletion of storage locks and container immutability policies, and for storage account updates that disable immutability.
- Review Azure Activity, Key Vault, and Entra event logs; the article notes that customer-provided-key and encryption-scope use may not be distinguishable from ordinary PutBlob requests in storage resource logs.
MITRE ATT&CK
Threat Actors
BlackCatSophos X-Ops reported that the ransomware gang deployed ransomware against victim Azure Storage accounts using Sphynx encryptor.CodefingerHalcyon reported that this named threat actor conducted ransomware activity abusing AWS S3 customer-provided keys; the article discusses a similar Azure feature.STORM-0501Microsoft reporting described this tracked actor abusing Azure encryption scopes to pursue ransomware payments from victims.
Malware
Products
AWS S3In January 2025, Halcyon reported that a threat actor named Codefinger was conducting a ransomware campaign by abusing the server-side encryption with customer-provided keys (SSE-C) of AWS S3.Azure Blob StorageTo date, the majority of research on cloud storage ransomware has focused on the abuse of AWS's S3, with a comparatively paltry focus on Azure Blob Storage.Azure Defender for StorageEnable Azure Defender for Storage for threat detection across storage accounts, and harden them with resource locks, immutability policies, and versioning to prevent data from being destroyed or overwritten.Azure Key VaultAttacker creates a new Azure Key Vault in the victim tenantAzure StorageThis post will explore four vectors for threat actors to abuse Azure Storage to maliciously encrypt victim blobs, including step-by-step explanations and event codes for detection.Entraway to evade these protections would be for the attacker to create a Key Vault in an attacker-controlled Entra tenant, and implement cross-tenant CMK encryption on the victim storage account using the method described