Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Every file and directory on an NTFS volume — present or deleted, hidden or visible — has a corresponding record in the Master File Table (MFT), the metadata backbone of the file system. The MFT tracks names, timestamps, size, permissions, and (for small files) the file’s actual content, all inside fixed-size records that persist, in whole or in part, long after a file is deleted. For a forensic analyst, the MFT is often the single densest source of file-system history on a Windows disk image, frequently surviving well past what Explorer or a simple directory listing would show.
MFT analysis matters specifically because it exposes two independent timestamp attributes per file — one that is trivially rewritable by user-mode tools and one that generally is not. That asymmetry is the basis for detecting timestomping, the anti-forensics technique where an attacker backdates a malicious file’s timestamps to blend in with legitimate system files, and it is one of the more reliable file-system-level indicators of tampering available to an investigator.
Attack Prerequisites
MFT forensics is an analysis technique, not an attack, but getting useful results depends on a few conditions:
- A forensically sound disk image or extracted
$MFTfile — acquired with a write-blocker or via a validated live-response export (e.g. KAPE), never analyzed directly against a mounted live volume. - The volume not yet been defragmented or heavily reused — deleted-file MFT records are only recoverable until their slot is reallocated to a new file.
- Parsing tooling capable of reading raw MFT structures — Eric Zimmerman’s
MFTECmd,analyzeMFT, The Sleuth Kit’sistat/fls, orplaso/log2timelinefor full-image supertimelines. - Access to supporting artifacts —
$LogFileand$UsnJrnl(the USN Journal) corroborate or contradict what the MFT alone shows, and are much harder for an attacker to consistently falsify.
How It Works
Each MFT record is normally 1024 bytes and begins with the signature FILE0 (or BAAD for a corrupted record), followed by a sequence of typed attributes. The two that matter most forensically are $STANDARD_INFORMATION (type code 0x10), which stores the Created/Modified/MFT-Modified/Accessed (C/M/E/A) timestamps that Explorer and the Win32 GetFileTime/SetFileTime API expose, and $FILE_NAME (type code 0x30), which stores a *second, independent* copy of the same four timestamps plus the file’s name and parent directory reference. $DATA (0x80) holds the actual file content when present — small files (roughly under 700-900 bytes depending on other attributes present) fit entirely inside the MFT record itself as resident data, meaning the content survives purely in MFT slack even after the file is deleted and its file-system-proper data runs are gone.
The critical asymmetry: $STANDARD_INFORMATION timestamps are updated by ordinary user-mode file operations and are exactly what the Win32 SetFileTime API (and every timestomping tool built on it) modifies. $FILE_NAME timestamps, by contrast, are only updated by NTFS itself during specific operations — file creation, rename, and move — and are not reachable through the standard file-time APIs at all. An attacker using a typical GUI or PowerShell timestomping technique changes $STANDARD_INFORMATION but leaves $FILE_NAME reflecting the file’s true creation time, producing a detectable SI/FN mismatch.
Two further sources corroborate or contradict MFT timestamps independently: the $LogFile, an NTFS transaction journal that records low-level metadata operations (including timestamp changes) for a short rolling window, and the $UsnJrnl (specifically its $J data stream under $Extend\$UsnJrnl), which logs a longer-lived, higher-level history of file creates, renames, extensions, and overwrites with reason codes. Both are updated independently of $STANDARD_INFORMATION and are rarely also forged by an attacker, making them the strongest corroborating evidence in a timestomping investigation.
Practical Example / Configuration
A concrete $STANDARD_INFORMATION timestomp check: extract and parse the MFT, then compare the SI and FN Created timestamps for the file(s) in question. Native, un-timestomped files typically show SI-Created equal to or extremely close to FN-Created (within the same operation); a meaningfully earlier or later SI-Created relative to FN-Created — especially SI dates that predate the OS install or match unrelated system files exactly — is the signature to look for.
# Extract $MFT from an image (e.g. mounted with Arsenal Image Mounter,
# or exported live via a triage collection tool)
MFTECmd.exe -f C:\cases\case1\$MFT --csv C:\cases\out --csvf mft.csv
# Also parse the USN journal and $LogFile for corroboration
MFTECmd.exe -f C:\cases\case1\$Extend\$UsnJrnl_J --csv C:\cases\out --csvf usnjrnl.csv
MFTECmd.exe -f C:\cases\case1\$LogFile --csv C:\cases\out --csvf logfile.csv
# mft.csv columns of interest per record:
# Created0x10 / Modified0x10 / LastAccess0x10 <- $STANDARD_INFORMATION
# Created0x30 / Modified0x30 / LastAccess0x30 <- $FILE_NAME
#
# Suspicious pattern (timestomped malicious binary):
# Created0x10 = 2019-03-18 05:12:00 (matches a stock Windows DLL date)
# Created0x30 = 2026-07-09 14:03:22 (the file's real drop time)
# -> SI predates FN by 7+ years and matches a suspiciously round OS date
A simple triage rule of thumb an analyst can script against the MFTECmd CSV output: flag any record where Created0x10 < Created0x30 by more than a small tolerance, or where Created0x10 timestamps cluster suspiciously (e.g. many unrelated files sharing the exact same second) — a common artifact of scripted timestomping.
Walkthrough / Exploitation
A full MFT-driven file-system timeline investigation typically layers several Eric Zimmerman / Sleuth Kit tools together:
# 1. Parse the MFT to CSV
MFTECmd.exe -f E:\images\case1.E01\$MFT --csv C:\out --csvf mft.csv
# 2. Cross-reference with the USN journal for create/rename/overwrite events
MFTECmd.exe -f E:\images\case1.E01\$Extend\$UsnJrnl_J --csv C:\out --csvf usn.csv
# 3. Build a full super-timeline including MFT, registry, event logs, etc.
log2timeline.py plaso.dump E:\images\case1.E01
psort.py -o l2tcsv -w timeline.csv plaso.dump
Load mft.csv and usn.csv into Timeline Explorer (or a spreadsheet) sorted by Created0x10, cross-filter for the suspect file name or path, and confirm the SI/FN discrepancy against the corresponding $UsnJrnl entry, which records the *actual* wall-clock time NTFS created or renamed the file regardless of what $STANDARD_INFORMATION was later set to.
Note: Resident file content stored directly inside a small MFT record can sometimes be recovered even after the file entry has been marked deleted and the directory entry removed, since the 1024-byte record slot itself is only overwritten when NTFS reallocates it — this is why MFT carving remains useful for small deleted files (scripts, config files, shortcuts) long after
$Recycle.Binhas been emptied.
Opsec / Analyst tip: Timestomping tools that only call
SetFileTimenever touch$FILE_NAME,$LogFile, or$UsnJrnl— always pull all three before concluding a file’s dates are trustworthy or forged. A sophisticated actor with raw disk access can in principle edit$FILE_NAMEtoo, but this is rarely seen outside of dedicated forensic-evasion research.
Detection and Defense
MFT-based timestomp detection is primarily a hunting and investigative control, but it feeds directly into broader detection posture:
- Automate SI/FN comparison across
MFTECmdoutput for newly dropped executables and scripts as part of routine threat hunting, not just incident response. - Retain and forward
$UsnJrnl/$LogFile-derived telemetry (e.g. via Sysmon Event ID 11 file-create events, which are independent of NTFS metadata and much harder to backdate after the fact) as a corroborating source. - Preserve the full $MFT, $LogFile, and $UsnJrnl during acquisition, not just the active file system — many triage collectors skip these by default.
- Treat mass-timestomped drops as high-signal, since legitimate software installers essentially never set
$STANDARD_INFORMATIONdates that predate the file’s actual creation.
Real-World Impact
Timestomping is a long-standing, widely used anti-forensics technique (MITRE ATT&CK T1070.006) seen across commodity malware and targeted intrusions alike, precisely because tools to backdate $STANDARD_INFORMATION timestamps (including built-in APIs callable from PowerShell) are trivially available. MFT and USN-journal analysis is the standard forensic countermeasure, and it is a routine part of any Windows intrusion investigation where an analyst needs to establish the true initial-access or drop time of a malicious artifact rather than the attacker-supplied one.
Conclusion
The Master File Table’s dual timestamp attributes turn a routine NTFS implementation detail into one of the more dependable anti-anti-forensics checks available to a Windows investigator. Parsing the MFT with tools like MFTECmd, comparing $STANDARD_INFORMATION against $FILE_NAME, and corroborating both against the $LogFile and $UsnJrnl reliably surfaces timestomped artifacts that a surface-level Explorer or dir listing would never reveal.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments