Data destruction via drive formatting, file modification, and file deletion is a critical element of an organization's ability to rapidly recover from a breach. Perhaps the attacker's signature can be detected and prevented from executing again on the org's hosts, but if the data is corrupted, rapid recovery (which can be daunting even with clean backups) is impossible.

Supposedly, cold-storage backups are often not logistically feasible for large corporations.

One solution I'm interested for this problem is hardware-level SATA monitoring and interception. It was only when looking for books on firmware development that I happened upon documentation of the US Department of Justice actually trying something like this. However, this evaluation only appears to test enforcement of effectively read-only drives.

This specification identifies the following top-level tool requirements:

• A hardware write block (HWB) device shall not transmit a command to a protected storage device that modifies the data on the storage device.

• An HWB device shall return the data requested by a read operation.

• An HWB device shall return without modification any access-significant information requested from the drive.

• Any error condition reported by the storage device to the HWB device shall be reported to the host.

The solution I imagine is more dynamic. Intercept all SATA signal and in the following cases:

  • attempts to reformat a populated drive
  • attempts to delete a large number of files
  • attempts to modify a large number of files
  • attempts to modify a moderate number of files with high entropy data

... the external hardware monitor reach out to a user-defined 2FA method for confirmation (via some encrypted tunnel or local radio communication, certainly not via the host's network card) before passing the commands forward

As a safety-net, the device would, before passing any deletion or overwrite command forward, move the target data to an on-board (the monitoring device) storage card which overwrites in a cyclic manner. In the case that the modified files end up becoming part of a larger malicious batch of operation which is halted by the 2FA process, those corrupted files will be safely accessible on the cache card.

Has such technology been tried? Did it work or not? What logistical or technical flaws in such a scheme would get in the way? Of course, installation is the obvious logistical challenge, however, I imagine corporations hit by major ransomware attacks might be willing to spend a little extra on such tech being built into some security-oriented brand of drives.

1 Answer 1


I would assume that a more intelligent approach at the SATA level than simply blocking any writes is currently not feasible to actually protect against ransomware. Anything else would require to understand what is actually happening, i.e understand what a specific write access really means. This would mean to somehow derive all the complexity of OS and application behavior from fairly simple SATA level commands.

It might be though to get at least some understanding at the hardware level about what is happening. This might be sufficient for detecting possibly anomal behavior, which might lead to a faster detection of problems or for better incidence response later. I doubt that the false positive rate or such heuristics or ML models will be low enough to be acceptable for active prevention though, since for this use case practically no false positives at all are acceptable.

  • I would argue that the concept of not blocking, but externally caching in 99% of "suspicious" cases would allow very nearly zero false positive outcomes. The system would only need to make an overt action in rare cases where extreme things are happening, far from normal use. A centralized external cache could store a lot of file history for many hosts. Interested in engineering it, testing the false positive rate in a lab, and publishing the results good or bad.
    – J.Todd
    Aug 18, 2021 at 21:11
  • Latency of the interactions could be a problem for usability or even cause bugs in Windows.
    – J.Todd
    Aug 18, 2021 at 21:22
  • @J.Todd: Enabling externally caching would immediately slow down the device considerably. Disabling it again would require some reliable decision that it was actually a false positive - i.e. probably some human intervention which should not be done lightly. I would also assume that because of the greatly reduced visibility at the hardware level the false positives will be fairly common - which given the cost of a false positive make active prevention infeasible. One might try to tune it for less false positives but this will result in more false negatives, i.e. missing more real problems. Aug 18, 2021 at 21:23
  • I have an idea to eliminate both of your performance and false positive considerations at the expense of doubling storage cost. Let's say for national security purposes, a nation-state entity decides it wants to bolster security (decrease recovery time) of privately owned utilities at no cost to the companies. So cost is a non-factor. Every drive is paired with a twin of equal capacity. A splitter clones the signal of every write operation to the twin. The write scheme for the twin is looped recording, only overwriting the oldest written data, like a security camera. (1/2)
    – J.Todd
    Aug 18, 2021 at 21:48
  • (2/2) Now for any loss, the entire drive's capacity would have to occur in write operations before the defender notices and freezes the external cache for a recovery & response effort. Formatting the drive or writing its entire contents size (looping the entire cache) in a small time period (user configured, lets say 7 days default) are the only events which trigger a 2FA event for the network admin.
    – J.Todd
    Aug 18, 2021 at 21:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .