For a long time, the standard mental image of a disk wiper was simple: overwrite the MBR, make the machine unbootable, and let the damage speak for itself. For DFIR teams, that model also implied a relatively clear workflow: verify partition damage, test whether the volume layout can be reconstructed, and move quickly to recovery or carving. That picture is still useful, but it no longer describes the whole class very well.

cover

Modern wipers do not always stop at boot disruption. Some go after GPT metadata, some parse NTFS structures, some rely on signed drivers to reach the disk through a more trusted path, and some skip low-level disk tricks entirely in favor of fast cross-platform file destruction. That distinction matters in DFIR and incident response because the triage path, the telemetry you need, and the recovery options change with each step. For analysts, a basic static malware analysis workflow is often enough to tell those categories apart early. Looking at the underlying disk techniques separately makes the progression easier to follow.

It started with sector zero

The easiest way to understand the evolution is to start from the oldest and simplest target.

On legacy BIOS systems, LBA 0 contains the Master Boot Record, a 512-byte sector with boot code and a small partition table. On GPT disks, sector 0 usually contains only a protective MBR for backward compatibility, while the real GPT header and partition entries start at LBA 1 and a backup copy is stored at the end of the disk. For a wiper, that distinction matters: damaging sector 0 alone is often enough to stop booting, but not always enough to prevent later recovery.

Several Windows wipers have used direct raw-disk access from user mode. Opening \\.\PhysicalDrive0 with CreateFile and writing to it with WriteFile is enough to corrupt boot or partition data if the process has the required privileges. WhisperGate is a clear example: its first stage overwrote the MBR with a fake ransom note, while the second stage corrupted files. The combination made the system look like ransomware even though the operation was destructive from the start.

mbr vs gpt

The weakness of an MBR-only approach is just as important as its simplicity: it damages discovery, not necessarily content. Much of the file data may still remain on the underlying media, and tools such as TestDisk or forensic suites can sometimes reconstruct enough partition information to recover part of the volume. In those cases, traditional file carving can still recover fragments that were never actually overwritten. For an IR team, that means the difference between a destructive event that is operationally serious and one that is also a near-total data loss scenario.

Then the filesystem became fair game

Once defenders and investigators understood the limits of MBR-only wiping, attackers had an obvious next move: go after the structures that make modern disks recoverable in the first place. CaddyWiper is a good example. Instead of relying only on raw writes, it used DeviceIoControl with IOCTL_DISK_SET_DRIVE_LAYOUT_EX to corrupt partition layout metadata. That approach can affect both the main GPT structures and the backup metadata, which makes simple partition reconstruction harder.

The next step was to move beyond partition metadata and attack filesystem metadata as well. On NTFS, the central structure is the Master File Table, or $MFT. Every file and directory is represented there, along with the data runs that map logical files to physical clusters. If the partition layout can be rebuilt but the MFT is badly corrupted, recovery falls back to carving and partial reconstruction. This is also why MFT anomalies are often so useful during forensic triage.

SentinelOne’s analysis of HermeticWiper showed exactly that broader approach. The malware corrupted MBR and partition data, parsed NTFS structures, and interacted with MFT-related metadata instead of stopping at boot disruption. At that point, recovering partition geometry alone was no longer enough to restore normal access to the filesystem. In practical DFIR terms, the case shifts from partition reconstruction to filesystem-level damage assessment.

Then came the driver shortcut

Even that was not the end of the story. User-mode wiping still leaves defenders some visibility on API calls and raw-disk access. That is one reason destructive malware increasingly relies on signed drivers and kernel-adjacent disk operations.

This is the logic behind Bring Your Own Vulnerable Driver, or BYOVD. The attacker does not need to write a custom kernel driver from scratch. Instead, after obtaining sufficient privileges, they load a legitimate signed driver that exposes dangerous functionality or contains exploitable flaws, then use it as a proxy to reach the disk from a more trusted execution path. For responders, this shifts attention toward service creation events, driver loads, device access patterns, and kernel-adjacent telemetry that many environments still collect poorly.

HermeticWiper used that model by deploying an EaseUS Partition Master driver. SentinelOne and CrowdStrike both documented the use of the \\.\EPMNTDRV\%u device path to reach physical drives through that driver rather than through ordinary filesystem operations. In practice, the malware was no longer asking Windows nicely for raw-disk access; it was borrowing a trusted component that already had it.

The broader trend is measurable. Research presented at NDSS 2026 analyzed 8,779 malware samples that loaded 773 distinct signed drivers and led to the disclosure of seven previously unknown vulnerable drivers. BYOVD is no longer a niche technique associated only with a few high-profile campaigns, and the same pattern appears in tools built specifically to neutralize endpoint protection, as in the case of Terminator.

A related example comes from DriveSlayer, which used FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_MOVE_FILE to fragment data before wiping it. These are legitimate IOCTLs intended for storage management. In a destructive workflow, they can be repurposed to make later recovery more time-consuming and less complete.

Complexity was not the only path forward

One of the more interesting developments is that the story does not end with ever more elaborate low-level sabotage. In several cases, the trend moves in the opposite direction: less finesse at disk level, more operational speed, broader platform coverage.

Unit 42’s March 2026 review of Iranian-linked activity describes a move away from bespoke wiper binaries in some operations and toward abuse of management planes and identity infrastructure. In parallel, families such as BiBi, Hatef, and Hamsa show the continued value of simpler file-level destruction. Instead of touching partition tables or NTFS internals, these samples or scripts recursively enumerate files and overwrite them with fixed-size blocks of junk or random data.

That approach is less complete than carefully targeting disk structures, but it is easier to port and faster to deploy across mixed Windows and Linux estates. A 4 KB write size, for example, often aligns reasonably well with common filesystem cluster or block sizes, which helps throughput without needing much sophistication. On Linux, a shell script that walks directories and overwrites files can be enough to cause serious damage without any driver loading or Windows-specific logic.

File-level wiping can leave more metadata behind than raw-sector destruction, but it reduces complexity and broadens reach. For an attacker who already has administrative control and only needs a few minutes to break operations, that is often a perfectly acceptable trade-off. For IR teams, it also means that endpoint, EDR, and file activity telemetry may matter more than disk forensics alone.

What this means for defenders

From a forensic perspective, each of these techniques closes a different recovery path. If only the MBR is damaged, analysts may still recover partition boundaries. If GPT metadata is also destroyed, the reconstruction work becomes harder. If NTFS metadata is corrupted as well, the investigation often falls back to carving. If the file contents themselves have already been overwritten across the estate, even carving may produce little. The important point is that every step down this chain removes an option that might have existed one generation earlier, which is exactly why scoping the wiping method early in triage matters.

defenders

For defenders, that means response cannot start at the moment of destruction. Backup architecture matters, especially when the same management plane can be used both to administer devices and to wipe them. Driver-loading telemetry matters because signed third-party drivers remain a recurring abuse path. Low-level disk access matters because legitimate processes rarely open \\.\PhysicalDrive0 or issue partition-layout IOCTLs without a clear administrative reason. On live systems, artifacts such as the USN Journal can still help reconstruct what happened before the wipe completed, assuming the attacker did not corrupt those records first. In mature IR workflows, these signals should drive containment and scoping decisions before the team spends time on recovery attempts that the wiping method has already made unrealistic.

Once a wiper reaches raw disk structures, the options for recovery narrow quickly. Prevention, segregation of administrative control, and restore testing usually matter more than any post-event attempt to reconstruct a destroyed volume.