Article URL: https://andreafortuna.org/2026/07/06/ntfs-forensics-deep-dive/ Comments URL: https://news.ycombinator.com/item?id=49109286 Points: 5 # Comments: 1

A skilled attacker who has spent any time studying forensics will know to modify file timestamps. Some will go further and delete their tools, clear event logs, and rename artefacts before exfiltrating or detonating. What most do not account for, because most training does not cover it carefully, is that NTFS keeps a layered audit trail spread across at least three separate structures, and cleaning one of them rarely touches the others. The Master File Table, the USN Journal, and the $LogFile each capture a different dimension of file system activity, at a different granularity and with different retention characteristics. When an analyst knows how to correlate all three, the story they tell is significantly harder to fully suppress than anything a single log or a timestamp suggests. This article walks through that structure in practical terms: what each artefact contains, how to extract it, and where the intersections between them are most useful for investigations. Before getting into tooling, it helps to have a clear model of what NTFS actually stores about a file, because the forensic value of these artefacts only becomes obvious once you understand the redundancy involved. Every file on an NTFS volume has at least one entry in the Master File Table, or $MFT (earlier overview). Each MFT entry is 1024 bytes and contains, among other things, two distinct sets of timestamps. The first set lives in the $STANDARD_INFORMATION attribute: the four MACB timestamps (Modified, Accessed, Created, $MFT entry modified) that most tools and the Windows Explorer interface expose. The second set lives in the $FILE_NAME attribute, which the NTFS kernel driver writes when the file is created and updates under a narrower set of circumstances. The critical forensic implication is that $FILE_NAME timestamps are written by the kernel and cannot be modified through standard Win32 APIs like SetFileTime. Most timestomping tools only reach $STANDARD_INFORMATION. That asymmetry is the most reliable single indicator of timestamp manipulation available in NTFS forensics. A file where $STANDARD_INFORMATION Born is earlier than $FILE_NAME Born is, under normal filesystem operation, an impossibility. The kernel copies $SI values from $FN at creation time; any later backdating of $SI will diverge from the kernel-written $FN values. When you see that divergence, you are reading a contradiction in the metadata record, not making an inference. The MFT also stores the file’s logical size, physical allocation, attribute list, and, for small files (typically under around 700 bytes), the file content itself as a resident attribute inside the MFT entry. This matters for carving: deleting a resident file does not free any cluster, it just marks the MFT entry as available for reuse. The content survives until the entry is overwritten. The USN Journal (\$Extend\$UsnJrnl) is an NTFS feature that has been available since Windows 2000 (dedicated post) and is enabled by default on modern Windows systems. Its primary stream, $J, records a sequential log of every file system change on the volume: file creates, renames, deletes, attribute changes, security descriptor updates, and more. Each record contains a 64-bit USN identifier, the filename, a parent MFT reference, a reason code bitmask (for example, USN_REASON_FILE_CREATE, USN_REASON_RENAME_OLD_NAME, USN_REASON_BASIC_INFO_CHANGE), and a timestamp.