Every forensic investigator should know these common antiforensic wipers

Everyone who does digital forensics has seen wipers.

Funny part is attackers and careless admins both sometimes want files gone.

Tools that overwrite/delete files — “wipers” — are common and can hide evidence. SDelete (a Sysinternals tool signed by Microsoft) is famous because it can slip past some whitelisting and looks “legit” on a system. But SDelete is only the tip of the iceberg — there are other tools and each leaves its own marks. Knowing those marks helps you figure out what happened even when the file contents are gone.

------------------------------------------------------------------------------------------------------------

The main players

Here are the common tools investigators run into:

• SDelete (Sysinternals) — overwrites file clusters and free space. Popular because admins use Sysinternals and signatures make it look benign.

• BCWipe (commercial) — very thorough, has features to wipe MFT records, slack space, and other NTFS artifacts. Commercial product; trial exists.

• Eraser (open source) — long-lived tool. Renames files many times (seven by default), overwrites clusters, etc.

• cipher.exe (built-in Windows) — intended for EFS tasks but /w: can wipe free space. Very stealthy because it’s a system binary.

------------------------------------------------------------------------------------------------------------

What these tools try to hide — and what they often fail to hide

Wipers attempt to remove traces of a file. But Windows and NTFS create lots of metadata, logs, and side-files that are harder to fully erase. From an investigator’s point of view, the goal is often just to prove the file existed and that wiping happened — not necessarily to recover the original content.

Commonly left-behind evidence includes:

• USN Journal ($UsnJrnl) entries — rename, delete, data-overwrite, stream changes. Wipers produce many USN events if they rename/overwrite repeatedly.

• NTFS LogFile ($LogFile) — sometimes contains original file names or operations even when MFT entries are gone.

• MFT records ($MFT) — deleted or overwritten MFT entries, reused MFT entry numbers (tools may create new files using same MFT index).

• Prefetch / evidence-of-execution — prefetch files and other execution traces often show the wiper ran.

• ADS (Zone.Identifier) — some tools (e.g., Eraser) leave alternate data streams like Zone.Identifier intact, which can reveal source URLs or original filenames.

• Temporary directories / filenames — e.g., EFSTMPWP left behind by cipher.exe, or ~BCWipe.tmp created by BCWipe.

• Odd timestamps — some wipers zero timestamps (e.g., set to Windows epoch Jan 1, 1601) which looks suspicious.

• Large flurries of rename / DataOverwrite / DataExtend events — pattern of many sequential operations in a short time window.

------------------------------------------------------------------------------------------------------------

Short tool profiles + investigator takeaways

SDelete

• What it does: Overwrites clusters and free space.

• Why it’s sneaky: Signed Sysinternals binary → looks legitimate.

• Look for: USN and MFT evidence of overwrites and prefetch/execution traces for sdelete.exe.

BCWipe

• What it does: Commercial, deep-wiping features (MFT, slack, NTFS $LogFile features advertised).

• Real behavior: Very noisy in NTFS journals — lots of renames, data-overwrite events, and creative file/directory creation to overwrite metadata (e.g., ~BCWipe.tmp, ... filenames).

• Look for: ~BCWipe.tmp directories, massive $UsnJrnl activity in a short time, entries that show rename → overwrite → delete sequences, prefetched BCWipe executables.

Eraser

• What it does: Open-source, renames files repeatedly (7 passes by default), overwrites clusters.

• Quirks: Leaves Zone.Identifier ADS sometimes; renames and timestamp zeroing (Jan 1, 1601) are common.

• Look for: Repeated rename patterns in USN, C (change ) time updated but other times zeroed, leftover ADS pointing to original download URL.

cipher.exe

• What it does: Windows built-in — /w: wipes free space by creating temporary files to overwrite free clusters.

• Quirks: Leaves a directory named EFSTMPWP at the root (observed persisting across reboots in many tests), creates many fil<xxxx>.tmp files while running.

• Look for: EFSTMPWP directory, temporary fil*.tmp files, prefetch entries showing cipher run (and Windows event traces of disk activity).

------------------------------------------------------------------------------------------------------------

Example artifact patterns to search for:

You can use these heuristics in your triage/scripting/search:

• Search USN journal for many sequence-like events (rename → data overwrite → delete) within seconds — suspicious.

• Look for directory names and temporary filenames: ~BCWipe.tmp, BCW, filXXXX.tmp.

• Check prefetch for unexpected executables: sdelete.exe, bcwipe*.pf, eraser*.pf, cipher*.pf.

• Scan for Zone.Identifier ADS on recently deleted files (may include original download URL or filename).

• Find files with timestamps set to zeroed timestamps — a potential sign of Eraser or timestamp wiping.

• Look for an MFT entry number reused by a later file or directory — indicates the original MFT record was targeted and may have been overwritten.

• Parse $LogFile (transaction log) for strange entries that mention original file names even when $MFT shows deletion.

------------------------------------------------------------------------------------------------------------

Investigator workflow

1. Snapshot everything (image the volume) — you need a forensically sound copy.

2. Parse the MFT and USN — timeline representation is crucial. Many wipers create big bursts in the USN journal that are easy to see in a timeline.

3. Check $LogFile and shadow copies — sometimes these hold remnants of filenames or older versions.

4. Search ADS — Zone.Identifier can unexpectedly reveal original source/location.

5. Look for prefetch and execution evidence — often the wiper executable will leave a prefetch or service entry.

6. Remember SSD caveats — wear-leveling and TRIM can make complete overwrites unreliable on SSDs; artifacts can be missing or inconsistent.

7. Correlate with logs — application logs, Windows event logs, and backup logs can confirm when delete/wipe activity occurred.

------------------------------------------------------------------------------------------------------------

Caveats and testing notes (be honest about limits)

• Tests often assume the active file clusters were overwritten — but you can’t always prove every copy was overwritten (especially on SSDs).

• Some wipers advertise wiping certain structures (like $LogFile), but testing showed mixed results — so always verify with artifacts rather than relying on vendor claims.

------------------------------------------------------------------------------------------------------------

Short example: cipher.exe /w:C: — what to expect

If someone runs cipher.exe /w:C: after deleting files:

• You may see EFSTMPWP at C:\ root.

• Temporary fil####.tmp files created and deleted during the run.

• No direct evidence of which files were wiped (cipher writes free space), but you can correlate deletion times from USN/MFT earlier in the timeline to guess what got targeted.

• Prefetch and process execution traces will show cipher.exe ran.

------------------------------------------------------------------------------------------------------------

Wrap-up — final thought

Wipers try to erase content, but they often leave stories. The job of a forensic examiner is to read those stories in metadata, journals, and side-files. Look for patterns — rapid renames, heaps of USN events, leftover temp folders, strange timestamps, MFT reuse, and ADS — and you’ll often reconstruct what happened even when the file is gone.

-------------------------------------Dean---------------------------------------------------------------