Analysis of the MFT $STANDARD INFORMATION and $FILENAME Attributes

 

Among the various types of digital evidence, temporal footprints are especially valuable because they enable investigators to confirm the time of an intrusion and reconstruct the sequence of events surrounding an incident. In NTFS, two attributes within the Master File Table (MFT) store the timestamps: the $STANDARD_INFORMATION ($SI) attribute and the $FILE_NAME ($FN) attribute.

All timestamps stored in the NTFS $STANDARD_INFORMATION ($SI) and $FILE_NAME ($FN) attributes are encoded as Windows FILETIME values. A FILETIME value represents the number of 100-nanosecond intervals elapsed since January 1, 1601, 12:00 A.M. (UTC). Because they are stored in UTC, these timestamps are not affected by local time zones or daylight saving time (DST). NTFS timestamps have a theoretical resolution of 100 nanoseconds. Both $SI and $FN provide four timestamp values commonly referred to as MACB, representing the following events:

• Modified – signifies when the content of the file is last updated.
• Accessed – refers to the last time of access to the contents, but in versions of Windows from Vista and up, updates to this timestamp are turned off by default.
• Changed— refers to changes to the file metadata—its name, security attributes, and so on (i.e., changes to the MFT entry).
• Birth— refers to the time at which the MFT entry was created. This attribute receives a lot of attention, but it is in contrast with the natural world, it actually means very little for a file to be “born”; its content may be completely replaced afterwards and its name, location, and security attributes may change. For practical purposes, its identity may have completely changed since its “birth”. The timestamp is not even tied to a particu lar MFT entry; moving files between file systems can result in copying the birth timestamp to a completely new entry. This begs the question of what the birth time is supposed to signify. Especially when file content is of an incriminating nature, us ing only the birth timestamp as definite proof of creation of the content at the signified time is highly questionable.

There is considerable confusion caused by different nomenclature lineages in forensic filesystem analysis. MACB is an extension of the MAC timestamps found on most traditional Unix-like systems, as displayed by the stat command. The terms are used in Forensic Discovery by Dan Farmer and Wietse Venema, which mainly deals with Unix-like systems, and Carrier’s work, and in the open source TSK filesystem analysis suite which is closely connected to both of these works. Some other forensic suites apply a different nomenclature. For instance, EnCase (by Guidance Software) uses ‘MACE’; for Modification, Access, Creation and “Entry Modified”. MACE’ has an edge on ‘MACB’ since in the MACB nomenclature, the terms ‘change’ and ‘modification’—concepts used interchangeably in everyday-language—actually have very different meanings. Some may find the following moniker to be of use when working with the MACB nomenclature: chAnge refers to metAdata, mOdification refers to cOntent.

The modification (M), access (A), and creation (B) timestamps of a file or directory are easily accessible through the Windows Explorer “Properties” dialog. These values are retrieved from the $STANDARD_INFORMATION ($SI) attribute. The fourth timestamp—the metadata change time (C)—is not shown to users and is generally hidden at the GUI level.

The timestamps stored in the $FILE_NAME ($FN) attribute are not directly visible to users and are not guaranteed to match those in $SI. When a file is created, all four timestamps in both $SI and $FN are initialized to the same values. However, while $SI timestamps may be updated by normal file operations (e.g., modifying content, accessing the file, or changing metadata), the timestamps in $FN are not directly updated by these actions. Instead, $FN timestamps are only refreshed when the $FN attribute itself changes, such as during file creation, copying, moving, renaming, or hard-link operations. In these cases, the operating system overwrites the existing $FN timestamps with the current values from $SI. Because Windows provides no API for directly modifying $FN timestamps, they are significantly more difficult to forge than the $SI timestamps presented to the user.

The $STANDARD_INFORMATION Attribute

Figure 1: The STANDARD_INFORMATION attribute hex dump

Following the MFT header for an MFT entry (in this case, MFT entry 24102) is the $STANDARD_INFORMATION attribute. This attribute is always resident. The attribute ID for this attribute is 0x10 00 00 00. The first part of this attribute follows a regular pattern known as the attribute header, which is 24 bytes long in this case. 

The bytes at offsets 0x38-0x3B make up the four-byte identifier for this attribute. These attribute IDs are defined in the $AttrDef metadata file.  Bytes 0x3C-0x3F define the length of this attribute. This conforms with the common practice of defining the length of an entry immediately following the identifier. The length shown here (endian reversed) is 0x00000060, which is 96 decimal. An inspection of Figure 1 above shows that 96 bytes from the beginning of this attribute (offset 0x38), at byte offsets 0x98-0xA1, are the four values 0x30000000. These are a set of four bytes that should be another attribute ID. In this case, it is the ID for a FileName Attribute, which is a valid entry, as we will see later.

At byte 0x40 is the resident/non-resident flag. This is signified by 0x00 for a resident attribute and 0x01 for a non-resident attribute. The flag refers to the body of the attribute itself. Other attributes will have similar headers, in which each attribute will be defined as resident or non-resident. The next byte, at offset 0x41, indicates the length of the attribute name. In this case, the length is zero, since this attribute is not allocated a name.

The bytes at offsets 0x42-0x43 indicate the offset value to the start of the attribute content. These are not always used, as in this case, where they are shown as 0x0000. The bytes at offset 0x44-0x45 are identified as a set of flags that signify the following states: 0x0000 = normal, 0x0100 = compressed, 0x4000 = encrypted, and 0x8000 = sparse. It may well be the case that this field is included in the Attribute Header for use only with a $DATA Attribute.

The purpose of the bytes at offsets 0x46-0x47 is unclear. Some sources suggest they are used as some form of attribute ID. Exploration of other MFTs suggests that these may be used for some purposes that have not yet been sufficiently well identified by the writer. Part of the field may be used as a flag to show malware-infected and malware-cleaned files.

The four bytes from offset 0x48-0x4B define the length of the attribute content. In this case, the value is 0x00000048 (endian reversed), which is 72 bytes in decimal. This attribute header is 24 bytes long, and the complete attribute, including this header, is defined at bytes 0x3C-0x3F as 96 bytes. The value of the attribute content should therefore be 96 – 24 = 72, which is what is stored here. 

The next two bytes, at offsets 0x4C-0x4D, indicate the offset from the beginning of this attribute to the start of the attribute proper. This is where the Standard Information attribute details start, after the header that is currently being deconstructed. The value is 0x0018, which equals 24 decimal. Noting from the figure above that the start offset for this attribute is 0x38, then the attribute content starts at offset 0x38 + 0x18 = 0x50.

Byte offset 0x4E is reported to be the “indexed” flag, and byte offset 0x4F is reported to be padding to an 8-byte boundary.

The $STANDARD_INFORMATION Attribute Content

The first 32 bytes of this attribute content from byte offset 0x50-0x6F in Figure 1 above refer to four dates and times.  The values stored in these bytes are in a format known as a “FILETIME,” which we mentioned earlier. This is a 64-bit number (held here in little-endian format) that represents the number of 100-nanosecond intervals that have elapsed since 00:00:00 GMT on 1 January, 1601. The date and time values in these 32 bytes are decoded as follows.

• Byte offsets 0x50 - 0x57 → Create date and time → 2014-03-18 09:49:57.3083968 UTC.
• Byte offsets 0x58 - 0x5F → Last Modified date and time → 2014-03-18 09:49:57.3083968 UTC.
• Byte offsets 0x60 - 0x67 → Last MFT Record Change date and time → 2015-12-12 02:19:47.0810831 UTC.
• Byte offsets 0x68 - 0x6F → Last Access date and time → 2014-03-18 09:49:57.3083968 UTC.

Byte offsets 0x70-0x73 are used for file permission flags, which are similar to the FAT attribute byte in a directory entry. This attribute byte system, in the style of MS-DOS, is used on byte offset 0x70, with further attributes being set by byte offset 0x71. It is understood that the byte offsets 0x72 and 0x73 are reserved for similar use. In this case 0x00400020 (endian reversed) represents a file with the Archive bit set and not locally resident.

Flag Value	Description
0x00000001	Read only. A file that is read-only. Applications can read the file but cannot write to it or delete it.
0x00000002	Hidden. The file or directory is hidden. It is not included in an ordinary directory listing.
0x00000004	System. A file or directory that the operating system uses a part of or uses exclusively.
0x00000010	Directory. The handle that identifies a directory.
0x00000020	Archive. A file or directory that is an archive file or directory. Applications typically use this attribute to mark files for backup or removal
0x00000040	Device. Reserved for system use
0x00000080	Normal. A file that does not have other attributes set. This attribute is valid only when used alone.
0x00000100	Temporary. A file that is being used for temporary storage.
0x00000200	Sparse_File. A file that is a sparse file
0x00000400	Reparse_Point. A file or directory that has an associated reparse point, or a file that is a symbolic link.
0x00000800	Compressed. A file or directory that is compressed. For a file, all the data in the file is compressed. For a directory, compression is the default for newly created files and subdirectories.
0x00001000	Offline. The data of a file is not available immediately. This attribute indicates that the file data is physically moved to offline storage.
0x00002000	Not_Content_Indexed. The file or directory is not to be indexed by the content indexing service.
0x00004000	Encrypted. A file or directory that is encrypted. For a file, all data streams in the file are encrypted. For a directory, encryption is the default for newly created files and subdirectories.
0x00008000	Integrity Stream. The directory or user data stream is configured with integrity (only supported on ReFS volumes).
0x00010000	Virtual. Reserved for system use
0x00020000	No_Scrub_Data. The user data stream not to be read by the background data integrity scanner (AKA scrubber). When set on a directory it only provides inheritance. This flag is only supported on Storage Spaces and ReFS volumes.
0x00040000	Recall_On_Open. When this attribute is set, it means that the file or directory has no physical representation on the local system; the item is virtual.
0x00400000	Recall_On_DataAccess. When this attribute is set, it means that the file or directory is not fully present locally.
0x10000000	Directory. Copy from corresponding bit in MFT record header flag (IS_DIRECTORY)
0x20000000	Index_View. Copy from corresponding bit in MFT record header25 flag (IS_VIEW_INDEX)

 Byte offsets 0x74 - 0x77 are said to be allocated for “Maximum Number of Versions.” When zero, as here, it is understood that version numbering is disabled. This field is thought to be associated with network security, where there are multiple users and multiple files.

 Byte offsets 0x78-0x7B are described as a “Version Number,” and byte offsets 0x7C-0x7F as a “Class ID.”  If the ‘Maximum Number of Versions’ is 0 (0x00000000), Maximum Versions is disabled, and so is the ‘Version Number.’ Since Windows 10 version 180320, part of the ‘Version Number’ bytes (specifically the first byte, 0x78 in our sample case) has been used for the “Is Case Sensitive” flag. A value of 1 means that the directory is case sensitive. Since Windows 10 version 1809, part of the ‘Version Number’ bytes (specifically the second byte, 0x79 in our sample case) has been used for the “Reserve Storage ID” flag. Possible ‘Reserve Storage ID’ values include:

Hex	Reserve ID	Use
00	None	The file or directory is not associated with any particular storage reserve area.
01	Hard	Used by the system to help ensure there is sufficient disk space to download and install updates.
02	Soft	Used by the system to help ensure there is sufficient disk space to install updates.
03	Max	Marks the limit of predefined storage reserve IDs currently understood by the system.

The Reserve Storage IDs can be queried on a live system as follows. It will show the reserved space for each Storage Reserve ID.

Figure 2: Reserve storage ID on a live system

To get a list of MFT file records associated with a specific Storage Reserve ID, enter the following command.

fsutil storagereserve FindById c: X
//where X is either 1, 2, or 3

It is claimed that byte offsets 0x80-0x83 are the “Owner ID.” No relevant records were found in our test MFT.  Byte offsets 0x84-0x87 are understood to be a “Security ID”. The Security ID here has no relation to the SID used in Windows to track the user. It is claimed that byte offsets 0x88-0x8F are the “Quota Charged.” The MFT was parsed for any non-zero values in these bytes, but no relevant records were found. If it has a value of zero, as seen here, then it is understood that quotas are disabled.

It is claimed that byte offsets 0x90-0x97 are the “Update Sequence Number” for the file $USNJRNL. The MFT was searched for any non-zero values in these bytes, but no relevant records were found. When it has a value of zero, as seen here, likely, the $USNJRNL function has not been activated.

Windows Time Rules

NTFS maintains dual timestamp repositories within each Master File Table (MFT) record: the $STANDARD_INFORMATION ($SI) attribute, which is user-mode accessible and modifiable, and the $FILE_NAME ($FN) attribute, which is kernel-enforced and significantly more resistant to direct manipulation. These attributes record four temporal values each—Modified (M), Accessed (A), Creation/Birth (B/C), and MFT Entry Modified (C/E)—yielding up to eight (or more, when considering $I30 directory index entries) forensic timestamps per file. As empirical testing demonstrates, these sets are updated asynchronously depending on the operation and interface. 

Figure 3: Windows time rules by SANS DFIR

The above figure delineates the predominant behavioral patterns for files (distinct from directories) under common operations—creation, modification, access, copying, moving (intra- and inter-volume), and renaming—specifically for the $STANDARD_INFORMATION attribute, as observed through Windows File Explorer and the native cmd.exe command interpreter. The corresponding $FILE_NAME attribute behaviors will be discussed later in this post.

These observations derive from controlled experimentation on Windows environments and should be regarded as probabilistic heuristics rather than immutable axioms. While highly consistent across legacy and contemporary Windows 10/11 builds, deviations arise due to ongoing kernel and shell refinements, application-specific I/O patterns (e.g., safe-save mechanisms inducing file tunneling), caching behaviors, and registry-controlled modifiers such as last-access update policies. Notably, beginning with Windows 10 version 1803, the NtfsDisableLastAccessUpdate registry value (and its successor bitfield/system-managed policies incorporating volume size thresholds) permits re-enablement of last-access timestamp updates under defined conditions, potentially restoring more granular A-time tracking.

A further critical caveat pertains to the Windows Subsystem for Linux (WSL). Operations executed via the WSL Bash shell (or equivalent Linux binaries) frequently diverge from native Windows timestamp semantics, often resulting in full synchronization or distinct inheritance patterns for $SI and $FN attributes. Forensic practitioners are advised to consult Richard Davis’s comprehensive empirical testing in the “13Cubed” series, wherein—approximately 23 minutes into the relevant episode—he systematically demonstrates that WSL file manipulations (e.g., cp, mv) do not conform to conventional Windows Explorer or cmd.exe rules.

While the inherent variability and edge cases in NTFS temporal mechanics can complicate timeline reconstruction, empirically validated rules achieving approximately 95% fidelity remain indispensable for inferring likely sequences of events. Digital forensic analysts should apply these heuristics judiciously to corroborate or refute hypotheses, while remaining vigilant for anomalies arising from anti-forensic tools (which predominantly target $SI), third-party applications, PowerShell discrepancies, file system tunneling, or cross-filesystem interactions. Cross-validation against ancillary artifacts—such as the USN Change Journal, Prefetch files, $LogFile, and $I30 index records—is essential to mitigate interpretive errors and strengthen evidentiary conclusions.

This nuanced understanding of NTFS temporal dynamics underpins robust timeline analysis and timestamp anomaly detection in intrusion, data exfiltration, or intellectual property investigations.

The $FILE_NAME Attribute

Figure 4: Hex dump of the $FILE_NAME attribute 

As enumerated in the $AttrDef metadata file, the attribute adheres to strict size constraints: a minimum of 68 bytes and a maximum of 578 bytes. This ceiling accommodates a filename of up to 255 Unicode (UTF-16LE) characters, excluding the null terminator. The variable-length structure permits multiple $FILE_NAME attributes within a single MFT record to support distinct namespaces (POSIX, Win32, DOS 8.3, or Win32+DOS) and to implement POSIX-style hard links, each potentially referencing different parent directory file references.

The attribute header, located at byte offsets 0x98–0xB7 in the above diagram (Figure 4), conforms precisely to the standard NTFS attribute header format previously examined (Figure 1). This includes the type code, record length, residency flag (always resident for $FILE_NAME), name length/offset (typically zero for unnamed instances), flags, instance identifier, and the resident value structure commencing with the 8-byte parent directory file reference.

• Bytes 0x98-0x9B → Attribute ID → 0x300000.
• Bytes 0x9C-0x9F → Length of Attribute → 0x00000078 = 120 (from byte offset 0x98-0x10F).
• Byte 0xA0 → Resident/Non-resident flag → 0x00 = resident
• Byte 0xA1 →    Length of name of attribute → 0x00 = no name
• Byte 0xA2-0xA3 → Offset to start of attribute content → 0x0000 = not used
• Byte 0xA4-0xA5 → Flags → 0x0000 = normal.
• Byte 0xA6-0xA7 → Not known → 0x0003.
• Byte 0xA8-0xAB → Length of attribute content → 0x0000005A = 90.
• Byte 0xAC-0xAD → Offset to the start of attribute content → 0x0018 = 0x98 + 0x18 = 0xB0.
• Byte 0xAE → Indexed flag → 0x01 = indexed.
• Byte 0xAF → Padding to an 8-byte boundary    →    0x00

The FILE_NAME Attribute Content

Starting from byte offset 0xB0 is the FileName attribute content. The first 8 bytes of the attribute are a reference to the parent directory. We note that the value in these first six bytes is 0x000000000538, which is equivalent to 1336 in decimal. This is the record number of the directory \Program Files\WindowsApps\DeletedAllUserPackages\Microsoft.SkypeApp_2.5.0.1005_neutral_split.scale-140_kzf8qxf38zg5c\images\scale-140\emoticons\30\ in which this file appears. The subsequent two bytes, 0x0001, denote the sequence number for that MFT record.

At absolute offset 0xB8-0xD7 within the attribute content, in our sample figure, begins an additional, independent quartet of MACB timestamps (Modified, Accessed, Creation/Birth, and MFT Entry Modified). These temporal values reside in the $FILE_NAME attribute and exhibit markedly divergent update semantics compared to their counterparts in the $STANDARD_INFORMATION ($SI) attribute.

• Byte offset 0xB8-0xBF → Create date and time → 2015-12-12 02:06:53.0318729 UTC.
• Byte 0ffset 0xC0-0xC7 → Last Modified date and time → 2015-12-12 02:06:53.0318729 UTC.
• Byte 0ffset 0xC8-0xCF → Last MFT Record Change date and time → 2015-12-12 02:06:53.0318729 UTC.
• Byte 0ffset 0xD0-0xD7 → Last Access date and time → 2015-12-12 02:06:53.0318729 UTC.

The precise design rationale for maintaining this duplicate set remains incompletely documented by Microsoft; however, empirical forensic analysis indicates that $FN timestamps are predominantly updated by the NTFS kernel during operations that modify the file’s namespace or directory index entry (such as creation, copying, intra- or inter-volume moves, and renaming). In contrast, $SI timestamps respond more readily to user-mode file I/O, content modification, and access events. This architectural separation enhances the evidentiary value of the $FN set, as it is substantially more resistant to direct manipulation by conventional user-mode anti-forensic utilities.

While the exact behavioral triggers continue to warrant further empirical validation across Windows versions, this duality frequently confers a tactical advantage to digital forensic examiners. Discrepancies between the $SI and $FN timestamp sets serve as reliable indicators of timestomping, anomalous file operations, or the use of tools that target only the more accessible $SI values. A comprehensive comparative analysis of both timestamp repositories—often augmented by $I30 index records—enables more robust timeline reconstruction, detection of deception, and validation of hypothesized file system activity sequences.

Absolute offsets 0xD8-0xDF, in our sample figure, are an 8-byte little-endian integer representing the allocated size of the file (the on-disk space reserved for the unnamed $DATA attribute, always a multiple of the cluster size). In the examined sample, this value is 0x0000000000000000 (0 bytes), consistent with an empty or metadata-only file. Immediately following, at byte offsets 0xE0–0xE7, resides the 8-byte logical (real) size of the file—the actual byte length of the file’s data content as reported to applications and directory listings. Here too, the value is 0x0000000000000000 (0 bytes).

Byte offsets 0xE8-0xEB are stated to be "Flags". These are similar to the FAT attribute byte in a directory entry, in the style of MS-DOS. We discussed these kinds of flags when we examined byte offsets 0x70-0x73 for the STANDARD_INFORMATION attribute. The values that they can take are identical to those discussed in the STANDARD_INFORMATION attribute. In this case, 0x20 00 00 00 represents a file with the Archive bit set. 

Byte offsets 0xEC-0xEF are reportedly used by extended attributes and reparse points. A search of the volume did not reveal any relevant records with non-zero entries at this location.

At absolute offset 0xF0, in our sample, is a single-byte field denoting the length of the filename in 2-byte Unicode (UTF-16LE) characters. To compute the precise byte length of the name string, this value must be multiplied by two. This length indicator is essential for accurate parsing, as it prevents examiners from inadvertently reading beyond the filename into subsequent padding bytes. Such padding—analogous to file slack—may contain residual data from prior MFT record reuse and could introduce irrelevant or misleading artifacts if over-read. It is important to note that NTFS attributes are aligned on 8-byte boundaries. Consequently, between the end of the filename string and the start of the next attribute (or the end of the MFT record), there will be 0 to 7 bytes of padding. This alignment requirement ensures efficient memory access but necessitates disciplined boundary-aware carving and structure traversal during manual or scripted MFT analysis.

In this case, it is seen to be 0x0C, which is 12 decimal. In Unicode, which has two bytes per character, this will mean a byte length of 24. Inspection of the file name, BROKEN~1.PNG, which follows, shows this to be correct. The use of one byte to store this value imposes a restriction on the file name length of 255 characters. It should be noted that Unicode characters occupy 2 bytes but count as one character.

Precise handling of the filename length field and subsequent padding is critical when reconstructing full paths, detecting hard links across multiple $FILE_NAME instances, or identifying namespace-specific artifacts (POSIX vs. Win32). Overlooking alignment padding risks incorporating garbage data into timelines or keyword searches, potentially leading to false positives or interpretive errors in investigations involving filename-based artifacts.

Absolute offset 0xF1, in our sample, is a one-byte field that records the type of the file name. In this case, it is seen to be 0x02, which indicates that it is DOS Type (8.3-compliant). Other valid values include:

• 0x00 = Posix Type
• 0x01 = Win32 Type (Long File Name)
• 0x02 = DOS Type (8.3-compliant)  
• 0x03 = Win32 &DOS Type (both Win32- and DOS-compliant).

Of the four categories shown above, the most general is that of POSIX, with value 0x00, and this permits the use of all Unicode characters and allows a file length of up to 255 characters. Win32, with value 0x01, is a subset of POSIX, and this prohibits the use of a small number of Unicode characters. It is equivalent to the FAT Long File Name (LFN). DOS, with value 0x02, is a subset of Win32, and this permits only single-byte upper-case characters, prohibits the use of a small number of these, and requires file names to be constrained within the standard DOS 8.3 format. It should be noted that, for compatibility with other systems, it may be necessary to record both the Win32 file name and a DOS-compliant file name in two separate File Name Attributes. However, where the Win32 file name is itself DOS-compliant, this is not necessary,  and the name needs only to be recorded once. The final category, Win32 & DOS, of value 0x03, is used to signal this situation; that the file name is both Win32- and DOS-compliant.

Multiple $FN attributes may exist, since there are four namespaces; for DOS8.3names, Windows names, POSIX names, and a shared namespace for filenames compatible with both DOS and Windows. An entry can thus have up to three $FN attributes. Each of these attributes stores a set of MACB timestamps. These timestamps are peculiar in that they are updated with the values of the $SI times tamps whenever the FN attribute itself changes. As the $FN attribute includes a reference to the parent directory, the update also happens when a file is moved to another directory within the same file system. The experiments conducted during this research show that if a filename in a particular namespace is changed, the timestamps of $FN attributes in the other namespaces are also updated, resulting in duplicates of (some earlier state of) the SI attribute timestamps in all $FN attributes.

As can be seen, byte offsets 0xF2-0x109 contain the file name. The character length of which (12) is given in byte offset 0xF0. This file name field, of value here BROKEN~1.PNG, has to be of variable length to permit the use of long file names. The six bytes from offset 0x10A to 0x10F are padding that has been added to ensure the next Attribute starts on an 8-byte boundary. It appears to be standard practice for all Attributes to start on 8-byte boundaries.

An examination of the MFT shows that when a file name exceeds the constraints of the 8.3 DOS name, two File Name Attributes are present in the record: one containing the DOS-compliant 8.3 file name and one containing the Win32 Long File Name. The same holds true for our sample MFT record. The second File Name attribute spans byte offsets 0x110-0x18F as shown in figure 4 above. 

Byte offsets 0x16A-0x18D contain the long file name, the character length of which is 18 (0x12), as given in byte offset 0x168. The value here is brokenheart_30.png.

The timestamps in the $FILE_NAME attribute (FNA) are set to mirror the $STANDARD_INFORMANTION attribute (SIA) timestamps when the file is created and cannot be altered directly. However, FNA values are updated to mirror the SIA values whenever the file is renamed or changes location on the drive. Thus, Joakim Schicht, the author of SetMACE, uses a combination of SIA changes and moving: First, the SIA timestamps are altered, and the file is moved to a different directory, causing the timestamps in the FNA to update and mirror the changes made to the SIA. The file has to be timestomped again before being relocated back to its original location because the FNA values will be updated again. Finally, the files' SIA values are timestomped one last time to ensure they are set exactly how the user wants them. This method allowed for the timestamps stored in the SIA and the FNA to be modified with nanosecond precision, making the detection of timestamp manipulation in NTFS difficult. Later, he realized that this method may leave additional evidence behind on the system and thus rewrote SetMACE to write directly to the system drive for versions 1.0.0.6 and newer. However, Microsoft patched this, and currently, direct access to the system drive is no longer allowed.

The accompanying diagram illustrates the results of identical file operations—creation, modification, access, copying, moving, and renaming—applied to the $FILE_NAME attribute timestamps. As anticipated, the behavioral rules diverge substantially from those governing the $STANDARD_INFORMATION ($SI) set, reflecting the kernel-mediated nature of $FN updates.

In forensic practice, this divergence can be leveraged to significant advantage. Notably, the Creation (Birth) timestamp in the $FILE_NAME attribute follows update semantics that closely parallel those of its $SI counterpart across many common operations. Consequently, the $FN Creation time often serves as a more stable and tamper-resistant anchor.

A key investigative indicator arises when discrepancies are observed between the $STANDARD_INFORMATION and $FILE_NAME Creation timestamps for the same file. Such inconsistencies frequently signal timestomping or other anti-forensic activity, as most user-mode tools lack the capability to directly modify the kernel-protected $FN values.

During timeline reconstruction and artifact validation, examiners should routinely compare the four-timestamp quartets from both attributes (and, where present, additional $FN instances for hard links or alternate namespaces). Persistent alignment in Creation times coupled with divergence elsewhere strengthens confidence in observed patterns, while anomalous mismatches warrant deeper scrutiny for manipulation, tool artifacts, or non-standard interfaces (e.g., WSL). This dual-attribute analysis remains a cornerstone of robust NTFS temporal forensics.