In this section
$STANDARD_INFORMATION Attribute
Scenario
You find 47 executable files in a temporary directory. All have identical $SI Created timestamps: 2025-08-15T09:00:00.0000000. The $SI Entry Modified timestamps range across March 18, 2026. The fractional seconds on Created are all zeros. Naturally created files have non-zero fractional seconds. Identical timestamps to the nanosecond across dozens of files means a script set them to the same value. The real creation time is in the $FN timestamps and USN Journal.
The FILETIME format
Every timestamp in the MFT uses Windows FILETIME: a 64-bit unsigned integer representing the number of 100-nanosecond intervals since January 1, 1601 00:00:00 UTC. This epoch predates the Unix epoch (January 1, 1970) by 369 years, and the 100-nanosecond resolution provides precision that is forensically significant for both event sequencing and timestomping detection.
To convert a FILETIME to a readable date: read the 8-byte little-endian integer, subtract the epoch offset (116444736000000000 — the number of 100-nanosecond intervals between 1601 and 1970), divide by 10,000,000 to get Unix seconds, then convert to your preferred date format. MFTECmd performs this automatically and outputs ISO 8601 with seven decimal places — the full 100-nanosecond resolution. In Python: struct.unpack('datetime(1601,1,1) + timedelta(microseconds=value//10) gives the datetime.
This precision matters for timestomping detection. When an attacker uses SetFileTime() or a timestomping tool to modify $SI timestamps, the tool typically sets timestamps with lower precision than NTFS natively provides. A file created naturally has a timestamp like 2026-03-15T14:23:07.1234567. A file timestomped via PowerShell's Set-ItemProperty typically produces 2026-03-15T14:23:07.0000000 — the fractional seconds are all zeros because the API call specified the timestamp to second precision. This is not definitive proof (some legitimate operations produce zero-fractional timestamps), but it is an indicator that warrants further investigation when other files in the same directory have full nanosecond precision.
A FILETIME value of 0 (all eight bytes 0x00) indicates the timestamp was never set. This is different from the epoch time (January 1, 1601). MFTECmd displays zero FILETIMEs as blank or a placeholder. In raw hex, eight consecutive zero bytes in a timestamp field mean the timestamp is undefined.
The four $SI timestamps
The timestamps are stored in Created, Modified, Entry Modified, Accessed order (CMEA) at offsets 0x00, 0x08, 0x10, 0x18 relative to the attribute content start.
Created (offset +0x00) records when the file was originally created on this volume. On a file that has never been copied or moved, this reflects the moment Windows allocated the MFT entry. On a copied file, it reflects the copy time, not the original creation time. On a same-volume move, Created is unchanged because the MFT entry is the same (only the parent directory reference changes). On a cross-volume move, the behavior is copy-then-delete, so Created reflects the move time.
Modified (+0x08) records the last time the file's $DATA attribute content was written. Opening a file, reading it, and closing it without changes does not update Modified. Renaming a file does not update it (the filename is in $FN, not $DATA). Changing permissions does not update it. Only actual data writes trigger a Modified update. This specificity makes Modified valuable for identifying when file content last changed, but it requires corroboration to determine what application performed the write.
Entry Modified (+0x10) records the last time any attribute in the MFT record was changed. This is broader than Modified: it captures data changes (which also update Modified) and metadata changes — renaming (changes $FN), changing permissions (changes $SI itself), moving to a different directory (changes the parent reference in $FN), and changing security descriptors. Entry Modified is the most frequently updated timestamp because any MFT record modification triggers it.
Accessed (+0x18) records the last time the file was read. On Windows XP and earlier, this updated on every access. Starting with Vista, NtfsDisableLastAccessUpdate reduces disk writes by only updating Accessed when it is more than one hour older than the current time. This setting is enabled by default on Windows 10/11, giving Accessed hour-level granularity at best. Treat Accessed as approximately accurate on modern evidence, not precise.
The forensic implications of the lazy access update: if a file was accessed at 14:30 and the Accessed timestamp shows 13:45, the file was genuinely accessed between 13:45 and the current time. If the Accessed timestamp shows a date from weeks ago, the file has not been accessed since that date (within the one-hour window). You can determine the NtfsDisableLastAccessUpdate setting from the registry hive (HKLM\SYSTEM\CurrentControlSet\Control\FileSystem) to know which behavior was in effect on the evidence system. A value of 1 means updates are disabled (hour granularity). A value of 0 means updates are enabled (full precision). The default changed to 1 starting with Windows 10 1803.
Anti-Pattern
Citing the Modified timestamp as proof a specific user edited the file
The $SI Modified timestamp proves the $DATA attribute was written at that time. Antivirus quarantine-and-restore, backup software, file synchronization (OneDrive, Dropbox), and Windows updates all write to $DATA and update Modified. Proving user-initiated modification requires correlating Modified with user session data (logon events), process execution (Prefetch), and application artifacts (Office recent documents, Jump Lists).
Permission flags and file attributes
At content offset +0x20, four bytes encode the file's DOS-compatible attribute flags. These are the same flags visible in the attrib command and the file properties dialog. The forensically relevant flags:
Hidden (0x0002): The file is hidden from default directory listings. Malware frequently sets this flag to avoid visual detection. A hidden file in a non-standard location warrants investigation.
System (0x0004): The file is marked as an operating system file. Combined with Hidden, this creates "super hidden" files invisible even when "Show hidden files" is enabled in Explorer — the user must also uncheck "Hide protected operating system files." Malware that sets both Hidden and System is deliberately hiding from the default file browser view.
Compressed (0x0800): The file is NTFS-compressed. The actual data on disk is smaller than the logical file size in the MFT. Recovering compressed files requires decompression after cluster extraction. Section 1.12 covers compression in detail.
Encrypted (0x4000): The file is encrypted with EFS (Encrypting File System). The $DATA attribute contains encrypted content that cannot be read without the user's decryption key. For forensic analysis, either the key must be recovered from the certificate store or backup, or the file must be examined on a live system where the user is logged in.
Archive (0x0020): Set by the filesystem when the file is modified. Backup software clears it after a successful backup. Forensically, an Archive flag that is set means the file has been modified since the last backup. An Archive flag that is cleared means a backup tool has processed the file. This is a low-confidence indicator but can corroborate other evidence of file activity.
Not Content Indexed (0x2000): The file is excluded from Windows Search indexing. Attackers occasionally set this flag on tools and staging directories to avoid appearing in Windows Search results. Like the Hidden/System combination, this flag is an indicator of deliberate concealment when found on files in unexpected locations.
The Update Sequence Number (USN)
At content offset +0x44 (NTFS 3.0+, all Windows 2000+ systems), an 8-byte field contains the Update Sequence Number. This is not the USN Journal entry itself — it is a reference that links the MFT record to the corresponding USN Journal entry. Every time NTFS modifies an MFT record, it writes an entry to the USN Journal ($UsnJrnl) and stores the USN offset in this field.
This creates an asymmetry that attackers rarely account for. When SetFileTime() modifies $SI timestamps, NTFS records the modification as a "data change" in the USN Journal — because the $SI attribute was modified. The USN Journal entry records the real time of the modification, the filename, and the reason code. The attacker has changed $SI to show fake values, but the USN Journal records that $SI was modified at the real time. Unless the attacker also truncates the USN Journal (a separate, more destructive anti-forensic action that itself leaves traces), the timestomping is detectable through USN correlation.
The relationship between $SI timestamps and the USN field creates a multi-artifact check. The $SI timestamp alone is modifiable. The USN field alone is a number without context. But the USN field combined with the corresponding USN Journal entry produces a complete picture: "the file's $SI timestamps were modified at [real time] and now show [fake time]." This is why the multi-artifact correlation approach matters. Single-artifact analysis is vulnerable to manipulation. Multi-artifact correlation is resilient because the attacker must manipulate multiple independent data sources consistently — and each additional source they manipulate creates additional forensic artifacts documenting the manipulation.
Reading $SI from raw hex
To locate $SI, navigate to the first attribute offset (from the record header at 0x14). Confirm the type is 10 00 00 00. The attribute header for a resident attribute contains the content size and content offset. The content offset (typically 0x18 from the attribute start) tells you where the timestamp fields begin.
For a standard record with $SI at offset 0x38, the content starts at 0x38 + 0x18 = 0x50. Created is at bytes 0x50-0x57, Modified at 0x58-0x5F, Entry Modified at 0x60-0x67, Accessed at 0x68-0x6F. Each is an 8-byte little-endian integer.
The manual verification workflow: read 8 bytes at the timestamp offset, convert little-endian to integer in Python (int.from_bytes(bytes.fromhex('HEX'), 'little')), convert to datetime (datetime(1601,1,1) + timedelta(microseconds=value//10)), compare to MFTECmd's output. If they match, the parser is correct. If they differ, you have found a discrepancy worth investigating. Apply this workflow to every file that forms a core finding in a legal or regulatory investigation. Document the raw-verified values in your methodology section.
$SI attribute size and NTFS version
The $SI attribute exists in two sizes depending on the NTFS version. NTFS 1.x (Windows NT 3.x and 4.0) has a 48-byte $SI content containing only the four timestamps (32 bytes), the permission flags (4 bytes), and reserved fields. NTFS 3.0 and later (Windows 2000 through Windows 11) has a 72-byte $SI content that adds the version fields, owner ID, security ID, quota charged, and the USN field.
On all evidence you encounter in current investigations, the $SI attribute will be the 72-byte version — NTFS 1.x systems have been out of production for over 20 years. However, if you encounter evidence from a forensic archive or legacy system, check the $SI content size before attempting to read fields beyond offset +0x20. Reading the USN field (+0x44) from a 48-byte $SI produces garbage data from whatever follows the $SI content in the MFT record. MFTECmd handles both versions automatically, but when reading raw hex, always verify the content size in the attribute header.
The content size is in the attribute header at attribute_start + 0x10 (4 bytes, little-endian). A value of 0x48 (72 decimal) confirms the extended NTFS 3.0+ format. A value of 0x30 (48 decimal) indicates the legacy format.
Investigation Principle
The $SI timestamp alone is not trustworthy. The $SI USN field alone is not self-explanatory. But the USN field combined with the corresponding USN Journal entry produces a complete picture: "the file's $SI timestamps were modified at [real time] and now show [fake time]." Multi-artifact correlation turns individual data points into defensible evidence.
Reading $SI from raw hex
To locate $SI, navigate to the first attribute offset (from the record header at 0x14). Confirm the type is 10 00 00 00. The content offset is in the attribute header at attribute_start + 0x14 (2 bytes), typically 0x18. So if $SI starts at record offset 0x38, the content begins at 0x38 + 0x18 = 0x50. Created is at 0x50-0x57, Modified at 0x58-0x5F, Entry Modified at 0x60-0x67, Accessed at 0x68-0x6F.
The manual verification workflow: read 8 bytes, convert little-endian to integer in Python (int.from_bytes(bytes.fromhex('HEX'), 'little')), convert to datetime (datetime(1601,1,1) + timedelta(microseconds=value//10)), compare to MFTECmd output. If they match, the parser is correct. If they differ, you've found either a parser issue or a conversion error worth investigating.