$FILE_NAME Attribute

Why $FN timestamps matter

$SI timestamps are updated by the Windows I/O manager through the file system filter stack. Any application that calls SetFileTime(), SetFileInformationByHandle(), or equivalent APIs can modify $SI timestamps. This is by design — applications legitimately set timestamps when extracting archives (to preserve the original file's timestamps), when synchronizing files (to match the source's timestamps), and when performing backup-restore operations. The same API that enables these legitimate uses is what timestomping tools exploit.

$FN timestamps are set by the NTFS driver at the kernel level. When NTFS creates a new file and allocates the MFT record, the driver copies the current system time into both $SI and $FN timestamps. From that point forward, $FN timestamps update only under specific NTFS-internal conditions: file rename (updates $FN Modified and Entry Modified), file move to a different directory (updates $FN Modified), and certain MFT record restructuring operations. Data writes to the file do not update $FN timestamps. The $FN Created timestamp is set once at file creation and almost never changes.

This creates the forensic asymmetry that makes timestomping detectable. When an attacker creates a malicious file at 02:14 on March 18, 2026, and then uses a timestomping tool to set $SI Created to August 2025, the $SI attribute shows August but the $FN attribute still shows March 18. The discrepancy between $SI Created and $FN Created — particularly when $FN Created is later than $SI Created, which cannot happen naturally — is strong evidence of timestamp manipulation.

── $FN content starts at attribute_start + content_offset ──
Offset   Hex                               Decoded
+0x00    05 00 00 00 00 00 03 00   Parent MFT ref: entry=5 seq=3       ◄ Root directory (C:\)
+0x08    80 1A C3 5F 82 A9 D8 01   $FN Created:  2026-03-18 02:13:02   ◄ Set by NTFS driver, not API
+0x10    80 1A C3 5F 82 A9 D8 01   $FN Modified: 2026-03-18 02:13:02
+0x18    80 1A C3 5F 82 A9 D8 01   $FN EntryMod: 2026-03-18 02:13:02
+0x20    80 1A C3 5F 82 A9 D8 01   $FN Accessed: 2026-03-18 02:13:02
+0x28-3F ...                               Alloc size, real size, flags
+0x40    08                             Filename length: 8 characters        ◄ x2 for UTF-16LE bytes
+0x41    03                             Namespace: 0x03 = Win32+DOS          ◄ Short name, single $FN
+0x42    74 00 65 00 73 00 74 00 2E 00 74 00 78 00 74 00  Filename: "test.txt"

The parent directory reference at +0x00 contains a 6-byte MFT entry number (5 = root directory) and a 2-byte sequence number (3). To reconstruct the full path, follow the parent chain: read the parent's MFT entry, read its $FN attribute for the directory name and its parent reference, continue until you reach MFT entry 5 (root). MFTECmd does this automatically in the "ParentPath" column. When it fails (because a parent directory's MFT entry was reallocated), it outputs an incomplete path.

Filename and namespace

At +0x40, one byte contains the filename length in characters (multiply by 2 for UTF-16LE bytes). At +0x41, one byte indicates the namespace: 0x00 POSIX (rare), 0x01 Win32 (long name), 0x02 DOS (8.3 short name), 0x03 Win32+DOS (short enough for both). The filename at +0x42 is UTF-16LE encoded. ASCII characters appear as the character byte followed by 0x00.

Most files have either one $FN attribute (namespace 0x03, when the filename is short enough for DOS compatibility) or two $FN attributes (namespace 0x01 for the Win32 long name and namespace 0x02 for the DOS 8.3 short name). When two $FN attributes exist, each has its own set of four timestamps. In practice, the timestamps in both are typically identical because NTFS sets them at the same time during file creation. However, certain operations can cause them to diverge — this is an edge case worth checking when precision matters.

Hard links create additional $FN attributes. Each hard link adds a $FN attribute with a different parent directory reference and potentially a different filename. The timestamps in each $FN attribute reflect when that hard link was created. The oldest $FN Created timestamp corresponds to the original filename, and newer $FN Created timestamps correspond to hard links added later. The hard link count at record header offset 0x12 tells you how many $FN attributes to expect. If the count is 1, expect one or two $FN attributes (Win32 + optional DOS). If the count is 2 or higher, expect additional $FN attributes for each hard link.

$FN timestamp update behavior

$FN Created: Set once when the file is created. Never updated by normal file operations. Editing the file, changing permissions, moving the file within the same volume, renaming the file — none of these update $FN Created. The only operations that set $FN Created are file creation (new file or copy) and tunnel-cache operations (described below). This makes $FN Created the most stable and reliable timestamp in NTFS. On a file that has not been subject to timestomping or tunnel-cache effects, $FN Created reflects the actual time the file was created on this volume.

$FN Modified: Updated when the file's data is modified AND the parent directory's $INDEX entry is updated to reflect the new size. In practice, this means $FN Modified tracks data changes that change the file's displayed size in the directory listing. Small edits that don't change the allocated size may not trigger a $FN Modified update. Large writes that extend or truncate the file do trigger it. $FN Modified is less frequently updated than $SI Modified because not every data write triggers a directory index update.

$FN Entry Modified: Updated when the MFT record is modified in a way that affects the directory index. This is less frequently updated than $SI Entry Modified — internal MFT changes that don't affect the directory listing don't trigger a $FN Entry Modified update.

$FN Accessed: Follows the same lazy-update rules as $SI Accessed. Disabled by default on Windows 10/11, giving hour-level granularity at best.

The NTFS tunnel cache

One legitimate mechanism can cause unexpected $FN timestamps: the NTFS tunnel cache. When a file is deleted and a new file is created with the same name in the same directory within 15 seconds (the default tunnel cache timeout), NTFS copies the deleted file's $FN timestamps to the new file. This preserves timestamp continuity during save operations where applications delete the original file and write a new one with the same name (a common save pattern in older applications).

The tunnel cache can cause forensic confusion: a file appears to have a $FN Created timestamp from a previous file that occupied the same name. The effect is time-limited (15 seconds) and name-specific (the new file must have the same name as the deleted file in the same directory). It does not affect files created with new names, files created more than 15 seconds after a deletion, or files created in different directories.

For the forensic examiner, the tunnel cache means $FN timestamps are highly reliable but not absolute. When a $FN Created timestamp seems inconsistent with other evidence (particularly when it is older than expected), consider whether the file's name was previously used by another file in the same directory. USN Journal analysis (covered in later modules) can confirm or rule out this scenario by showing the deletion of the previous file and the creation of the new one within the tunnel cache window. The tunnel cache timeout is configurable via the registry key HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\MaximumTunnelEntryAgeInSeconds, though modifying it is extremely rare in production environments.