NTFS Architecture and Timestamps

The Master File Table: one record per file

NTFS organizes all file metadata in the Master File Table. Every file and directory on an NTFS volume has at least one MFT record. Each record is exactly 1024 bytes on standard configurations. 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 "FILE" signature, the sequence number (tracking how many times the record has been reused), the hard link count, flags indicating whether the record is in use and whether it represents a directory, and the offset to the first attribute.

The MFT grows dynamically as files are created, allocating from the MFT Zone (typically 12.5% of the volume). The MFT does not shrink. Once a record is allocated, it remains allocated even after the file is deleted. Deleted files have their records marked as "not in use" but the record itself, including all attributes, timestamps, and potentially resident file content, remains intact until reallocated. On a 256GB SSD with typical enterprise usage, a deleted file's MFT entry may persist for weeks to months. This is why MFT analysis can recover metadata for deleted files.

This is what the first 32 bytes of an MFT record look like in a hex editor. Every concept described above maps to specific byte offsets:

Offset   Hex                                        ASCII
0x0000   46 49 4C 45 30 00 03 00  C8 A4 0B 00 00 00 00 00   FILE0...........
0x0010   01 00 01 00 38 00 01 00  A0 01 00 00 00 04 00 00   ....8...........
         │     │     │     │
         │     │     │     └─ Flags: 0x01 = in use (0x00 = deleted)
         │     │     └─ First attribute offset: 0x38 (56 bytes in)
         │     └─ Link count: 1 hard link
         └─ Sequence number: 1 (first use of this MFT entry)

The "FILE" signature at offset 0x00 identifies a valid MFT record. The sequence number at 0x10 increments each time the entry is reused for a different file. The flags at 0x16 tell you whether the record is in use (0x01) or deleted (0x00). The first attribute offset at 0x14 tells you where to start reading attribute data. When MFTECmd parses this record, it reads these exact bytes. When you verify MFTECmd's output in a hex editor, these are the bytes you check.

Attributes: where forensic evidence lives

Every piece of metadata in an MFT record is stored in an attribute. Five attribute types are forensically significant.

$STANDARD_INFORMATION (type 0x10) is present in every MFT record. It contains four timestamps (created, modified, MFT entry modified, accessed), file permission flags, the owner's security ID, and the update sequence number. This is the attribute that MFTECmd's primary timestamp columns come from. Critically, $SI timestamps can be modified by any process with write access to the file. The Windows API function SetFileTime() sets the $SI timestamps to arbitrary values. Timestomping tools use this API. There is no warning in the MFT record itself that the timestamps have been modified.

$FILE_NAME (type 0x30) contains the filename, the parent directory reference, the file size, and its own set of four timestamps. The $FN timestamps are set by the NTFS driver when the file is created. The $FN creation timestamp is set once and never changes. The key forensic principle: $FN timestamps cannot be modified by user-mode applications. SetFileTime() modifies $SI timestamps but not $FN timestamps. This makes $FN timestamps the forensically reliable reference point for detecting timestomping.

$DATA (type 0x80) stores file content. If the content fits within the MFT record (approximately 700 bytes or less), it is stored "resident." This is forensically significant because resident file content is captured by any MFT extraction, even for deleted files. 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 content is recoverable from the MFT alone.

If content exceeds the resident threshold, it is stored "non-resident" with a data run list mapping logical file offsets to physical disk clusters. Multiple data runs indicate fragmentation. When a non-resident file is deleted, its clusters are marked as available in $Bitmap but the data persists until overwritten.

Alternate Data Streams (ADS) are additional named $DATA attributes. A file can have its default unnamed $DATA attribute plus named streams containing hidden data. The classic example is malware stored in an ADS: legitimate.txt:malware.exe. The text file's properties appear normal. The ADS is only visible through specific tools or commands. MFTECmd reports ADS when parsing the MFT, which is one reason MFT analysis catches evidence that directory listing misses.

$INDEX_ROOT / $INDEX_ALLOCATION (types 0x90/0xA0) implement directory B-tree indexes. When a file is deleted from a directory, its index entry is removed from the active B-tree but often persists in the index slack space, including the filename and timestamps. This $I30 slack provides evidence independent of the deleted file's own MFT record.

Cluster allocation and data recovery

NTFS divides volumes into clusters (typically 4096 bytes). The $Bitmap file tracks allocation. When a file is deleted, clusters are marked as free but the data persists until another file is allocated those clusters. This is the basis of deleted file recovery on traditional hard drives.

SSDs fundamentally change this. The TRIM command, enabled by default since Windows 7, instructs the SSD controller to erase the flash cells underlying deallocated clusters. After TRIM, content is physically erased, not merely marked as free. The window between deletion and TRIM execution varies from milliseconds to hours. For forensic purposes: treat deleted file content recovery on SSDs as unreliable. MFT metadata recovery (timestamps, filenames, sizes) is unaffected because the MFT is a live file and TRIM only affects deallocated clusters.

Common analysis issues

"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 entirely 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.

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 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.

MACE: what the acronym actually means

MACE stands for Modified, Accessed, Created, Entry Modified. It is a forensic community shorthand for the four timestamps in $STANDARD_INFORMATION. The order reflects the fields' offset positions within the attribute, not their importance.

Modified records the last time the file's content was changed. Only content modification triggers an update. Opening for reading does not. Renaming does not. Changing permissions does not. A Modified timestamp of March 15 proves content was written on March 15. It does not prove the file was accessed, renamed, or had permissions changed on that date.

Accessed records the last time the file was read or executed. In theory. Since Windows Vista, Windows has disabled automatic last access timestamp updates by default (NtfsDisableLastAccessUpdate = 1). The Accessed timestamp is only updated when it differs from the current date by more than one hour, and even then the update is deferred and batched. On most modern Windows systems, this timestamp is unreliable for forensic purposes. Do not cite the Accessed timestamp as evidence of user activity without verifying the NtfsDisableLastAccessUpdate setting on the evidence system.

Created records when the file was created on this volume. Copy and move behavior is nuanced: copying within the same volume gives the new file a new Created timestamp. Moving within the same volume is a directory index operation only, so Created is unchanged. Moving between volumes creates a new file on the destination (new timestamp) and deletes the original.

Entry Modified records when the MFT record itself was last modified. Any attribute change triggers an update: rename, permissions, $DATA modification, security descriptors. If Entry Modified is more recent than Modified and Created, something changed in the record after the last content write. This could be a permission change, a rename, or a timestomping operation.

$FILE_NAME timestamps: the forensic baseline

$FN timestamps are set by the NTFS kernel-mode driver. User-mode applications cannot modify them because no public Windows API accesses them. SetFileTime() modifies $SI timestamps but does not touch $FN timestamps. To modify $FN, an attacker would need raw disk access or a kernel driver, both significantly more complex than user-mode timestomping and both leaving additional forensic traces.

$FN timestamps update under narrower conditions than $SI. The $FN Created timestamp is set when the file is created and is never updated by normal operations. This makes it the single most reliable timestamp for determining when a file first appeared on the volume. The $FN Modified timestamp updates only when the file's size changes. The $FN Accessed timestamp follows the same deferred behavior as $SI Accessed and is similarly unreliable.

The discrepancy between $SI and $FN update behavior is a design consequence, not an accident. $SI timestamps serve the operating system: applications query and update them. $FN timestamps serve the directory index: they are duplicated in the parent directory's $I30 for performance, and updating directory indexes for every file operation would create significant overhead. This performance-driven design creates the forensic opportunity: $FN timestamps lag behind $SI, and they cannot be modified through the standard API.

One exception: NTFS file name tunneling. When a file is deleted and a new file is created in the same directory with the same name within 15 seconds, NTFS can tunnel the original file's creation timestamp to the new file. This preserves timestamps during save operations (applications that save by creating a temp file, deleting the original, and renaming). Tunneling affects $SI Created and sometimes $FN Created. Be aware of this when analyzing files that were recently replaced.

In practice, you compare these timestamps in MFTECmd's CSV output opened in Timeline Explorer. Here are four records showing normal behavior and one showing timestomping:

FileName                  Created0x10 ($SI)           Created0x30 ($FN)           Delta
report_q3.docx            2026-03-10 14:22:18.4731284 2026-03-10 14:22:18.4731284 0s     ◄ Normal
budget_final.xlsx         2026-03-10 14:22:19.1028447 2026-03-10 14:22:19.1028447 0s     ◄ Normal
meeting_notes.pdf         2026-02-15 09:47:33.8812956 2026-03-10 14:22:20.5539012 -23d   ◄ Copy (original created Feb 15)
svchost_update.exe        2025-08-15 09:00:00.0000000 2026-03-18 02:13:02.3456789 -215d  ◄ TIMESTOMPED

The first two files have identical $SI and $FN Created timestamps with normal nanosecond precision. That is normal behavior for files created on this volume. The third file has $SI Created earlier than $FN Created by 23 days, with normal precision in both. That is a legitimate copy artifact: the copy preserved the original's $SI Created timestamp while $FN reflects the copy time. The fourth file has $SI Created 215 days earlier than $FN Created with zero nanoseconds (.0000000). Both indicators together (massive delta plus zero fractional) make this a strong timestomping finding.

Timestamp precision and timestomping detection

NTFS timestamps are 64-bit FILETIME values representing 100-nanosecond intervals since January 1, 1601 UTC. This sub-second precision is forensically valuable in two ways.

First, it provides ordering. Two files created within the same second can be ordered by nanosecond components. A staging directory with files copied at 14:22:18.4731284 and 14:22:18.6892103 can be sequenced even though both show "14:22:18" at second-level precision.

Second, nanosecond precision is a timestomping indicator. Most timestomping tools set timestamps using the Windows API with FILETIME values constructed without fractional precision. A file with $SI Created of 2026-01-15 09:00:00.0000000 (zero fractional component) surrounded by files with timestamps like 2026-01-15 08:47:23.4827193 (normal variation) is suspicious. Zero fractional seconds suggest programmatic timestamp setting rather than genuine file operation.

Timestamp behavior during file operations

Understanding how timestamps update during common operations prevents incorrect conclusions.

File creation: All eight timestamps set to the same value. $SI and $FN are identical at creation.

Content write (no size change): $SI Modified and $SI Entry Modified update. $FN Modified does not (no size change). This divergence is normal and expected.

Content write (with size change): $SI Modified, $SI Entry Modified, and $FN Modified all update.

Rename (same directory): $SI Entry Modified updates. $FN attributes are replaced (old removed, new added with current timestamps). $SI Modified and $SI Created are unchanged.

Delete: No timestamp updates. The MFT record's in-use flag is cleared. All timestamps remain at their last values. The USN Journal records the deletion with its own independent timestamp.

Common analysis issues

"How do I check whether last access timestamps were enabled on the evidence system?" Extract the SYSTEM registry hive and open it in Registry Explorer. Navigate to SYSTEM\CurrentControlSet\Control\FileSystem. Look for the value NtfsDisableLastAccessUpdate. If the value is 1 (or absent. The default is disabled), last access timestamps are unreliable. If the value is 0, they were enabled. Note: on Windows 10 1809 and later, the value might be 0x80000003 (a combined value where the high bit indicates user-mode control). The forensic implication is the same. Check the actual value and document it.

"If both $SI and $FN timestamps are set to the same value at creation, how do I detect timestomping?" After creation, the two sets diverge during normal operations. $SI timestamps update frequently (every content write, every attribute change). $FN timestamps update rarely (only on size changes and renames). A file that has existed for weeks will typically show $SI Modified ≠ $FN Modified (because content was written without size changes). A timestomped file often shows $SI Created much earlier than $FN Created. The attacker backdated $SI but couldn't modify $FN. The key comparison is $SI Created vs $FN Created for detecting backdating, and the nanosecond fractional component for detecting programmatic timestamp setting.

"What if the attacker uses a kernel driver to modify $FN timestamps?" A kernel-mode driver with raw disk access can modify any byte on the volume, including $FN timestamps. This is a sophisticated attack that eliminates the $SI/$FN comparison indicator. However, the kernel driver itself leaves forensic traces: Event Log records of driver loading (System log, Event ID 7045 for service-type drivers), Sysmon Event ID 6 (driver loaded), registry persistence for the driver, and the driver file itself in the MFT. Additionally, the USN Journal still records the original file creation time independently of both $SI and $FN timestamps. Multi-artifact correlation catches what single-artifact analysis misses.

Timestamp precision and its forensic value

NTFS timestamps are stored as 64-bit Windows FILETIME values representing 100-nanosecond intervals since January 1, 1601 UTC. This gives NTFS timestamps a theoretical precision of 100 nanoseconds. 0.0000001 seconds. In practice, the actual precision depends on the system timer resolution and the operation type, but NTFS routinely records timestamps with sub-second precision.

This precision is forensically valuable in two ways. First, it provides ordering: two files created within the same second can often be ordered by their nanosecond components. A staging directory containing files copied at 14:22:18.4731284 and 14:22:18.6892103 can be placed in creation order even though both show "14:22:18" at second-level precision. This ordering can establish the sequence of attacker operations during rapid file staging.

Second, nanosecond precision is a timestomping detection indicator. Most timestomping tools set timestamps using the Windows API, which typically sets the fractional seconds to zero or to round values. A file with a $SI Created timestamp of 2026-01-15 09:00:00.0000000 (all zeros in the fractional component) surrounded by files with timestamps like 2026-01-15 08:47:23.4827193 (normal sub-second variation) is suspicious. The zero fractional component suggests the timestamp was set programmatically rather than generated by a genuine file operation. This indicator is not definitive. Some legitimate operations produce round timestamps. But combined with $SI/$FN discrepancy, it strengthens the timestomping assessment.