$FILE_NAME Attribute

Why $FN timestamps matter

The $FILE_NAME attribute contains its own set of four MACE timestamps that are independent of the $STANDARD_INFORMATION timestamps. Both sets use the same FILETIME format (8-byte, 100-nanosecond precision), but they are updated by different mechanisms and under different conditions.

$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 itself at the kernel level. When NTFS creates a new file and allocates the MFT record, the driver copies the current system time into both the $SI timestamps and the $FN timestamps. From that point forward, $FN timestamps are updated only under specific NTFS-internal conditions: file rename (updates $FN Modified and $FN Entry Modified), file move to a different directory (updates $FN Modified), and certain MFT record restructuring operations. Critically, data writes to the file — opening it, editing it, saving it — do not update $FN timestamps. The $FN Created timestamp, in particular, 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 the $SI Created timestamp to August 15, 2025, the $SI attribute shows August 2025 but the $FN attribute still shows March 18, 2026. The discrepancy between $SI Created and $FN Created — particularly when $FN Created is later than $SI Created, which should never happen naturally — is strong evidence of timestamp manipulation.

The parent directory reference

The first eight bytes of the $FILE_NAME attribute content (offset 0x00) contain the parent directory reference — a pointer to the MFT record of the directory that contains this file. This reference is structured as a 6-byte MFT entry number followed by a 2-byte sequence number, stored in little-endian format.

The entry number identifies which MFT record represents the parent directory. The sequence number identifies which allocation of that MFT record is the parent. This distinction matters when directories are deleted: if you have a file whose parent reference points to MFT entry 500 with sequence number 3, and MFT entry 500 currently has sequence number 5, then the file's parent directory was deleted and MFT entry 500 has been reused twice since then. The parent directory that this file belonged to no longer exists — at least not at that MFT entry.

To reconstruct a file's full path from MFT data, you follow the parent directory chain: read the file's $FN parent reference, look up that MFT entry, read its $FN attribute (which contains the directory's name and its own parent reference), and continue until you reach MFT entry 5 (the root directory). MFTECmd performs this resolution automatically in its "ParentPath" output column. When the resolution fails — because a parent directory's MFT entry has been reallocated — MFTECmd outputs an incomplete or incorrect path.

For the forensic examiner, the parent directory reference provides evidence of where a file was located, independent of the directory structure visible on the live system. A deleted file's MFT record still contains its parent reference. A file that was moved between directories retains its new parent reference, and the old location may be recoverable from USN Journal entries that recorded the move operation. In the insider threat scenario (INC-NE-2026-0915), the parent references on copied files show which directories the departing engineer targeted — even if those directories have been renamed or reorganized since the investigation period.

Filename and namespace

At offset 0x40 in the $FN content, a one-byte field contains the filename length in characters (not bytes — each Unicode character is 2 bytes in UTF-16LE). At offset 0x41, a one-byte field indicates the filename namespace:

0x00 — POSIX: Case-sensitive, allows almost any character including colons and backslashes. Rarely seen on Windows — primarily used by POSIX subsystem applications and WSL.

0x01 — Win32: The standard Windows long filename. Case-preserving but case-insensitive. Maximum 255 characters. Cannot contain certain reserved characters (\ / : * ? " < > |).

0x02 — DOS: The 8.3 short filename. Maximum 8 characters for the name, 3 for the extension. Uppercase only. Generated automatically by NTFS for compatibility with older applications.

0x03 — Win32+DOS: The filename satisfies both Win32 and DOS naming requirements (8 characters or fewer, valid characters, no spaces). Only one $FN attribute is needed because the same name works for both namespaces.

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 short name). When two $FN attributes exist, each has its own set of four timestamps. In practice, the timestamps in both $FN attributes 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.

The filename starts at offset 0x42 and is encoded in UTF-16LE (2 bytes per character). To read it in hex, take pairs of bytes starting at 0x42 and interpret each pair as a Unicode character. For ASCII-compatible characters, the second byte of each pair is 0x00. So the filename "test.txt" appears as 74 00 65 00 73 00 74 00 2E 00 74 00 78 00 74 00 in hex — each ASCII character followed by a null byte.

$FN timestamp update behavior

Understanding exactly when $FN timestamps update (and when they don't) is essential for interpreting them correctly in investigations.

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

$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 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 access-update rules as $SI Accessed (disabled by default on Windows 10/11).

The key forensic takeaway: $FN Created is the most stable 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. It is the timestamp to trust when $SI timestamps are in question.

The NTFS tunnel cache

There is one legitimate mechanism that can cause $FN timestamps to show unexpected values: 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 is designed to preserve 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 practice, the tunnel cache most commonly affects files saved by applications that use delete-and-replace save patterns. 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 that $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 (WF2) 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.

Multiple $FN attributes per record

An MFT record can contain multiple $FILE_NAME attributes. The most common case is a file with both a Win32 long filename and a DOS 8.3 short filename — two $FN attributes, one with namespace 0x01 (Win32) and one with namespace 0x02 (DOS). Files with short names that fit DOS requirements have a single $FN attribute with namespace 0x03 (Win32+DOS).

When walking the attribute chain in hex, don't stop at the first $FN attribute. Continue walking and collect all $FN attributes. Compare the timestamps across them — they should be identical under normal conditions. If they differ, the file has undergone an unusual operation that updated one $FN attribute without the other, which is forensically interesting.

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 particular hard link was created. This means a hard-linked file can have $FN attributes with different timestamps — 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 in the MFT record header (offset 0x12) tells you how many $FN attributes to expect. If the hard link count is 1, expect one or two $FN attributes (Win32 + optional DOS). If the hard link count is 2, expect an additional $FN attribute for the hard link. If the hard link count is higher, the file has multiple hard links and the $FN attributes reveal where each link points.