The $MFT — the one artifact I check first on every Windows investigation

If you work in DFIR and you are not comfortable reading the Master File Table, this article is for you. We will go from what it is, to what it contains, to how you actually use it, all without assuming you already know the answer.

A note before we begin

This is the first article in the “I Experience, We Learn” series. Everything here is based on what I have personally encountered while working on Windows investigations. My intention is not to hand you ready-made conclusions — forensic interpretation always depends on the full context of your specific case. What I want to do is build your foundational understanding so that when you open a $MFT for the first time, you know what you are looking at and what questions to start asking.

We will keep things practical. No unnecessary theory. Just what matters, explained clearly.

First, what problem does the $MFT solve?

Windows uses a file system called NTFS — New Technology File System — on almost every modern device you will encounter in an investigation. NTFS is built around one central idea: every single file and folder on a volume needs a detailed record that the operating system can refer to quickly. That record lives in the Master File Table, or $MFT.

Think of it this way. When you walk into a large library, the librarian does not search every shelf to find a book. They check a catalogue first. The $MFT is NTFS’s catalogue. Every file has an entry in it — its name, its size, its timestamps, its location on disk, its permissions, and sometimes even its actual content if the file is small enough.

WHY THIS MATTERS FOR FORENSICS

When a file is deleted on an NTFS volume, its $MFT entry is not immediately removed. It is simply marked as available for reuse. Until another file takes that slot, all the metadata about the deleted file, timestamps, name, size, attributes — remains readable. This is why the $MFT is often one of the first places an examiner looks when trying to understand what was on a device, including things that someone may have tried to remove.

Where does the $MFT live and how do you get it?

The $MFT is a hidden system file that sits at the root of every NTFS volume. You cannot open it through Windows Explorer — the operating system protects it from normal user access. But forensic tools can extract it from a forensic image or directly from a live system. There are three practical ways to acquire the $MFT:

• From a forensic image: If you have a full disk image (E01 or raw/dd format), any major forensic platform can extract the $MFT directly from the image. This is the most forensically sound method.
• From a live system using FTK Imager: Open FTK Imager as Administrator, add the volume as a logical evidence item, navigate to the root, right-click on $MFT, and export. This gives you the raw $MFT file without needing a full disk image.
• Using KAPE for triage: KAPE’s triage targets will pull the $MFT along with other key NTFS artifacts in a single pass. This is particularly useful in time-sensitive engagements where you cannot afford to image the entire disk.

Inside a single MFT record, what does the structure look like

Each entry in the $MFT is exactly 1,024 bytes in size. The first 16 entries, record numbers 0 through 15, are reserved for NTFS’s own system files. Record 0 is the $MFT itself. Record 1 is its mirror backup ($MFTMirr). Everything from record 16 onwards is where actual files and directories are recorded.

Every record starts with the four-byte signature FILE (hex: 46 49 4C 45). If you see this in a hex editor, you are looking at the start of an MFT record. Here is the general layout of what follows:

Highlighted rows (0x10 and 0x30) are the two most forensically significant attributes they each carry a full set of MAC(B) timestamps.

Resident data is worth knowing about. Because small files store their content directly inside the MFT record, it is sometimes possible to recover the content of a small deleted file even if the disk clusters it originally occupied have been overwritten. The $DATA attribute in the MFT record may still hold the content. This applies to files roughly 700 bytes or smaller.

The four key attributes every examiner should know

Not all attributes carry equal forensic weight. These four come up in almost every Windows investigation:

Understanding MAC(B) timestamps slowly and clearly

The MAC(B) times are derived from file system Metadata. MAC(B) stands for:

• Modified (M)- Last time the file’s actual content changed. Saving a document updates this. Renaming or moving the file does not.
• Accessed (A)- Last time the file was opened or read. On many modern Windows systems, this is disabled by default, so it may not always be reliable
• Changed (C) ($MFT Modified)- Last time the MFT record itself was modified, such as permissions, attributes, link count. This is NOT the creation time. Beginners often confuse C with Created.
• Birth (B) (File Creation Time)- When the file was first created on this volume. On a file copy, this reflects the copy time, not the original file’s creation date.

Not all file systems record a birth time. Only NTFS File systems will record it. Every file on an NTFS volume carries eight timestamps in total, “four” in the $STANDARD_INFORMATION attribute and “four” in the $FILE_NAME attribute. Together, these are referred to as MAC(B) timestamps. Each letter stands for a different type of event.

One of the most common beginner mistakes: The C in MAC(B) does not stand for Created. It stands for Changed; meaning the MFT entry itself was modified. The Born (B) timestamp is the creation time. Getting this right matters when you are building a forensic timeline.

$STANDARD_INFORMATION vs $FILE_NAME and why both matter

One of the most practically important things to understand about $MFT timestamps is that every file has two sets of them, and they do not always agree with each other. When they disagree, that disagreement itself can be meaningful.

The $STANDARD_INFORMATION (0x10) timestamps are what Windows Explorer shows when you right-click a file and check its properties. They can be modified by any user-space application that has write access to the file. There are publicly available tools — including some built into penetration testing frameworks — that can set these timestamps to any value an attacker chooses.

The $FILE_NAME (0x30) timestamps are different. They are only updated by the Windows kernel during specific operations like file creation, copying, or moving a file within the same volume. They are not easily accessible to user-space processes on modern patched Windows systems.

This means that when you are looking at a suspicious file, comparing the two sets of timestamps can be informative:

In Example B above, the $STANDARD_INFORMATION timestamp shows a date from years earlier while the $FILE_NAME timestamp shows the actual date the file was created on this volume. This kind of mismatch is one indicator that timestamp manipulation — commonly referred to as timestomping — may have occurred. It does not confirm it on its own, but it is a flag worth following up on.

Important nuance: Not every timestamp mismatch means tampering. Some legitimate software installers modify $SI timestamps as part of their installation process. Some archiving tools preserve original timestamps when extracting files. Always look for corroboration in other artifacts like the $UsnJrnl or prefetch files before forming any view on whether manipulation occurred.

Timestomping: what it is and why it matters

Timestomping is the deliberate modification of file timestamps to make a file appear older or newer than it actually is. It is classified under MITRE ATT&CK as technique T1070.006 — Indicator Removal: Timestomp.

The reason attackers use it is straightforward. When an incident responder filters the $MFT to look for files created during the window of a known attack, a timestomped file may fall outside that window entirely — and get skipped. If the $STANDARD_INFORMATION timestamp has been set to a date two years in the past, the file looks like a pre-existing system file rather than something dropped during the incident.

The practical detection approach is comparing $STANDARD_INFORMATION timestamps against $FILE_NAME timestamps for the same file. MFTECmd flags these mismatches automatically in its output when you use the “--at” flag. But there are a few additional things worth knowing:

• Some timestomping tools truncate the nanosecond precision field to all zeros — producing timestamps ending in .0000000. This can be a secondary indicator. However, some legitimate archiving tools also truncate nanoseconds, so it is not conclusive on its own.
• If an attacker renames or moves a file on the same volume after timestomping the $SI attribute, Windows will copy the tampered $SI timestamps into the $FN attribute — meaning the mismatch disappears. This is a known limitation of the $SI vs. $FN comparison method.
• The $UsnJrnl and $LogFile can sometimes provide independent timestamp evidence for a file’s activity, which is why corroboration across multiple artifacts is always preferred over relying on a single source.

A step-by-step guide on how to acquire, parse, and begin analysis

Acquiring the $MFT

• Launch FTK Imager as Administrator on the target or examiner machine. Navigate to File → Add Evidence Item → Logical Drive and select the volume you are examining.
• In the left pane, expand the volume tree. NTFS metadata files appear at the root with $ prefixes. Right-click $MFT and select Export Files. Save to a write-protected evidence output folder.
• While you are there, also export $LogFile, $Boot, and the $UsnJrnl ($Extend\$J). Pull them all at once — you will need them for corroboration.
• Immediately after export, record the MD5 and SHA-1 hash of each file. Note the acquisition time in UTC. This is your chain of custody starting point.

Parsing with MFTECmd

Basic parse to CSV - loads into Timeline Explorer
MFTECmd.exe -f "C:\Evidence\$MFT" - csv "C:\Evidence\Output" - csvf parsed_mft.csv

Include ALL $FILE_NAME timestamps - critical for mismatch detection
MFTECmd.exe -f "C:\Evidence\$MFT" - csv "C:\Evidence\Output" - csvf parsed_mft.csv - at

Generate a bodyfile for mactime-based timelines (Linux / SIFT workflow)
MFTECmd.exe -f "C:\Evidence\$MFT" - body "C:\Evidence\Output" - bodyf timeline.body - bdl C - blf

Parse $UsnJrnl alongside $MFT for corroboration
MFTECmd.exe -f "C:\Evidence\$J" -m "C:\Evidence\$MFT" - csv "C:\Evidence\Output" - csvf usnjrnl.csv

The “--at” flag matters more than most tutorials mention. By default, MFTECmd only outputs $FILE_NAME timestamps in columns like Created0x30 when they are different from the $STANDARD_INFORMATION timestamps. If you skip “ — at”, you will miss the full picture — especially in timestomping scenarios where the differences are exactly what you are looking for.

Key columns to focus on in Timeline Explorer

Tools that work alongside MFTECmd

What to always corroborate with

The $MFT is a powerful starting point, but it should never be the only artifact you rely on. These companion artifacts each add something that the $MFT alone cannot give you:

• $UsnJrnl ($J): The NTFS Update Sequence Number Journal logs every file operation — create, delete, rename, overwrite — with a reason code and an independent timestamp. It can confirm or challenge what the $MFT timestamps suggest about when a file was active.
• $LogFile: The NTFS transaction log. Useful for very recent file system operations, though it fills up quickly on busy systems and has limited historical depth.
• $I30 (Directory Index): Each directory maintains its own index of contained files. Deleted entries leave metadata residue in the directory index slack — this residue persists across all Windows versions, including Windows 10 and 11.
• Volume Shadow Copies: Point-in-time snapshots of the volume. Comparing a current $MFT against one from a shadow copy can reveal files that were created or deleted between snapshot intervals.
• Prefetch files: Provide independent timestamps for program execution. If a prefetch file’s embedded timestamp does not align with the $MFT timestamps for the same executable, that is worth investigating.

What this article has covered

We have gone from what the $MFT is and why it exists, to the internal structure of a single MFT record, to the four key attributes, to how MAC(B) timestamps work and where they can mislead you, to how timestomping appears in the data and how to approach it carefully, and finally to the full acquisition and parsing workflow.

This is a foundational article. The concepts here will come up in almost every Windows investigation you work on — whether you are looking at a suspected data deletion, a malware infection, or a timeline reconstruction after an incident. The more comfortable you are reading the $MFT, the faster your analysis will become.

In Episode 02, we will use this foundation and go further — looking at how the $MFT’s Born timestamps, combined with the Volume Serial Number and Event Log Record IDs, can help an examiner understand the broader history of a Windows device. Stay tuned.

COMMUNITY PLATFORMS AND RESOURCES REFERENCED

• Forensic Focus — forensicfocus.com
• DFIR-IRIS — dfir-iris.org
• AboutDFIR — aboutdfir.com
• This Week in 4n6 — thisweekin4n6.com
• The DFIR Report — thedfirreport.com
• SANS DFIR Blog
• EZ Tools — ericzimmerman.github.io
• Hexordia Blog
• And many more…….