MACB on NTFS: $SI vs $FN

Every file on an NTFS volume carries at least eight timestamps, and a timeline is only as good as the examiner's knowledge of what moves each one. This lesson explains the MACB notation used in timelines, where the eight values live, which component updates them, how normal operations such as copy, rename and edit change them, and how to recognize values that do not fit those patterns. Module 7 covers timestomping as an anti-forensic technique; here the goal is to read a timeline correctly.

MACB notation

Timelines label each file system timestamp with one of four letters:

C is the trap: on NTFS it means the MFT entry (metadata) changed, not "created". Windows Explorer does not show it at all.

Timeline tools combine identical values into one row and show the letters as a four-position code with dots for the ones that do not apply. In The Sleuth Kit's mactime output, m.c. means this time is both the content modification and the MFT entry change, .a.. is an access only, and macb means all four are equal, which is normal at creation. TSK's bodyfile (fls -m) lists the $FN values as a separate entry whose name ends in ($FILE_NAME), so one file can produce rows for both sets. Plaso's l2tcsv output has a MACB column with the same letters in upper case (Lesson 3.3).

Where the eight timestamps live

Lesson 1.3 introduced the two attributes. Their timestamps sit at these offsets inside the attribute content:

$FN starts with the 8-byte parent reference, which is why its timestamps begin at 0x08. All eight are FILETIME values: 64-bit counts of 100-nanosecond intervals since 1601-01-01 00:00:00 UTC (Lesson 3.1). They are stored in UTC, whatever the system's time zone.

A file has one $SI but one $FN per name. With 8.3 short names enabled, Quarterly Report.xlsx has a Win32 $FN and a DOS $FN (QUARTE~1.XLS), and each carries its own four timestamps, usually identical. Hard links add more $FN attributes. The parent directory's $I30 index entry holds another copy of the $FN, timestamps included, which may differ from the record; entries left in index slack can preserve times of deleted or renamed files.

Who updates them

$SI is maintained by NTFS during normal file operations, and any process with write-attribute access to the file can also set it from user mode. SetFileTime sets created, accessed and modified; the native call NtSetInformationFile with the FileBasicInformation class (and SetFileInformationByHandle) can set all four, including the MFT entry modified time. No administrator rights are needed. Legitimate software uses these calls all the time: archivers, copy and backup tools, installers and cloud sync clients restore times on purpose.

$FN is written by the NTFS driver in the kernel when a name is created, which mainly happens on create, rename and move. There is no documented API to set $FN directly. That is why $FN is harder to fake and why comparing it with $SI is useful. Harder is not impossible: because a rename or move typically copies $SI values into the new $FN, someone can set $SI and then move the file, and raw disk writes can change anything (Module 7).

Last access is weak evidence

The registry value NtfsDisableLastAccessUpdate under HKLM\SYSTEM\CurrentControlSet\Control\FileSystem controls A updates. Since Windows Vista they have been disabled by default. From Windows 10 version 1803 the value can be 0x80000000 to 0x80000003: bit 0x2 set means "System Managed", in which Windows decides and enables updates on system volumes of 128 GB or less, and bit 0x1 set means disabled. fsutil behavior query disablelastaccess shows the setting on a live system. So whether A is updated depends on the version and the volume: never assume it either way. Even when enabled, NTFS delays writing a new access time to disk by up to one hour. Treat A as weak evidence: an old A does not prove the file was not opened, and a recent A may come from antivirus scanning, indexing or backup. Use Prefetch, LNK files and Jump Lists to show that a file or program was opened (Module 2).

Rules of thumb on Windows 10 and 11

Research on Windows 10 and 11 NTFS has tabulated how common operations change the eight values. The table shows the typical result; behavior varies by Windows build and by the program doing the work, so test on the same version before relying on a rule in a report.

"New" is the time of the operation, "–" unchanged, "Source" inherited from the original file, and "From $SI" means the new $FN takes the $SI values held just before the operation. A move to another volume is a copy followed by a delete: the new record gets new $FN times like a copy, but a cut and paste in Explorer also keeps the source's $SI B, so M and B both look old.

Three consequences matter most:

• Copy indicator. A copy keeps the source's M but gets a new B, so M earlier than B is the normal sign of a copied file, not of tampering.
• Archives and downloads. Extraction tools usually set M from the time stored in the archive, and some also restore B and A, so extracted files can look years old. A browser download normally gets B when the file is first created and M when writing ends; some download tools set M from the server's Last-Modified header. A Zone.Identifier alternate data stream helps to identify downloads.
• Safe-save applications. Many editors, including office suites, save by writing a temporary file and renaming it over the original. The file then sits in a new MFT record, while NTFS tunneling (a cache, 15 seconds by default, keyed on the name) gives the new file the old $SI creation time. A stable B does not prove the record is the same.

Worked example: budget-q3.xlsx

(a) Copied from a USB drive. The FAT32 drive held budget-q3.xlsx, last modified 2026-07-28T16:42:10Z. It was copied to C:\Users\ana\Documents\. The record (for example in istat output) shows:

Reasoning: $SI M is 5 days, 16 hours and 33 minutes before $SI B, which matches the copy pattern (MFTECmd's Copied column flags this). $SI B equals $FN B, so nothing suggests backdating. $SI M has a zero sub-second part because FAT32 stores modification times in 2-second steps and the copy preserved it; 16:42:10 is an even second. FAT stores local time, so the conversion to UTC used the copying system's time zone (Lesson 3.5). The file arrived at 09:15:42Z; corroborate the USB device with the artifacts in Lesson 2.6.

(b) Edited and saved in place on 2026-08-04T22:31:07.4410023Z. $SI M and $SI C become 2026-08-04T22:31:07.4410023Z. $SI B stays 09:15:42.6183420Z, and $SI A is unchanged because last access updates are disabled. All four $FN values stay at 2026-08-03T09:15:42.6183420Z. Now M is later than B, so the copy indicator has disappeared from $SI; the arrival time survives in $SI B and in all four $FN values. If a safe-save editor had been used, check the record number against earlier artifacts before assuming it is the same record.

Reading anomalies

Patterns that do not fit the table deserve a closer look:

• $SI B earlier than $FN B. After create, copy, rename and same-volume move, $SI B equals $FN B. A cut and paste from another volume and some archive extractions also produce an older $SI B, but they leave $SI C at the time of the operation.
• Zeroed sub-second values. A FILETIME whose 100-nanosecond part is 0000000. NTFS records full precision, while many tools that set times use whole seconds.
• $SI dates before the operating system was installed, using InstallDate (Unix seconds) under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. Feature upgrades reset that value, so compare carefully.

Each has innocent causes: archive extraction, installers, sync clients and files from FAT media. Treat them as leads, not findings, and confirm with $UsnJrnl (a BASIC_INFO_CHANGE reason at the time the values were set) and $LogFile (Lesson 1.4 and Module 7). MFTECmd, for example, writes the eight values as Created0x10, Created0x30, LastModified0x10, LastModified0x30, LastRecordChange0x10, LastRecordChange0x30, LastAccess0x10 and LastAccess0x30 (0x10 is $SI, 0x30 is $FN), and flags records with SI<FN (an $SI time earlier than the $FN time), uSecZeros (zero sub-second values) and Copied. Some tools leave $FN columns empty when they equal $SI, so check how your tool displays them.

Worked example: a timestomped file

C:\ProgramData\Intel\igfxupd.exe shows all four $SI values as 2019-03-19T04:12:00.0000000Z and all four $FN values as 2026-08-05T02:14:48.9917304Z. InstallDate is 1,676,037,931, which is 2023-02-10T14:05:31Z.

The raw $SI created value is the 8 bytes 00 E8 45 E6 09 DE D4 01, read little-endian as 0x01D4DE09E645E800 = 131,974,423,200,000,000. Divided by 10,000,000 that is 13,197,442,320 seconds with remainder 0: no sub-second part. The $FN value 134,303,696,889,917,304 leaves a remainder of 9,917,304, that is .9917304 s.

Reasoning: $SI B is seven years before $FN B; $SI is zeroed while $FN is not; $SI predates the installation; and $SI C was also set, which SetFileTime alone cannot do. A normal copy would give a new $SI B, and a move from another volume or an extraction that restores B would still leave $SI C at the time of the operation. The defensible statement is that the file name was created on this volume at 2026-08-05T02:14:48Z and its $SI values were probably set afterwards, pending confirmation from $UsnJrnl.

Exam focus: Expect to identify which of the eight timestamps an operation changes, to recognize M earlier than B as a copy, and to choose $FN over $SI when $SI looks manipulated. Practical tasks may ask for a file's arrival time on a volume, which comes from B and must be stated in UTC with full precision. Questions on last access test whether you know it is usually disabled and therefore weak.

Key points

• MACB means Modified, Accessed, MFT entry Changed and Born; on NTFS C is metadata change, not creation.
• $SI and each $FN hold four FILETIME values in UTC; a file has one $SI but one $FN per name, plus a copy in the parent's $I30 index.
• $SI can be set from user mode by any process with write-attribute access; $FN is written by the kernel on create, rename and move, so it is harder to fake.
• A copy keeps the source's M and gets a new B, so M earlier than B is normal for copied files.
• Whether last access is updated depends on the version and volume; treat A as weak evidence.
• $SI B earlier than $FN B, zeroed sub-seconds and dates before installation are leads to confirm with $UsnJrnl and $LogFile.