Skip to content
Reverse Engineering
Anti-Forensicintermediate

Secure File Wiping

Multi-pass overwriting destroys payload contents to defeat file carving, but metadata, slack, and journal residue often survive to prove a file existed.

Ordinary deletion only unlinks a file: the clusters stay on disk until reused, so a forensic carver can often recover the full contents. Secure wiping defeats that by overwriting the file's data clusters — sometimes multiple passes with zeros, ones, or random bytes — before deletion, so the original payload cannot be carved back. Attackers use it on droppers, staged archives, and credential dumps they no longer need on disk.

The technique succeeds at its narrow goal — the content is usually gone — but it is loud at the metadata layer. Wiping the bytes does not erase the journals, MFT residue, or slack space that record the file's existence, name, size, and timing. A defender pivots from "recover the file" to "prove the file existed and reconstruct what it was."

How it works

Sysinternals SDelete is the canonical tool and the one many actors copy or imitate:

cmd
:: Overwrite file contents (DoD-style passes) then delete
sdelete64.exe -p 3 -nobanner C:\Users\Public\dump.bin

:: Linux equivalent
shred -n 3 -z -u /tmp/payload.bin

On NTFS, overwriting in place is reliable only for non-resident data; small files stored resident in the MFT, copy-on-write behavior, and journaling can leave the original bytes elsewhere. SDelete also overwrites free space to catch previously deleted copies — but each of these operations generates its own journal and $LogFile activity.

Detection & analysis

Static analysis:

  • Inspect the $MFT: a wiped file's MFT record frequently survives (or lingers as a deleted entry) carrying the original filename, size, and $SI/$FN timestamps even when the data clusters are zeroed — enough to identify what was destroyed.
  • Examine file slack and cluster slack: the wiping tool overwrites the logical file length, but the tail of the last cluster and adjacent slack may still hold fragments of the original or of a prior file. Carve these for partial recovery.
  • Look for telltale overwrite patterns — large runs of identical bytes (0x00, 0xFF) or high-entropy random fill in clusters that the MFT marks as belonging to a now-deleted file.

Dynamic analysis:

  • The $UsnJrnl:$J records the sequence cleanly: DATA_OVERWRITE / DATA_TRUNCATION events followed by FILE_DELETE, all naming the file — proving both that the file existed and that it was securely wiped, with timestamps. Sysmon Event ID 1 / 4688 captures the sdelete/shred command line.
  • Recover intact copies from sources the wipe never touched: Volume Shadow Copies, backup snapshots, and pagefile/hiberfil residue if the payload was ever loaded into memory.

Detection rule hint: Alert on execution of sdelete/shred/cipher /w and on a USN pattern of DATA_OVERWRITE immediately preceding FILE_DELETE for the same record — a signature of secure wiping rather than normal deletion. Recovery path: parse the surviving MFT entry for the wiped file's name/size/timestamps, carve adjacent slack, and restore from the most recent shadow copy.

Votes

Comments(0)