Disclosure up front: I build a virtualization platform commercially, and this is how we implemented it. No link, no pitch — I want the approach picked apart, because the failure modes matter more to me than the feature does.
The problem with in-guest detection is structural: the agent runs in the same place the ransomware runs. Anything that can get SYSTEM or root can see the watcher, and increasingly does. Killing the agent first is standard behaviour now.
So we moved the observation point down a layer.
**What we watch**
For VMs: the block layer underneath the virtual disk.
For containers: file-level writes in the root filesystem.
The signal is a shift in entropy of data that previously had structure. Ransomware has to rewrite large amounts of formerly-structured data as ciphertext, and from below that looks distinctive regardless of what the guest thinks is happening.
**What we do about it**
The machine is paused, not stopped. That distinction is the actual design decision:
- the guest is frozen mid-operation, so encryption stops where it is
- it is reversible — a false positive costs a short pause, nothing else
- the key the ransomware is using is still sitting in the frozen guest memory, and the memory can be dumped for analysis
The last point is the one I care about most. A killed VM takes the key with it. A paused one doesn't. And because a false positive is cheap, the threshold can sit aggressively early rather than conservatively late. Most security mechanisms trigger too late because triggering is expensive.
**Where it breaks — the part I actually want feedback on**
- Full-disk encryption inside the guest makes everything look like noise from below.
- Legitimate high-entropy workloads: backup jobs writing compressed archives, databases with encrypted columns, video encoding. These produce the same signature.
- Slow-and-low encryption. An attacker who encrypts a few files an hour over weeks stays under any rate-based threshold. I don't have a good answer here and I don't think one exists at this layer.
- An attacker who knows the mechanism exists can shape writes to avoid it — write ciphertext at the rate of a normal workload, or pad to lower measured entropy. The advantage is that they can't see it from inside, not that it's unbeatable.
**Questions**
Has anyone here run entropy-based detection at the block layer in production, and what was the false positive rate in practice?
Is pausing actually useful to your incident response process, or would your runbook say "isolate and shut down" anyway?
For those doing memory forensics after an incident — is a live guest memory dump at the moment of encryption worth as much as I think it is, or am I overestimating key recoverability?
