NTFS anti-forensics: attacker tactics on the MFT

Short answer: Anti-forensic techniques on NTFS aim to hide what a file is, when it was touched, or that it ever existed. None of the common techniques are clean — each one leaves a different artifact in $MFT, $UsnJrnl, $LogFile, or VSS snapshots. This post catalogs the techniques and the giveaways that defeat them.

Timestomping

The classic. Tools like SetMACE, timestomp, and built-in PowerShell one-liners call SetFileTime or write $STANDARD_INFORMATION directly to make a file look older or newer than it is.

What it leaves behind:

• $STANDARD_INFORMATION and $FILE_NAME timestamps diverge — SetFileTime only updates SI. See the four MFT timestamps.
• Sub-second precision is often zeroed. Natural Windows activity leaves fractional seconds; many timestomping tools round to the second.
• A $STANDARD_INFORMATION created time older than $FILE_NAME created is impossible — files cannot exist before they are named.

How to spot it: Parse $MFT and flag every record where SI and FN disagree by more than a few seconds, or where SI predates FN at all. The browser parser on this site exposes both timestamp sets per record.

Alternate data streams (ADS)

NTFS lets a file carry multiple $DATA attributes. The unnamed one is the "real" file; named ones (file.txt:hidden) are alternate data streams — invisible to Explorer, invisible to dir, and routinely used to stash payloads.

What it leaves behind:

• An ADS is just another $DATA attribute in the same MFT record. Every parser that walks the attribute stream lists them.
• The Zone.Identifier ADS, added automatically by browsers, often survives on downloaded payloads — proving the file came from the internet and which security zone.

How to spot it: dir /R from cmd.exe lists ADS on a live system. streams.exe from Sysinternals enumerates them. The MFT parser shows them inline with the record. See alternate data streams.

Wiping a single file

Sophisticated wipers overwrite the file's clusters and then delete the MFT record. Less sophisticated ones (del /f, SDelete on default settings) overwrite the data but leave the MFT record in place.

What it leaves behind:

• A deleted MFT record with intact $FILE_NAME and $STANDARD_INFORMATION — the name and timestamps survive even if the data is gone. See what survives when you delete a file on NTFS.
• Often a $UsnJrnl record for the original creation and the deletion.
• $LogFile entries for the metadata operations.
• A VSS snapshot from before the wipe still containing the full file.

How to spot it: Even a "wiped" file leaves a name, a path, and timestamps in $MFT. Combine with VSS snapshots (snapshots and $MFT) and you often recover the content too.

Wiping the MFT record itself

A more aggressive attacker writes a new file to deliberately reuse the slot, overwriting the deleted record. This succeeds — the slot is gone — but the deletion is itself an event.

What it leaves behind:

• The sequence number of the record incremented. A reference from $UsnJrnl or $LogFile to the old sequence is now stale and tells you the slot has been reused since.
• $UsnJrnl still records both the original creation/deletion and the new file's creation, including a different parent directory if the new file lives elsewhere.
• Snapshot copies of $MFT from before the reuse still hold the original record.

How to spot it: Cross-reference $UsnJrnl against the current $MFT. A $UsnJrnl entry whose target record's sequence number is now higher than the entry's reference indicates a reuse.

$UsnJrnl truncation

The change journal is finite. An attacker who runs noisy operations (many file writes) can force $UsnJrnl to wrap, evicting older entries.

What it leaves behind:

• A $UsnJrnl that starts later than its $Max parameter would suggest is suspicious.
• $LogFile does not rotate the same way and often still records the operations that pushed $UsnJrnl out.
• The noisy operations themselves leave thousands of MFT records — they are visible.

$UsnJrnl deletion

fsutil usn deletejournal /D C: removes the journal entirely. Recreated journals start with a fresh USN counter.

What it leaves behind:

• A $UsnJrnl whose first USN is suspiciously high, or whose first record is hours or minutes before the incident.
• An $Extend directory entry whose MFT record sequence number has incremented.
• VSS snapshots from before the deletion still containing the full journal.

Renaming to a system file

Hiding malware as svchost.exe, lsass.exe, or another familiar Windows binary. Not technically MFT anti-forensics, but it is the most common analyst-fooling trick in the wild.

What it leaves behind:

• A $FILE_NAME whose parent directory reference is not C:\Windows\System32.
• A $DATA attribute whose size and entropy do not match the legitimate binary's distribution.
• A Zone.Identifier ADS from the download.

Ransomware MFT scribbles

Some ransomware families (Petya, NotPetya, and a handful since) deliberately corrupt $MFT to make the volume unmountable. This is destructive rather than evasive.

What it leaves behind:

• BAAD records where FILE should be.
• An unbootable system, but a forensically valuable image — signature-scan the volume for FILE records and most of the table is still readable.

See ransomware patterns in MFT for the details.

The general principle

Every anti-forensic technique on NTFS leaves some artifact. The reason is structural: $MFT, $UsnJrnl, $LogFile, and VSS each record a different view of the same events, and modifying one of them is itself an event that the others record. Triage that walks all four together is hard to defeat.