NTFS and the Master File Table
The MFT is the most important artifact on a Windows disk — it records every file that ever existed on the volume, including deleted files, with four timestamps per file. This chapter explains NTFS structure, what the MFT tells you, and how to use MFTECmd to build a file activity timeline.
An attacker staged 3.2 GB of data in a temp directory, compressed it with 7-Zip, exfiltrated it over HTTPS, then deleted the archive and the staging folder. By the time you're investigating, the files are gone. But the MFT remembers them. Every file that existed on the volume has an MFT record with creation, modification, MFT-modified, and access timestamps. The deleted archive's MFT record is still present, with timestamps that let you build the exact sequence: "attacker created staging dir at 02:14, ran data collection script at 02:16, 7-Zip compress completed at 02:31, archive uploaded at 02:33, deletion at 02:35." This chapter shows you how to read that story from the MFT.
NTFS Filesystem Structure
NTFS Volume Layout ═══════════════════════════════════════════════════════════════════ [ Partition Boot Record ] [ $MFT — Master File Table ] ← Every file has a record here [ $MFTMirr — MFT backup (first 4) ] [ $LogFile — Journal ($UsnJrnl) ] ← Tracks recent file operations [ $Volume — Volume name/GUID ] [ $AttrDef — Attribute definitions ] [ $Bitmap — Cluster usage map ] [ $BadClus — Bad cluster tracking ] [ $Secure — Security descriptors ] [ $UpCase — Uppercase table ] [ $Extend — Directory for meta ] │ └── $UsnJrnl — Update Sequence Journal └── [ File data — actual content ] The MFT itself: ├── MFT Record 0: $MFT (the MFT file itself) ├── MFT Record 1: $MFTMirr ├── MFT Record 2: $LogFile ├── ... ├── MFT Record 24: C:\Windows\ ├── MFT Record 25: C:\Windows\System32\ └── ... one record per file/directory ...
The Four NTFS Timestamps (MACB)
Every MFT record contains two sets of four timestamps — called MACB — one set in $STANDARD_INFORMATION and one in $FILE_NAME. This distinction is critical for forensics.
| Letter | Name | Updated when |
|---|---|---|
| M | Modified ($DATA) | File content was last written/changed |
| A | Accessed | File was last opened/read (unreliable — often disabled in Windows for performance) |
| C | Changed ($MFT record modified) | Any attribute on the MFT record changed — includes renamed, permissions changed, etc. |
| B | Birth (Created) | File was created on this volume |
Every MFT record has two timestamp sets. $STANDARD_INFORMATION timestamps are what Windows Explorer shows and what forensic tools report by default — they can be trivially modified with timestomping tools like Meterpreter's timestomp. $FILE_NAME timestamps are harder to modify because they're in a different attribute and most timestomping tools don't touch them. The forensic tell: if $SI and $FN timestamps for a file's creation time differ significantly, timestomping has likely occurred. A file created by the attacker but timestomped to look like a Windows system file will have a $FN birth timestamp matching when the attacker actually created it, even if $SI timestamps were changed to blend in.
Detecting Timestomping
Timestomping Detection Pattern
═══════════════════════════════════════════════════════════════════
Normal file (not timestomped):
$STANDARD_INFORMATION Created: 2026-03-15 09:23:14
$FILE_NAME Created: 2026-03-15 09:23:14 ← matches SI
Timestomped file (attacker changed $SI to blend in):
$STANDARD_INFORMATION Created: 2020-08-01 00:00:00 ← suspicious precision
$FILE_NAME Created: 2026-09-15 03:42:17 ← real creation time
Indicator: $SI created time predates $FN created time
Indicator: $SI timestamps have suspiciously round precision (00:00:00)
Indicator: $SI timestamps predate the OS installation date
Additional tell: $MFT record sequence number
MFT records are allocated sequentially. A file with:
- $SI timestamps from 2020
- MFT record number 850,000+
- Other files created in 2026 have MFT numbers around 840,000
→ The MFT record number says the file was created much later than the
timestamps claim.
Using MFTECmd to Analyze the MFT
:: Parse MFT with MFTECmd — Eric Zimmermann's tool
:: Requires: MFTECmd.exe from https://ericzimmerman.github.io
:: Basic MFT parse — outputs CSV with all files + timestamps
MFTECmd.exe -f "D:\evidence\$MFT" --csv "D:\analysis\mft" --csvf mft.csv
:: Output includes:
:: EntryNumber, SequenceNumber, ParentEntryNumber,
:: FileName, Extension, FileSize,
:: Created0x10 (SI created), Modified0x10 (SI modified), MFTModified0x10, LastAccessed0x10
:: Created0x30 (FN created), Modified0x30 (FN modified), MFTModified0x30, LastAccessed0x30
:: IsDirectory, IsDeleted, HasAds, IsAds, SI_LT_FN (timestomp indicator!)# Hunt for timestomped files in MFTECmd output
# SI_LT_FN = 1 means $SI created timestamp is earlier than $FN created timestamp
# This is the primary timestomping indicator
$mft = Import-Csv "D:\analysis\mft\mft.csv"
# Method 1: Use MFTECmd's built-in SI_LT_FN flag
$mft | Where-Object {
$_.SI_LT_FN -eq "1"
} | Select-Object FileName, Created0x10, Created0x30, EntryNumber, IsDeleted |
Format-Table -AutoSize
# Method 2: Find files with suspicious round timestamps
$mft | Where-Object {
$_.Created0x10 -match "00:00:00$" # midnight precision
} | Select-Object FileName, Created0x10, Created0x30 |
Format-Table
# Method 3: Files in system directories with $SI created before OS install
# First determine OS install date from registry or event log
$osInstall = "2025-06-01" # get this from SOFTWARE hive InstallDate key
$mft | Where-Object {
$_.FullName -match "^C:\\Windows" -and
[datetime]$_.Created0x10 -lt [datetime]$osInstall
} | Where-Object {
# But $FN timestamp is AFTER OS install (real creation was after install)
[datetime]$_.Created0x30 -gt [datetime]$osInstall
} | Select-Object FileName, Created0x10, Created0x30Deleted Files in the MFT
When Windows deletes a file, it marks the MFT record as "not in use" but doesn't immediately overwrite it. The record remains — with all timestamps and file metadata intact — until NTFS needs to reuse that record number for a new file. On most systems, deleted file MFT records persist for days to weeks.
# Find deleted files from MFT CSV output
$mft = Import-Csv "D:\analysis\mft\mft.csv"
# Show all deleted files created after a specific date
$mft | Where-Object {
$_.IsDeleted -eq "True" -and
[datetime]$_.Created0x10 -gt [datetime]"2026-09-19 00:00:00"
} | Select-Object FileName, Extension, FileSize, Created0x10, Modified0x10, ParentPath |
Sort-Object Created0x10 |
Format-Table -AutoSize
# Common attacker artifacts to look for in deleted files:
# .zip, .7z, .rar — data staging/exfiltration archives
# .exe, .dll — malware dropped and deleted after execution
# .ps1, .bat, .vbs — scripts run and deleted
# .cab — compressed installation packages
# No extension — renamed to evade detectionThe USN Journal ($UsnJrnl)
The Update Sequence Number Journal records every file operation — creation, modification, rename, deletion — with a sequence number and timestamp. It fills and wraps (overwriting old records), but for recent activity it's a richer record than the MFT alone.
# Parse USN Journal with MFTECmd (also handles $J / $UsnJrnl)
# The journal is at $Extend\$UsnJrnl:$J
# MFTECmd can parse the journal directly
MFTECmd.exe -f "D:\evidence\C\$Extend\$J" --csv "D:\analysis\usn" --csvf usn.csv
# USN Journal output columns:
# UpdateTimestamp, UpdateReasons, FileName, FileExtension
# UpdateReasons shows: FILE_CREATE, DATA_OVERWRITE, DATA_EXTEND,
# RENAME_OLD_NAME, RENAME_NEW_NAME, FILE_DELETE, CLOSE
# On Linux with SIFT: use python-ntfs or ntfsusn
# pip install ntfs
# ntfsusn parse /dev/sda1 "$Extend/$UsnJrnl" -o usn.csvMFT Analysis Workflow in Practice
| Question | MFT approach |
|---|---|
| What files did the attacker create? | Filter MFT by creation time in the suspected attacker timeframe. Look in temp dirs, user profile, ProgramData, AppData. |
| What did the attacker delete? | Filter IsDeleted=True and creation time in attacker timeframe. |
| Did the attacker use timestomping? | Filter SI_LT_FN=1 — any result here is a timestomping indicator. |
| What was the first file the attacker dropped? | Sort by Created0x10 (earliest) for attacker-associated paths during the incident window. |
| Did the attacker stage data for exfiltration? | Look for large archive files (.zip/.7z) created in unusual locations during the incident window, including deleted ones. |
Q & A
Q: The MFT record for a deleted file is gone — NTFS reused it. Is the file data still recoverable?
Once the MFT record is overwritten, file system metadata for that file is gone — you can't look it up by filename or path anymore. But the file's actual data clusters on disk may still be intact (unallocated but not yet overwritten). File carving tools — Foremost, Scalpel, PhotoRec — scan raw disk blocks for file signatures (magic bytes at the start of known file formats) and recover file content without needing the MFT metadata. You'll get the content but not the original filename or timestamps. For common formats (ZIP, PDF, Office documents), carving works well. For files with no recognizable header — encrypted data, custom binary formats — carving may not be able to identify them. Chapter 28 covers deleted file recovery and carving in detail.
Q: An attacker ran a tool from memory — no file dropped to disk. Will the MFT have any record?
If the tool was truly fileless — loaded entirely in memory via PowerShell, .NET reflection, or process injection — the MFT won't have a record of the tool itself. However, any side effects may appear: if the tool wrote output files (scan results, credentials), those appear in the MFT. If the tool was initially dropped as an EXE and then executed, its MFT record exists even if the file was later deleted (marked as deleted, not erased). Fileless execution leaves different evidence trails: PowerShell Script Block Logs (Event 4104), Prefetch entries (if execution came from a temp file), Amcache entries (if the loader touched the filesystem), and most importantly — the memory image, where the injected code lives. For truly fileless attacks, memory forensics is the primary evidence source, not the MFT.