In this module

The Four NTFS Timestamps

Module 0 · Free

Operational Objective

Every forensic timeline is built from timestamps. An examiner who treats all timestamps as equivalent — "the file was created on March 15" — is making an assumption that may be wrong. NTFS stores eight timestamps per file: four in $STANDARD_INFORMATION and four in $FILE_NAME. These two sets of timestamps are created differently, updated under different conditions, have different modification permissions, and provide different forensic value. An examiner who does not understand these differences will miss timestomping (because they only checked $SI timestamps), produce incorrect timelines (because they assumed a timestamp updates when it doesn't), or make unsupported claims in testimony (because they stated an access time as proof of user activity when the access timestamp was disabled by Windows default settings). This subsection provides the precise behavior of each timestamp — when it is set, what updates it, what does not update it, and what it proves — so that every timestamp reference in every subsequent module rests on an accurate understanding of what the value actually represents.

Deliverable: Complete reference for all eight NTFS timestamps across $SI and $FN attributes: the specific operations that set and update each timestamp, the circumstances under which timestamps do NOT update (including the critical NtfsDisableLastAccessUpdate behavior), the forensic conclusions each timestamp supports, and the comparison methodology that detects timestomping. The MACE acronym decoded with operational precision.

Estimated completion: 35 minutes

Figure WF0.4 — The eight NTFS timestamps compared. $SI timestamps (left) are modifiable by user-mode applications and vulnerable to timestomping. $FN timestamps (right) are set by the NTFS driver and cannot be modified through standard Windows APIs. The $FN Created timestamp is the single most forensically reliable timestamp — set once at file creation, never updated by normal operations.

MACE: what the acronym actually means

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

Modified records the last time the file's content was changed. A write operation that changes the file's data updates this timestamp. Opening a file for reading does not. Renaming a file does not. Changing the file's permissions does not. Only content modification — bytes written to the $DATA attribute — triggers an update. This precision matters: a Modified timestamp of March 15 proves that the file's content was written on March 15. It does not prove that the file was accessed, renamed, or had its permissions changed on March 15.

Accessed records the last time the file was read or executed. In theory. In practice, Windows has disabled automatic last access timestamp updates since Windows Vista (via the NtfsDisableLastAccessUpdate registry value, which is set to 1 by default). When disabled, the Accessed timestamp is only updated when it differs from the current date by more than one hour AND the file is opened. Even then, the update is deferred and batched. The practical result: the Accessed timestamp on most modern Windows systems is unreliable for forensic purposes. It may reflect the last access time, or it may reflect the access time from days or weeks ago, or it may reflect the creation time if the file has never been accessed since creation. Do not cite the Accessed timestamp as evidence of user activity without verifying the NtfsDisableLastAccessUpdate setting on the evidence system.

Created (sometimes called "Birth") records when the file was created on this volume. The behavior during copy and move operations is nuanced: when a file is copied within the same volume, the new file gets a new Created timestamp (the current time). When a file is moved within the same volume, no new MFT record is created (it is a directory index operation only), so the Created timestamp is unchanged. When a file is moved between volumes, a new file is created on the destination (new Created timestamp) and the original is deleted from the source.

Entry Modified records when the MFT record itself was last modified — distinct from when the file's content was modified. Any change to any attribute in the MFT record triggers this update: renaming the file, changing permissions, modifying the $DATA attribute (which also updates Modified), or changing security descriptors. This timestamp is often overlooked but has specific forensic value: if the Entry Modified timestamp is more recent than the Modified and Created timestamps, something changed in the MFT record after the last content write. This could be a permission change, a rename, or — if the gap is suspicious — a timestomping operation that modified $SI timestamps (which changes the record and triggers an Entry Modified update).

$FILE_NAME timestamps: the forensic baseline

The $FILE_NAME attribute contains its own set of four MACE timestamps. These timestamps behave differently from $SI timestamps in two critical ways.

First, $FN timestamps are set by the NTFS driver — the kernel-mode filesystem driver that processes all NTFS operations. User-mode applications cannot directly modify $FN timestamps because there is no public Windows API that accesses them. The SetFileTime() API, which timestomping tools use to modify $SI timestamps, does not touch $FN timestamps. To modify $FN timestamps, an attacker would need to write directly to the raw disk (bypassing the filesystem driver entirely) or use a kernel-mode driver that manipulates NTFS structures. Both are possible but significantly more complex than user-mode timestomping — and both leave additional forensic traces (raw disk write patterns, loaded driver artifacts).

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

Expand for Deeper Context

The discrepancy between $SI and $FN timestamp update behavior is not an accident — it is a design consequence. $STANDARD_INFORMATION timestamps serve the operating system: applications query file timestamps through the Windows API, and the OS updates them to reflect current file state. $FILE_NAME timestamps serve the directory index: they are duplicated in the parent directory's $I30 index for performance (so directory listings don't need to read each file's MFT record). Updating directory index entries for every file operation would create significant performance overhead, so NTFS updates $FN timestamps conservatively.

This design decision — made for performance reasons, not forensic reasons — creates the forensic opportunity: $FN timestamps lag behind $SI timestamps, and they cannot be updated through the standard API. An attacker who uses SetFileTime() to backdate a file's $SI Created timestamp to match other files in the directory succeeds — the $SI timestamp changes. But the $FN Created timestamp still shows the real creation time. The timestamp discrepancy between $SI and $FN is the primary indicator of timestomping, and it is detectable through any tool that reports both sets of timestamps (MFTECmd reports both by default).

One exception to be aware of: NTFS "file name tunneling." When a file is deleted and a new file is created in the same directory with the same name within a short window (default 15 seconds, configurable via the MaximumTunnelEntryAgeInSeconds registry value), NTFS can tunnel the original file's creation timestamp to the new file. This is designed to preserve timestamps during save operations (many applications save by creating a temporary file, deleting the original, and renaming the temporary to the original name). Tunneling affects the $SI Created timestamp and — in some implementations — the $FN Created timestamp. Be aware of this when analyzing files that were recently replaced or overwritten.

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.

Decision point

You find a file where the $STANDARD_INFORMATION Created timestamp is 2025-08-15 09:00:00.0000000 (zero fractional seconds) but the $FILE_NAME Created timestamp is 2026-03-18 02:13:02.3456789 (full nanosecond precision). The $SI timestamp predates the $FN timestamp by 7 months.

Your options: (A) The $SI timestamp is the real creation date — the file was created in August 2025. The $FN timestamp was updated by a system process. (B) The $FN timestamp is the real creation date (March 18, during the intrusion). The $SI timestamp was manipulated (timestomped) to make the file appear older. The zero fractional seconds in $SI are a classic timestomping indicator — legitimate NTFS timestamps have nanosecond precision, but timestomping tools that use SetFileTime() API calls typically set timestamps with zero fractional seconds because the API accepts FILETIME values that most tools construct without fractional precision.

The correct approach is B. The combination of $SI predating $FN (which shouldn't happen in normal operations — $FN is set at creation and rarely changes) and the zero fractional seconds in $SI is a strong timestomping indicator. Document both timestamps and flag the discrepancy.

.\MFTECmd.exe -f "C:\Evidence\$MFT" --csv "C:\Evidence\Output" --csvf mft_output.csv

Try It — Compare $SI and $FN Timestamps in MFTECmd Output

If you have a KAPE collection with an MFT extract (or extract one from your analysis VM as described in WF0.1), parse it with MFTECmd:

Open mft_output.csv in Timeline Explorer. The columns you need:

- Created0x10 — $SI Created timestamp - Created0x30 — $FN Created timestamp - LastModified0x10 — $SI Modified timestamp - LastModified0x30 — $FN Modified timestamp

Exercise 1: Find normal timestamp behavior. Sort by Created0x10 descending to see recently created files. For most files, Created0x10 and Created0x30 will be identical or nearly identical (within the same second). This is normal — both are set at file creation time.

Exercise 2: Find legitimate discrepancies. Filter for files where Created0x10 is significantly earlier than Created0x30. Files that were copied from another location may show this: the copy preserves the original's $SI Created timestamp (the source file's creation time) while the $FN Created timestamp reflects the time the copy was created on this volume. This is a legitimate discrepancy — it indicates a copy operation, not timestomping.

Exercise 3: Identify suspicious discrepancies. Look for files where Created0x10 is much earlier than Created0x30 AND the $SI timestamp has zero or round nanoseconds AND the file is an executable or script. This pattern — backdated $SI, accurate $FN, programmatic precision — is the classic timestomping indicator.

Timestamp behavior during file operations

Understanding how timestamps update during common operations prevents incorrect forensic conclusions. The table below summarizes the behavior for the five most common operations — each cell represents whether the timestamp updates (✓) or does not update (—).

File creation: $SI Created ✓ (current time), $SI Modified ✓ (same as created), $SI Entry Modified ✓ (same), $SI Accessed ✓ (same). $FN Created ✓ (same as $SI), $FN Modified ✓ (same). All timestamps set to the same value at creation.

Content write (no size change): $SI Modified ✓ (updates to write time), $SI Entry Modified ✓ (MFT record changed). $FN Modified — (no size change, no update). Other timestamps unchanged.

Content write (with size change): $SI Modified ✓, $SI Entry Modified ✓. $FN Modified ✓ (size changed, so $FN updates). Other timestamps unchanged.

Rename (same directory): $SI Entry Modified ✓ (MFT record changed — new $FN attribute). $FN attributes replaced (old removed, new added with current timestamps). $SI Modified —, $SI Created —.

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

Compliance Myth: "The last accessed timestamp proves when the user last opened the file"

The myth: The "Date Accessed" field in Windows Explorer (and the corresponding Accessed timestamp in MFT tools) shows when a user last opened a file. If the timestamp shows March 15, the user opened the file on March 15.

The reality: Since Windows Vista (2006), Windows has disabled automatic last access timestamp updates by default (NtfsDisableLastAccessUpdate = 1 in the SYSTEM registry hive). When disabled, the Accessed timestamp is updated lazily — only when the current Accessed timestamp is more than one hour behind the real access time, and even then the update is batched and deferred. On many systems, the Accessed timestamp reflects the creation time because the file has never triggered an update condition since creation. On Windows Server, the behavior may differ (some server configurations enable last access updates). The examiner must check the NtfsDisableLastAccessUpdate value in the evidence system's SYSTEM registry hive before citing Accessed timestamps in any finding. If the value is 1 (default on client Windows), Accessed timestamps should not be used as evidence of user activity. If the value is 0, they are more reliable but still subject to batching delays.

Troubleshooting

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

Operational Artifact — NTFS Timestamp Forensic Reference Card

Timestamp reliability ranking (highest to lowest): 1. $FN Created — set once at file creation, never updated by normal operations, not modifiable via Windows API. 2. USN Journal timestamp — independent record of file operations maintained by NTFS, separate from MFT timestamps. 3. $FN Modified — updates on file size changes, not modifiable via Windows API. 4. $SI Entry Modified — updates on any MFT record change, modifiable via API but rarely targeted by timestomping. 5. $SI Created — modifiable via SetFileTime(), primary timestomping target. 6. $SI Modified — modifiable via API, updates frequently so less useful for historical analysis. 7. $SI Accessed / $FN Accessed — disabled by default since Vista, unreliable on client Windows. Timestomping indicators: (a) $SI Created ≠ $FN Created by more than a few seconds. (b) $SI Created has zero nanoseconds (0000000) when surrounding files have normal sub-second values. (c) $SI Created is earlier than $FN Created (backdating). (d) $SI Entry Modified is within seconds of $SI Created but $SI Modified is months later (the timestomping operation updated both Created and Entry Modified simultaneously). Always document: the NtfsDisableLastAccessUpdate registry value from the evidence system's SYSTEM hive in your examination notes.

During a forensic examination, you find a suspicious executable "svchost_update.exe" in C:\Windows\Temp. MFTECmd reports: $SI Created = 2025-12-01 10:30:00.0000000, $SI Modified = 2026-03-28 14:15:47.3928471, $FN Created = 2026-03-28 14:15:47.3928471, $FN Modified = 2026-03-28 14:15:47.3928471. The USN Journal shows a FILE_CREATE entry for this file at 2026-03-28 14:15:47 UTC. What do the timestamps tell you?

The file was originally created on December 1, 2025 and then modified on March 28, 2026. The $FN Created timestamp matches the modification date because the file size changed on March 28, which updated the $FN timestamp. This is normal file lifecycle behavior.

The file was created on March 28, 2026 at 14:15:47 (confirmed by $FN Created and USN Journal). The $SI Created timestamp was then backdated to December 1, 2025 to make the file appear older and blend with legitimate system files. Two timestomping indicators are present: the $SI Created timestamp has zero nanoseconds (0000000) indicating programmatic timestamp setting, and $SI Created is three months earlier than $FN Created which preserves the real creation time. The $SI Modified was not changed, creating an impossible chronology where the file was apparently modified three months after its claimed creation date — but the real timeline shows creation and first modification occurred simultaneously.

The file was copied from another location on March 28. Copy operations preserve the original file's $SI Created timestamp (December 1) while setting $FN Created to the copy time (March 28). The zero nanoseconds in $SI Created are normal for files created on older Windows systems where timer resolution was lower.

The timestamps are unreliable because the file is in C:\Windows\Temp, which frequently has files created and deleted by Windows Update and other system processes. System processes sometimes set timestamps to specific values for versioning purposes. The examiner should focus on other artifacts rather than timestamp analysis for this file.

You've built the foundations of artifact-level forensic analysis.

WF0 gave you the taxonomy, NTFS architecture, and the five-step methodology. WF1 took you inside the MFT at the binary level — every attribute, every timestamp, every edge case. From here, every artifact category gets the same raw-first treatment.

WF2–WF10: every major Windows artifact decoded at binary level — USN Journal, Prefetch, Amcache, Shimcache, ShellBags, LNK, Jump Lists, SRUM, Event Logs, and the Registry hives
INC-NE-2026-0915 (WF13) — Insider data exfiltration capstone. Work the complete investigation from USB history to OneDrive exfiltration evidence
INC-NE-2026-1022 (WF14) — Ransomware capstone. Three-host triage (FIN01 → IT03 → FS01) across the 72-hour attack chain
The lab pack — 25+ realistic evidence files in 10 formats, simulated KAPE triage pre-populated, both capstones deployable to your own VM
Anti-forensic detection methodology — defeat timestomping, log clearing, and Prefetch deletion with cross-artifact correlation

Unlock with Specialist — £25/mo See Full Syllabus

Cancel anytime

← Previous Next →