← Back to blog

NTFS anti-forensics: what attackers actually do, and what gives them away

· 7 min read

Every anti-forensics technique on NTFS leaves something behind. The reason is structural. The MFT, the USN journal, $LogFile, and Volume Shadow Copies each record a different view of the same events, and modifying one of them is itself an event the others record. An attacker who hides from one artifact almost always lights up another. A defender who walks all four together is hard to beat.

This is the catalog. For each technique: what attackers do, what residue it leaves, and which artifact gives them away.

Timestomping

The classic. Tools like SetMACE, timestomp, the well-known Invoke-TimeStomp PowerShell scripts, and any number of red team helpers call SetFileTime or write $STANDARD_INFORMATION directly to make a file look older or newer than it is. Recent variants also touch $FILE_NAME by renaming the file (which forces NTFS to update FN) and then renaming back. The "double rename" trick is what separates a competent operator from a script kiddie.

What gives it away:

  • SI/FN divergence. Plain SetFileTime only touches SI. The corresponding FN timestamps are still the real creation/rename times. See the four MFT timestamps. Any record where SI created is more than a few seconds away from FN created is suspicious. Where SI created predates FN created, it is impossible naturally: files cannot exist before they are named.
  • Sub-second granularity. NTFS stores timestamps in 100-nanosecond ticks. Native operations leave noise in the bottom digits. Most timestomping tools round to the second. A column of .0000000 suffixes lined up neatly across multiple files is a fingerprint.
  • $UsnJrnl truth. The USN journal logs the actual modification time when entries are written. A USN DATA_OVERWRITE for a record's $DATA attribute with a timestamp that disagrees with the MFT's SI modified time is timestomping caught red-handed.
  • VSS snapshots. Older Volume Shadow Copies hold the pre-stomp values. Diff the current $MFT against the snapshot's $MFT for the same record and the change is visible.

The double-rename trick defeats SI/FN divergence. It does not defeat USN journal entries or VSS diffs.

Alternate Data Streams as payload hiding

A $DATA attribute with a name (legit.docx:payload.exe) is invisible to Explorer, invisible to dir, and routinely used to stash executables, scripts, or encoded configuration that the visible file does not betray. Launched via wmic process call create, rundll32, or Get-Content -Stream plus Invoke-Expression.

What gives it away:

  • MFT walks expose every $DATA attribute. Per-file enumeration misses streams on files you did not think to check. The MFT does not. See alternate data streams.
  • Sysmon Event ID 15 (FileCreateStreamHash) is the one Sysmon event that hashes ADS creation. If Sysmon is deployed and configured, this catches stream drops directly.
  • Zone.Identifier. Downloads from a browser carry this ADS. A binary that lacks it in \Downloads\ either never came from a browser or was deliberately stripped (Unblock-File).

Wiping a single file

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

What gives it away:

  • The MFT record itself. A deleted record with intact $FILE_NAME and $STANDARD_INFORMATION still names the file, gives its parent directory, and shows the timestamps at the moment of deletion. See what survives a delete.
  • $UsnJrnl create and delete entries. Both events are logged independently of whether the data was wiped.
  • $LogFile. Transaction records for the metadata operations sit there until rolled over.
  • VSS snapshots. If a snapshot existed before the wipe, the file is intact in it.

Wiping the MFT record itself

A more aggressive attacker writes new files specifically to force NTFS to reuse the slot, overwriting the deleted record. This succeeds: the slot is gone. The deletion is still an event.

What gives it away:

  • Sequence number increment. A reference from $UsnJrnl or $LogFile to record R sequence S is now stale; the current record is sequence S+1. A cross-reference exposes the reuse.
  • $UsnJrnl history. The original creation, modification, and deletion are still recorded. So is the new file's creation. The reuse leaves a USN trail.
  • VSS snapshots. Snapshot copies of $MFT from before the reuse still hold the original record at sequence S.

$UsnJrnl truncation

The change journal is finite. An attacker running noisy operations (many file writes) can force $UsnJrnl to wrap, evicting older entries. The default size is 32 MB on most installations; bigger on Server.

What gives it away:

  • A short $UsnJrnl with a high starting USN. If the journal's first record is hours or minutes before the incident on a host that has been online for weeks, it has been rotated unnaturally fast. Calculate the expected rate.
  • $LogFile does not rotate the same way. It is sized to the volume and overwrites on a different policy. Operations that pushed the USN journal out are sometimes still in $LogFile.
  • The noisy operations themselves leave thousands of MFT records. The thousands of churned files needed to wrap the journal are visible in $MFT. The technique is loud.

$UsnJrnl deletion

fsutil usn deletejournal /D C: removes the journal entirely. The recreated journal starts with a fresh USN counter. The $Extend\$UsnJrnl MFT record's sequence number increments to reflect the deletion-and-recreation.

What gives it away:

  • First USN suspiciously high or first record suspiciously recent. A freshly created $UsnJrnl whose first record postdates the incident is a tell.
  • $Extend directory entry sequence number incremented. The MFT record for $UsnJrnl itself has a higher sequence than baseline.
  • VSS snapshots. Pre-deletion snapshots still contain the full original journal. Mount them with vshadowmount and extract.

Renaming malware to a system file name

Hiding a tool as svchost.exe, lsass.exe, cmd.exe, or another familiar Windows binary. Not strictly MFT anti-forensics, but it is the most common analyst-confusing trick in the wild.

What gives it away:

  • $FILE_NAME parent directory reference. The legitimate svchost.exe lives in C:\Windows\System32. A file with that name in \Users\bob\AppData\Local\Temp\ is not it. Check the parent reference, not just the name.
  • $DATA size and hash. The legitimate binary is well known. SHA-256 the impostor and compare. Mismatches are immediate.
  • Zone.Identifier ADS if it was downloaded.
  • Code signing. Microsoft binaries are signed. Check the Authenticode signature on the on-disk file; the impostor will not have one or will have a non-Microsoft one.

Less common but worth knowing. Multiple $FILE_NAME attributes on the same MFT record let an attacker have the same payload appear in two directories at once. Deleting it from one only removes one $FILE_NAME; the file lives until the last link is gone.

What gives it away:

  • hardlink_count field in the record header. If a record has count > 1, every $FILE_NAME is one of the links. The MFT shows all of them.
  • $UsnJrnl HARD_LINK_CHANGE reason on creation and removal of hard links.

$LogFile manipulation

fsutil does not offer a "delete the log file" option, but the log rotates on its own and operations that fill the volume can push entries out. Sophisticated operators occasionally try to scrub $LogFile to remove transaction records around an incident.

What gives it away:

  • $LogFile is locked while Windows runs. Tampering requires unmounting the volume, which is itself an event.
  • VSS snapshots from before the tamper still hold the full log.

Ransomware MFT scribbles

Some ransomware families (Petya, NotPetya, a handful since) deliberately corrupt $MFT to make the volume unmountable. This is destructive rather than evasive; the goal is denial of service, not stealth.

What gives it away:

  • BAAD records where FILE should be. chkdsk's tombstone for unrepairable records is what NTFS leaves after the wipe. Sometimes the scribbler does not write BAAD, in which case the records are unparseable but signature-scannable.
  • An unbootable system, but a forensically valuable image. The data clusters are usually intact. Signature-scan the volume for FILE records and most of the table is readable. See ransomware patterns in MFT for the details.

The general principle

Every anti-forensic technique on NTFS leaves an artifact somewhere. The reason is structural: $MFT, $UsnJrnl, $LogFile, and VSS each record a different view of the same events. The attacker who scrubs the MFT leaves USN entries. The attacker who deletes the USN journal leaves a fresh $Extend\$UsnJrnl sequence number bump and VSS snapshots intact. The attacker who runs vssadmin delete shadows leaves Windows Event Log entries (System 8224, Application VSS 8194) and possibly Sysmon Event ID 1 for the vssadmin.exe invocation.

Triage that walks all four NTFS artifacts plus event logs and VSS is what catches sophisticated operators. Single-artifact triage misses them.

Further reading

Related posts

External resources