$FILE_NAME Attribute is an NTFS metadata attribute that stores the file name, parent directory reference, and a second set of timestamps for a file. It is used by NTFS to support directory indexing and path resolution, and its values can differ from the $STANDARD_INFORMATION metadata.
What the $FILE_NAME Attribute Stores
The NTFS $FILE_NAME attribute is one of the core metadata records associated with a file. It stores the file name as NTFS knows it, a reference to the parent directory, and a second set of timestamps. Because it is part of the file system’s indexing and path-resolution machinery, it can retain evidence that differs from the $STANDARD_INFORMATION record.
That dual view matters because NTFS can preserve more than one timestamp source for the same file. In investigations, the $FILE_NAME record is often compared with other metadata to understand how the file system resolved the object, how directory entries changed, and whether timeline values were manipulated or merely updated by normal activity.
Why $FILE_NAME Matters in File System Analysis
The attribute is important because NTFS does not treat file metadata as a single flat record. The parent reference and name give investigators the directory context, while the embedded timestamps provide another timeline anchor. When those values are contrasted with $STANDARD_INFORMATION, analysts can spot inconsistencies that deserve closer review rather than assuming one metadata source is definitive.
That makes $FILE_NAME especially useful in file system forensics, where directory movement, rename activity, and metadata preservation can all affect what a timeline appears to show. A file can look unchanged from one record while another record reflects a different history, which is why analysts usually interpret the attribute alongside the Master File Table and related NTFS artefacts.
How Investigators Use It to Reconstruct Activity
In practice, the attribute helps reconstruct how a file sat inside the directory tree at a specific point in time. The parent directory reference can show where NTFS placed the entry, and the timestamp set can provide a second chronology that may be older or newer than the companion metadata record. That is useful when tracing file creation, rename events, moves, and deletion artefacts.
Investigators commonly compare the attribute with other timeline sources to build a more reliable sequence of events. The strongest value comes from correlation, not isolation: a single metadata record can be incomplete or misleading, but a consistent pattern across $FILE_NAME, directory entries, and journaling artefacts is far more informative than any one field alone.
When $FILE_NAME Differs from $STANDARD_INFORMATION
Differences between the two metadata views are not automatically suspicious, but they are always worth understanding. NTFS updates the records in different ways depending on the operation, so a file can carry one set of timestamps in the $FILE_NAME attribute and another in $STANDARD_INFORMATION. That separation can reflect normal file-system behaviour, copied files, or post-event tampering.
For defenders and forensic analysts, the practical question is whether the difference is explainable by legitimate activity. If it is not, the mismatch can become a clue that the file history was altered, a directory entry was reused, or anti-forensic activity affected the timeline. That is why the attribute is usually interpreted as part of a broader evidentiary picture rather than as a standalone indicator.
Risk and Threat Considerations
Inconsistencies between NTFS metadata records can be abused to obscure file history, frustrate timeline reconstruction, or make a manipulated file look less suspicious than it is. The risk is not that the attribute is unreliable by itself, but that a defender who reads only one metadata source may miss evidence of rename, move, or timestomping activity.
Failure mechanism: Attackers or anti-forensics tools can alter one set of timestamps or rely on NTFS record behaviour to create a mismatch between directory metadata and the companion file metadata, leaving analysts with a weakened or misleading timeline.
Impact: The result can be delayed detection, weaker attribution of file activity, and less confidence in incident reconstruction, especially when the file record is used to support containment or legal reporting.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1070.006 — Timestomp | Covers file timestamp manipulation used to hide or alter file history. |
| Recommendation — Map timestamp inconsistencies to T1070.006 and hunt for timeline tampering across file-system artefacts. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Supports preserving and reviewing forensic evidence needed to validate file activity timelines. |
| Recommendation — Retain and review audit evidence that corroborates file-system metadata timelines. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Applies because analysts must review and correlate records to detect file metadata manipulation. |
| SI-4 — System Monitoring | Applies where file-system monitoring is used to detect suspicious changes in metadata or activity. | |
| Recommendation — Correlate audit records with file-system artefacts to identify suspicious metadata changes. Monitor file-system events for anomalous metadata changes and directory activity. | ||
Practitioner Guidance
What to watch for: Treat $FILE_NAME as a comparison point, not a verdict. When the timestamps or parent reference do not align cleanly with other NTFS artefacts, investigate the surrounding file system context before concluding that the discrepancy is benign or malicious.
Practitioner takeaway: The attribute is most valuable when it is correlated with the broader NTFS timeline, because that is where directory movement, rename history, and tampering become visible.
Related resources from NHI Mgmt Group
- How should security teams prevent command injection when an API needs to use a file name or system command on the server side?
- What breaks when an AI agent instruction file references a bucket or package name that no longer exists?
- How do developers prevent external control of a file name or path?
- What mitigations reduce the risk of External Control of File Name or Path?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org