In this module

$STANDARD_INFORMATION Attribute

14 hours · Module 1 · Free

Operational Objective

The $STANDARD_INFORMATION attribute is the first attribute in every MFT record and the primary source of file timestamps that tools report. When MFTECmd outputs Created, Modified, Accessed, and Entry Modified timestamps, it reads them from the $SI attribute's eight-byte FILETIME fields. These are the timestamps that appear in Windows Explorer, in forensic timelines, and in investigation reports. They are also the timestamps that attackers modify when they timestomp — because $SI timestamps are writable through standard Windows APIs while $FILE_NAME timestamps require kernel-level access. Understanding the $SI attribute at the binary level means understanding which timestamps can be trusted, which can be manipulated, what additional metadata the attribute contains beyond timestamps (permissions, security ID, update sequence number, quota information), and how to read each field directly from hex when you need to verify or recover data that a parser couldn't process.

Deliverable: Ability to locate the $STANDARD_INFORMATION attribute in a raw MFT record, parse all timestamp fields (Created, Modified, MFT Entry Modified, Accessed) from their 8-byte FILETIME encoding, interpret the permission flags, read the Update Sequence Number (USN), and identify timestomping indicators by comparing $SI timestamps against expected patterns.

Estimated completion: 40 minutes

Figure WF1.2 — $STANDARD_INFORMATION attribute layout showing the four MACE timestamps (Created, Modified, Entry Modified, Accessed), permission flags, and extended fields including the Update Sequence Number. All four timestamps are modifiable through the Windows API, making $SI the primary target for timestomping attacks.

The FILETIME format

Every timestamp in the MFT uses the Windows FILETIME format — a 64-bit (8-byte) 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.

To convert a FILETIME value to a human-readable timestamp: 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 conversion automatically and outputs timestamps in ISO 8601 format with seven decimal places of precision. The seven decimal places correspond to the full 100-nanosecond resolution of the FILETIME format.

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 by Windows has a creation timestamp like 2026-03-15T14:23:07.1234567. A file whose timestamp was set by PowerShell's Set-ItemProperty typically has a creation timestamp like 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 of timestomping (some legitimate file operations also produce zero-fractional timestamps), but it is an indicator that warrants further investigation, particularly when other files in the same directory have full nanosecond precision.

A FILETIME value of 0 (all eight bytes are 0x00) indicates the timestamp was never set. This is different from the epoch time (January 1, 1601) — a zero FILETIME means the field is empty, not that the file was created in 1601. MFTECmd displays zero FILETIME values as blank or as a specific placeholder depending on the version. In raw hex, eight consecutive zero bytes in a timestamp field mean the timestamp is undefined.

The four $SI timestamps

The $STANDARD_INFORMATION attribute contains four timestamps, commonly known by the MACE acronym: Modified, Accessed, Changed (Entry Modified), and Entry Created — though the order in the attribute is actually Created, Modified, Entry Modified, Accessed (CMEA at offsets 0x00, 0x08, 0x10, 0x18 relative to the attribute content start).

The Created timestamp (offset 0x00) records when the file was originally created. On a file that has never been copied or moved, this timestamp reflects the moment Windows allocated the MFT entry and created the initial $DATA attribute. On a file that was copied from another location, the Created timestamp reflects when the copy was made — not when the original file was created. On a file that was moved within the same volume, the Created timestamp is unchanged because the MFT entry is the same (only the parent directory reference changes). On a file that was moved across volumes, the behavior is a copy-then-delete, so the Created timestamp reflects the cross-volume move time.

The Modified timestamp (offset 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 the Modified timestamp. Opening a file, editing the content, and saving it does update the Modified timestamp. Renaming a file does not update the Modified timestamp (the filename is in $FILE_NAME, not $DATA). Changing file permissions does not update the Modified timestamp. The Modified timestamp specifically tracks data changes, not metadata changes.

The Entry Modified timestamp (offset 0x10) records the last time any attribute in the MFT record was changed. This includes data changes (which also update the Modified timestamp) but also metadata changes: renaming the file (changes $FILE_NAME), changing permissions (changes $STANDARD_INFORMATION itself), moving the file to a different directory (changes the parent reference in $FILE_NAME), and changing security descriptors. The Entry Modified timestamp is broader than the Modified timestamp — it captures any MFT record modification, not just data modifications.

The Accessed timestamp (offset 0x18) records the last time the file was read. On Windows XP and earlier, this timestamp was updated on every file access. Starting with Windows Vista, Microsoft introduced the NtfsDisableLastAccessUpdate registry setting to reduce disk writes, and this setting is enabled by default on Windows 10 and Windows 11. With last access updates disabled, the Accessed timestamp is only updated when it is more than one hour older than the current time — meaning the Accessed timestamp has hour-level granularity at best on modern Windows systems. On evidence from Windows 10/11, treat the Accessed timestamp as approximately accurate (within an hour) rather than precise.

Compliance Myth: "The file's modified date proves when the user last edited it"

The $SI Modified timestamp proves when the $DATA attribute was last written — not necessarily when a user edited the file. Antivirus scans that quarantine and restore files update the Modified timestamp. Backup software that rewrites files during restore operations updates the Modified timestamp. File synchronization tools (OneDrive, Dropbox) that re-download files update the Modified timestamp. Even Windows itself updates Modified timestamps during system updates that replace system files. In an investigation, the Modified timestamp is evidence that the file's data was written at that time. It is not evidence that a specific user edited the file at that time. Proving user-initiated modification requires correlating the Modified timestamp with user session data (logon events), process execution evidence (Prefetch showing the application that wrote to the file), and application-specific artifacts (Office recent documents, Jump Lists).

Permission flags and file attributes

At offset 0x20 (relative to $SI content start), four bytes encode the file's DOS-compatible attribute flags. These are the same flags visible in the Windows attrib command and the file properties dialog. Forensically, the flags that matter are:

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 (particularly if also marked as system) warrants investigation.

System (0x0004): The file is marked as an operating system file. Combined with Hidden, this creates "super hidden" files that are 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 flags is deliberately hiding from the user's default file browser view.

Compressed (0x0800): The file is NTFS-compressed. The actual data on disk is smaller than the logical file size reported in the MFT. When recovering deleted files, compressed data requires decompression before interpretation.

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 of EFS-encrypted files, either the user's key must be recovered (from the certificate store or backup) or the file must be examined in the context of a live system where the user is logged in.

The Update Sequence Number (USN)

At offset 0x44 (in the extended $SI attribute present on NTFS 3.0 and later — all Windows 2000+ systems), an eight-byte field contains the Update Sequence Number. This is not the USN Journal entry — it is a reference number that links the MFT record modification 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.

The forensic value of the $SI USN field: it provides a direct link between the MFT record's current state and the USN Journal entry that describes the most recent modification. When examining a timestomped file, the $SI timestamps show the fake time, but the USN field points to the USN Journal entry that records the actual time of the timestomping operation itself. If the USN Journal is intact, this link provides evidence of the modification that the attacker intended to conceal.

Expand for Deeper Context

The relationship between $SI timestamps and the USN field creates an asymmetry that attackers rarely account for. When SetFileTime() modifies the Created or Modified timestamp, NTFS records the operation as a "data change" in the USN Journal — because the $SI attribute was modified. The USN Journal entry records the current time (the real time of the modification), the filename, and the reason code. The attacker has successfully changed the $SI timestamps to show fake values, but the USN Journal records that the $SI attribute was modified at the real time. Unless the attacker also truncates or deletes the USN Journal (which is a separate, more destructive anti-forensic action that itself leaves traces in the $MFT and $LogFile), the timestomping is detectable through USN correlation.

This is why the multi-artifact correlation approach matters. The $SI timestamp alone is not trustworthy — it can be modified. The $SI USN field alone is not self-explanatory — it's just a number. But the $SI 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]."

Decision point

You are building a forensic timeline for a ransomware investigation. You notice that 47 executable files in a temporary directory all have identical $SI Created timestamps — 2025-08-15T09:00:00.0000000. The $SI Entry Modified timestamps for the same files show dates ranging from 2026-03-18T02:14:33.4521876 to 2026-03-18T02:17:44.8934521. The Accessed timestamps are all within the same March 18 range. The fractional seconds on the Created timestamps are all zeros.

Your options: (A) Report the August 2025 creation date as the installation date for these executables. (B) Investigate the timestamps further — the zero fractional seconds on Created combined with the mismatch between Created and Entry Modified suggest timestomping. Check $FN timestamps and USN Journal entries for the real creation time.

The correct approach is B. The zero fractional seconds are the first indicator — naturally created files on NTFS have non-zero fractional seconds. The three-month gap between Created (August 2025) and Entry Modified (March 2026) is the second indicator — if these files were truly created in August 2025, some metadata change would have updated the Entry Modified timestamp before March 2026 (antivirus scans, Windows updates, or simply accessing the file). The identical Created timestamps across 47 files is the third indicator — while batch installation can produce similar timestamps, identical timestamps to the nanosecond across dozens of files is almost always the result of a script that set all timestamps to the same value. Check the $FN timestamps (WF1.3) and the USN Journal (WF2) for the real creation time.

Reading $SI from raw hex

To locate the $SI attribute in a raw MFT record, navigate to the first attribute offset (read from the record header at offset 0x14) and confirm the attribute type is 0x10000000 (stored as 10 00 00 00 in little-endian). The $SI attribute is always the first attribute in the chain because NTFS creates it first when allocating a new MFT record.

The attribute header for a resident attribute (which $SI always is) contains: the type code (4 bytes), the total attribute length (4 bytes), the non-resident flag (1 byte, always 0 for $SI), the name length (1 byte, always 0 — $SI has no name), the name offset (2 bytes), the flags (2 bytes), the attribute ID (2 bytes), the content size (4 bytes), and the content offset (2 bytes, relative to the attribute start). The content offset tells you where the timestamp fields begin.

For a standard unnamed resident attribute, the content offset is typically 0x18 (24 bytes from the attribute start). So if the $SI attribute begins at offset 0x38 in the MFT record, the $SI content begins at 0x38 + 0x18 = 0x50. The Created timestamp occupies bytes 0x50–0x57. The Modified timestamp occupies bytes 0x58–0x5F. The Entry Modified timestamp occupies bytes 0x60–0x67. The Accessed timestamp occupies bytes 0x68–0x6F.

Each timestamp is an 8-byte little-endian integer. To convert to a readable date, read the bytes in reverse order (little-endian to big-endian), convert to a decimal integer, and apply the FILETIME conversion. In practice, Python makes this straightforward: import struct; struct.unpack(' gives the integer, and datetime(1601,1,1) + timedelta(microseconds=value//10) gives the datetime. MFTECmd does this automatically, but knowing the manual process allows you to verify the tool's output against the raw data.



Try it: Extract $SI timestamps from raw hex

Using the same MFT file from the WF1.1 exercise, navigate to MFT entry 0 (offset 0x000). This is the $MFT file itself.

1. Read the first attribute offset from the record header at offset 0x14. Navigate to that offset. 2. Confirm the attribute type is 10 00 00 00 ($STANDARD_INFORMATION). 3. Read the content offset from the attribute header (typically at attribute_start + 0x14, two bytes). This tells you where the timestamps begin relative to the attribute start. 4. Calculate the absolute offset: attribute_start + content_offset. 5. Read 8 bytes starting at that absolute offset — this is the Created timestamp in FILETIME format. 6. Convert the 8 little-endian bytes to a decimal integer. You can use Python: int.from_bytes(bytes.fromhex('YOUR_HEX_HERE'), 'little'). 7. Convert to a datetime: from datetime import datetime, timedelta; datetime(1601,1,1) + timedelta(microseconds=VALUE//10). 8. Compare your result to MFTECmd's output for MFT entry 0's Created timestamp. They should match exactly, including the fractional seconds.

If they match, you have verified the parser's output against the raw data. If they don't match, you have found a discrepancy that warrants investigation — either in your conversion or in the parser's handling of this specific record.


$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 will encounter in current investigations, the $SI attribute will be the 72-byte version — NTFS 1.x systems have been out of production support for over 20 years. However, if you encounter evidence from a forensic archive or a legacy system, check the $SI content size before attempting to read fields beyond offset 0x20. Attempting to read the USN field (offset 0x44) from a 48-byte $SI attribute produces garbage data from whatever follows the $SI content in the MFT record.
MFTECmd handles both versions automatically and outputs the appropriate fields. But when reading raw hex, always check the content size in the attribute header before interpreting fields.


During a forensic examination, you extract a file's $STANDARD_INFORMATION timestamps and find: Created = 2026-01-10T08:30:00.0000000, Modified = 2026-03-22T15:45:12.3456789, Entry Modified = 2026-03-22T15:45:12.3456789, Accessed = 2026-03-22T15:00:00.0000000. What should you investigate further and why?


The Accessed timestamp is rounded to the hour, indicating the system clock was misconfigured — investigate clock synchronization.
The Created timestamp has zero fractional seconds while the Modified and Entry Modified timestamps have full nanosecond precision. This pattern suggests the Created timestamp may have been set through an API call (timestomping or a file operation that resets the creation time) rather than by NTFS naturally. The Accessed timestamp rounding to the hour is normal on Windows 10/11 with NtfsDisableLastAccessUpdate enabled. Investigate by comparing $SI Created against the $FILE_NAME Created timestamp and checking USN Journal entries around the claimed creation date.
The Modified and Entry Modified timestamps are identical, which proves no metadata changes occurred after the last data write — the file has not been renamed, moved, or had permissions changed since March 22.
Everything looks normal — the Created date is two months before Modified, which is a typical pattern for a file that was created and later edited.



Operational Artifact — $STANDARD_INFORMATION Field Reference and Timestamp Verification Method

This subsection provides the complete field reference for the $STANDARD_INFORMATION attribute content area and a manual timestamp verification method using hex editors and Python. Use this reference when you need to verify MFTECmd timestamp output against raw MFT data — particularly for key evidence files where timestamps are central to your findings. The verification method (read raw hex → convert little-endian → apply FILETIME conversion → compare to parser output) should be applied to every file that forms a core finding in a legal or regulatory investigation. Document the verification in your report as methodology evidence.






© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.


You've built the foundations of artifact-level forensic analysis.
WF0 gave you the taxonomy, NTFS architecture, and the five-step methodology. WF1 took you inside the MFT at the binary level — every attribute, every timestamp, every edge case. From here, every artifact category gets the same raw-first treatment.

WF2–WF10: every major Windows artifact decoded at binary level — USN Journal, Prefetch, Amcache, Shimcache, ShellBags, LNK, Jump Lists, SRUM, Event Logs, and the Registry hives
INC-NE-2026-0915 (WF13) — Insider data exfiltration capstone. Work the complete investigation from USB history to OneDrive exfiltration evidence
INC-NE-2026-1022 (WF14) — Ransomware capstone. Three-host triage (FIN01 → IT03 → FS01) across the 72-hour attack chain
The lab pack — 25+ realistic evidence files in 10 formats, simulated KAPE triage pre-populated, both capstones deployable to your own VM
Anti-forensic detection methodology — defeat timestomping, log clearing, and Prefetch deletion with cross-artifact correlation


Unlock with Specialist — £25/mo
See Full Syllabus

Cancel anytime





← Previous
Next →