Ransomware that never runs on any of your machines
Datadog sets out four ways an attacker who already has access to an Azure subscription can encrypt a victim’s stored data without ever deploying ransomware to a host. Two of the four are not theoretical: the first is the route used in a BlackCat deployment in 2023, and the third documents STORM-0501 activity. The other two are researcher demonstrations that Datadog says have not been seen in public reporting. The shape they share is that the attacker turns the platform’s own encryption features against the data, so from the storage service’s point of view every operation is legitimate and authorised.
What worked
Azure’s defaults do some real work and Datadog says so. Microsoft requires soft-delete on any key vault used for customer-managed key encryption of storage, which leaves a window in which a deleted key can be recovered rather than a permanent loss.
What failed
The logs, which is the finding that matters to anybody who would have to investigate this. Datadog is specific twice. Azure resource logs "do not log the x-ms-encryption-key-sha256 header, making usage of CPKs difficult to detect", and "the usage of encryption scopes in storage operations is not logged in storage resource logs". Two of the four encryption routes leave no trace in the logs you would reach for first.
And the protection that does exist can be shortened rather than defeated. The soft-delete retention that would have given you 90 days can be set by the attacker to its minimum of seven before the key vault is linked to the storage account. Ninety days is a recovery window. Seven days is a long weekend.
The number
7 days
the minimum soft-delete retention an attacker can set before linking a key vault to the storage account, in place of the 90 days the default would otherwise have given you to recover the key.
What to do instead
Turn the recovery controls on before you need them, because not one of them can be applied afterwards. Versioning, immutability policies and resource locks on storage, and Azure Defender for Storage for detection. Data that is already encrypted cannot be retroactively versioned.
Then close the logging gap by watching the control plane instead of the data plane. If customer-provided keys and encryption scopes do not appear in storage logs, the observable events are elsewhere: a key vault created and a key generated and then deleted in quick succession, a customer-managed key configuration pointing at a tenant that is not yours, a soft-delete retention being shortened, protection features being removed. Datadog lists each of those, and they are the detections that survive the gap.
Then take long-lived credentials out of the picture. This is an identity attack with a storage outcome, and all four methods begin from access somebody already held. Short-lived, narrowly scoped tokens is the control at the real entry point rather than at the visible one.
And rehearse the recovery. A cloud storage account is exactly as restorable as the versioning and immutability you configured in advance, and nobody wants to find out which they have during the incident.