NTFS Architecture for Forensic Examiners

The Master File Table: one record per file

NTFS organizes all file metadata in the Master File Table — a file that is itself stored on the volume (it is MFT record 0, referencing itself). Every file and directory on an NTFS volume has at least one MFT record. Each record is exactly 1024 bytes on standard NTFS configurations (this size is set at format time and cannot be changed without reformatting).

An MFT record is not a row in a database. It is a binary structure with a fixed-size header followed by a variable number of attributes. The header contains the record's administrative data: the "FILE" signature that identifies a valid record, the sequence number that tracks how many times the record has been reused, the hard link count, the flags that indicate whether the record is in use and whether it represents a directory, and the offset to the first attribute. The attributes contain the file's actual metadata and, for small files, the file content itself.

The relationship between MFT records and files is not always one-to-one. A file with many attributes or a very long filename may require multiple MFT records — a base record and one or more extension records linked by the base record reference. Hard links create multiple $FILE_NAME attributes in the same MFT record (one per link) or reference the same MFT record from multiple directory indexes. Understanding these relationships matters when you encounter an MFT record with an unexpected number of attributes or when a file appears to have contradictory metadata.

Attributes: where forensic evidence lives

Every piece of metadata in an MFT record is stored in an attribute. NTFS defines approximately 17 attribute types, but five are forensically significant.

$STANDARD_INFORMATION (type 0x10) is present in every MFT record. It contains four timestamps (created, modified, MFT entry modified, accessed), file permissions flags, the owner's security ID, and the update sequence number. This is the attribute that MFTECmd's primary timestamp columns come from. Critically for forensic analysis, $SI timestamps can be modified by any process running with write access to the file — including timestomping tools. A user-mode application can call SetFileTime() via the Windows API to set the $SI creation, modification, and access timestamps to any value. The MFT entry modification timestamp updates automatically when the record changes, but some timestomping tools account for this.

$FILE_NAME (type 0x30) contains the filename, the parent directory reference (which MFT record represents the parent directory), the file's size, and — crucially — its own set of four timestamps. The $FN timestamps are set by the NTFS driver when the file is created, and they are updated only in specific circumstances: the $FN creation timestamp is set once at file creation and never changes. The $FN modification timestamp updates when the file's $DATA attribute size changes (not when content changes without size change). The $FN access timestamp is rarely updated due to Windows' default behavior of disabling last access time updates (NtfsDisableLastAccessUpdate). The key forensic principle: $FN timestamps cannot be modified by user-mode applications. The SetFileTime() API modifies $SI timestamps but not $FN timestamps. This makes $FN timestamps the forensically reliable reference point for detecting timestomping.

$DATA (type 0x80) stores the file's content. If the content fits within the MFT record (approximately 700 bytes or less after other attributes are accounted for), it is stored "resident" — the bytes are physically within the MFT record itself. This is forensically significant because resident file content is captured by any tool that extracts the MFT, even if the file has been deleted. A small batch script, a configuration file, a text note — if the content was small enough to be resident and the MFT record hasn't been reallocated, the file content is recoverable from the MFT alone, without examining disk clusters.

If the content exceeds the resident threshold, it is stored "non-resident" — the $DATA attribute contains a data run list that maps logical file offsets to physical disk clusters. Each data run specifies a starting cluster and a length. Multiple data runs indicate file fragmentation. When a non-resident file is deleted, its MFT record is marked as free and its clusters are marked as available in the $Bitmap, but the data in those clusters persists until overwritten. This is the basis for deleted file recovery — and why SSDs with TRIM complicate recovery (TRIM instructs the SSD controller to erase the underlying flash cells for deallocated clusters).

$INDEX_ROOT (type 0x90) and $INDEX_ALLOCATION (type 0xA0) are present in directory MFT records. They implement a B-tree index of the directory's contents — each entry in the index contains the filename, the MFT reference number for the file, and the file's $FILE_NAME timestamps (duplicated from the file's own MFT record for performance). The forensic significance is in the index slack: when a file is deleted from a directory, its index entry is removed from the active B-tree, but the entry often persists in the index's allocated but unused space. This $I30 slack contains the filenames and timestamps of deleted files — evidence that persists independently of the deleted file's MFT record.

Cluster allocation and data recovery

NTFS divides the volume into clusters — fixed-size allocation units typically 4096 bytes (4KB) on modern systems. The $Bitmap file tracks which clusters are in use and which are free. When a file is created, NTFS allocates clusters from the free pool and records the allocation in the file's $DATA attribute as data runs. When a file is deleted, the clusters are marked as free in $Bitmap, but the data in those clusters is not zeroed or overwritten — it persists until another file is allocated those same clusters.

This is the fundamental principle of deleted file recovery on traditional hard drives: the file's data persists in its original clusters until those clusters are reused. The MFT record tells you which clusters the file occupied (if the record hasn't been reallocated), and you can read those clusters directly to recover the content. If the MFT record has been reallocated, file carving techniques can scan unallocated clusters for known file signatures (headers, magic bytes) to recover content without metadata.

SSDs fundamentally change this equation. The TRIM command, enabled by default on Windows since version 7, instructs the SSD controller to erase the flash cells underlying deallocated clusters. After TRIM, the cluster's content is gone — not merely marked as free, but physically erased at the flash level. TRIM execution is asynchronous (the OS sends the TRIM command, the SSD controller executes it at its discretion), so there is a window between deletion and TRIM execution where data may still be recoverable. This window varies from milliseconds to hours depending on the SSD controller and system load. For forensic purposes: on SSDs, treat deleted file content recovery as unreliable. MFT metadata recovery (timestamps, filenames, sizes) is unaffected by TRIM because the MFT is a live file — TRIM only affects deallocated clusters, and the MFT record for a deleted file is in an allocated MFT cluster.

# List files in a directory with their sizes
Get-ChildItem C:\Windows\Temp -File | Where-Object { $_.Length -lt 700 } | 
    Select-Object Name, Length | Sort-Object Length | Format-Table -AutoSize

How MFT records relate to the change journal

The MFT stores the current state of every file. The USN Journal ($UsnJrnl) stores the history of changes to every file. Together, they provide both the "what exists now" and "what happened over time" perspectives that a forensic examination requires.

When a file operation occurs — creation, modification, rename, deletion, security change — NTFS writes two records: it updates the MFT record to reflect the current state, and it appends a USN Journal entry recording the change. The USN entry includes a timestamp, the file's MFT reference number (linking the journal entry to the MFT record), the parent directory's MFT reference number, the reason code (what type of change occurred), and the filename.

This dual recording creates a correlation opportunity that is central to forensic analysis. The MFT tells you the file's current timestamps. The USN Journal tells you when specific changes occurred. If the MFT timestamps have been manipulated (timestomping), the USN Journal entries — which record the actual time each operation occurred — provide independent evidence of the real timeline. If the MFT record has been reallocated (the deleted file's metadata is lost), USN Journal entries may still reference the original file by MFT reference number, providing evidence of operations on a file whose MFT record no longer describes it.

The $LogFile provides a third layer of correlation. It records NTFS transactions at the filesystem driver level — the raw redo/undo operations that implement file creation, modification, and deletion. The $LogFile wraps quickly (typically hours of retention), but during that window, it provides the most granular view of filesystem operations available. When the USN Journal has been cleared by an attacker, the $LogFile may retain evidence of file operations that occurred within its retention window.

The NTFS metadata files

NTFS reserves the first 24-27 MFT records for metadata files — special files that implement the filesystem itself. Forensic examiners encounter these regularly because they are the source of key artifacts:

Record 0 ($MFT) is the MFT itself — the file you extract to analyze all other file metadata. Record 2 ($LogFile) is the transaction log. Record 6 ($Bitmap) tracks cluster allocation. Record 8 ($BadClus) tracks bad clusters (sometimes abused by attackers to hide data in clusters marked as "bad"). Record 9 ($Secure) stores security descriptors. Record 11 ($Extend) is the directory containing extended metadata files, including the USN Journal ($UsnJrnl, which is actually $Extend\$UsnJrnl).

You don't need to memorize these record numbers — MFTECmd identifies them correctly. But understanding that these metadata files are stored as MFT records in the same MFT that stores user files helps you understand why the MFT is self-contained: extracting the $MFT file gives you access to every file's metadata, including the metadata that describes the MFT itself.

Troubleshooting

"I understand databases and file systems generally — why do I need to learn NTFS internals specifically?" Because the forensic artifacts you analyze are NTFS data structures. When MFTECmd reports a "sequence number" of 47, that has specific forensic meaning — the MFT record has been reused 47 times, which means 46 previous files occupied that record before the current one. When it reports "non-resident" data with a specific data run, that tells you exactly which disk clusters to examine for file content recovery. Without NTFS knowledge, these are opaque values. With it, they are forensic evidence.

"Modern forensic tools abstract all of this away." They abstract the parsing away — which is their purpose. They do not abstract the interpretation away. The tool gives you values. You must determine what those values mean for your investigation, whether they are reliable for this specific evidence, and whether they could have been manipulated. That determination requires understanding the NTFS structures that produced those values.

"Does any of this apply to ReFS?" ReFS (Resilient File System) is used on some Windows Server volumes, particularly Storage Spaces Direct. ReFS has a fundamentally different architecture — no MFT, different metadata structures, different timestamp handling. Forensic tool support for ReFS is limited compared to NTFS. This course focuses exclusively on NTFS because it is the filesystem on virtually every Windows workstation, every Windows laptop, every Windows Server boot volume, and every Windows forensic image you will encounter in practice. ReFS forensics is a specialized topic that may be covered in future courses.