# Holding blobs for ransom: Four methods for Azure Storage ransomware

Four Azure Blob Storage ransomware techniques encrypt victim blobs via client-side encryption, CPK, encryption scopes, or CMK deletion; two observed in the wild.

- Payout: Real-world hack
- Program: Microsoft
- Analysis by: Datadog Security Labs
- Disclosed: 2026-06-15
- Write-up quality: 7/10
- Original: https://securitylabs.datadoghq.com/articles/azure-blob-storage-ransomware-four-methods/
- Library page: https://bugbountylibrary.com/r/blog%3Asecuritylabs-datadoghq-com-articles-azure-blob-storage-ransomware-four-methods
- Tags: area:cloud domain:cloud impact:data-leak impact:dos impact:integrity kind:incident platform:threat-intel tech:azure technique:source-review vuln:misconfiguration

**Target:** Azure Storage accounts, Key Vault, encryption scopes, CMK
**Root cause:** Azure Storage supports multiple encryption mechanisms (client-side, CPK, encryption scopes, CMK) that attackers with data-plane or control-plane access can abuse to render blobs inaccessible, and CPK/encryption-scope usage is not logged in storage resource logs.
**Steps:**
1. Method 1: bulk `GetBlob` download, encrypt locally, `PutBlob` overwrite (BlackCat/Sphynx).
2. Method 2: reupload blobs with `x-ms-encryption-key`, `x-ms-encryption-key-sha256`, `x-ms-encryption-algorithm: AES256` headers via `PutBlob`.
3. Method 3: create Key Vault key, create encryption scope, reupload blobs with `x-ms-encryption-scope` header, delete key/vault.
4. Method 4: `PATCH` storage account with `keySource: Microsoft.Keyvault` pointing at attacker key, then delete key.
5. Evade soft-delete: set soft-delete retention policy to its minimum value of seven days, or use cross-tenant CMK with attacker-controlled Entra tenant and federated credentials.
**How found:** Author compared Azure encryption features against AWS S3 ransomware research, noted logging gaps for CPK and encryption scopes, and reasoned through how each feature could be abused for extortion.
**Exploitation:** Attacker with storage access key (method 1/2) or control-plane privileges (method 3/4) encrypts blobs with attacker-held keys, deletes keys, and demands ransom; cross-tenant CMK prevents victim recovery.
**Escalation:** Cross-tenant CMK via multi-tenant app, federated credentials, and attacker-tenant Key Vault bypasses soft-delete/purge protection entirely.
**Insight:** CPK and encryption-scope PutBlob requests log identically to a "normal" PutBlob request, so detection must rely on control-plane events (encryptionScopes/write, KeyCreate/KeyDelete) and cross-tenant CMK URIs rather than data-plane logs.

## Proof of concept (copied exactly from the original report)

**CPK-encrypted blob upload via curl**

```
curl -X PUT "https://${ACCOUNT}.blob.core.windows.net/${CONTAINER}/${BLOB}" \
 -H "Authorization: Bearer ${ACCESS_TOKEN}" \
 -H "x-ms-version: 2025-01-05" \
 -H "x-ms-date: $(date -u +'%a, %d %b %Y %H:%M:%S GMT')" \
 -H "x-ms-blob-type: BlockBlob" \
 -H "Content-Type: text/plain" \
 -H "Content-Length: 13" \
 -H "x-ms-encryption-key: ${ENCRYPTION_KEY}" \
 -H "x-ms-encryption-key-sha256: ${ENCRYPTION_KEY_SHA256}" \
 -H "x-ms-encryption-algorithm: AES256" \
 --data-binary "Hello, world!"
```