10.2 Timestomping Countermeasures: Comparing $STANDARD_INFORMATION vs $FILE_NAME Timestamps

10.2 Timestomping Countermeasures: Comparing $STANDARD_INFORMATION vs $FILE_NAME Timestamps

Quick Answer: Timestomping is an anti-forensic technique where an adversary deliberately modifies a file's MACB timestamps (Modified, Accessed, Created, Born/MFT Altered) to camouflage malicious executables within legitimate operating system directories (such as C:\Windows\System32). Because standard user-space tools and APIs (like kernel32!SetFileTime or Meterpreter's timestomp) alter only the $STANDARD_INFORMATION (Attribute 0x10) attribute, they leave the kernel-protected $FILE_NAME (Attribute 0x30) attribute untouched. Forensic examiners expose timestomping by comparing 0x10 and 0x30 timestamps, identifying nanosecond rounding anomalies (.0000000Z), and cross-referencing file activity against the non-volatile $UsnJrnl:$J journal.

---

Timestomping Mechanics & Threat Actor Motivations

When threat actors deploy backdoors, web shells, or privilege escalation tools to disk, standard operating system file creation timestamps immediately draw forensic scrutiny during initial incident triage. Investigators routinely sort files chronologically to identify binaries introduced during the suspected window of intrusion.

To subvert temporal analysis, threat actors execute timestomping to achieve three tactical goals:

1. Baseline Blending: Forging a malicious binary's creation date to match surrounding operating system components (e.g., matching the installation date of cmd.exe or kernel32.dll).
2. Super-Timeline Subversion: Evading time-windowed forensic queries (such as hunting for files created between 02:00 and 04:00 on the day of an alert).
3. Incident Response Frustration: Confusing incident responders, leading them to believe that an attacker binary has been dormant for years rather than introduced hours prior.

Target Directory: C:\Windows\System32\
Actual Intrusion Window: September 22, 2026 at 03:14:22 UTC

File Name       Reported Timestamp (Explorer)     Status / True State
---------       -----------------------------     -------------------
svchost.exe     2021-05-18 12:45:00 UTC           Legitimate Windows Binary
kernel32.dll    2021-05-18 12:45:00 UTC           Legitimate Windows Binary
beacon.dll      2021-05-18 12:45:00 UTC <------- FORGED VIA TIMESTOMPING!
cmd.exe         2021-05-18 12:45:00 UTC           Legitimate Windows Binary

---

NTFS Timestamp Architecture: Attribute 0x10 vs. Attribute 0x30

To understand why timestomping fails under rigorous forensic scrutiny, an investigator must understand how the New Technology File System (NTFS) records file metadata inside the Master File Table ($MFT). Every file and directory on an NTFS volume is allocated at least one 1024-byte record in the $MFT.

NTFS maintains four timestamps for every file, universally designated by the acronym MACB:

• M: Modified (Last Data Written / Content Modified)
• A: Accessed (Last Read / Touched by OS or Application)
• C: MFT Altered / Changed (Metadata modified in $MFT)
• B: Born (Created / Original Inception on Volume)

Crucially, NTFS stores these four timestamps in two separate MFT attributes for every single file:

+-------------------------------------------------------------------------+
|                        1024-BYTE MFT RECORD LAYOUT                      |
|                                                                         |
|  +-------------------+  Offset 0x00 - 0x2F: Record Header               |
|  |   Record Header   |  Magic 'FILE', Sequence Number, Flags (In-Use)   |
|  +-------------------+                                                  |
|  |                   |  Offset 0x30+: ATTRIBUTE 0x10                    |
|  | $STANDARD_INFO    |  • MACB Timestamps (Modifiable by User-Space)    |
|  |     (0x10)        |  • File Attributes (Read-only, Hidden, System)   |
|  |                   |  • Visible to Windows Explorer & CLI 'dir'       |
|  +-------------------+                                                  |
|  |                   |  Variable Offset: ATTRIBUTE 0x30                 |
|  |    $FILE_NAME     |  • MACB Timestamps (KERNEL PROTECTED)            |
|  |     (0x30)        |  • UTF-16 File Name & Length                     |
|  |                   |  • Parent Directory Inode Reference              |
|  +-------------------+                                                  |
|  |   $DATA (0x80)    |  Variable Offset: File Content Data Runs         |
|  +-------------------+                                                  |
+-------------------------------------------------------------------------+

Comparing $STANDARD_INFORMATION (0x10) and $FILE_NAME (0x30)

The Critical Architectural Vulnerability in Timestomping

When a threat actor uses automated post-exploitation modules (such as Metasploit's timestomp or PowerShell (Get-Item payload.exe).CreationTime = '01/01/2021'), the tool calls the standard Win32 function:

BOOL SetFileTime(
  HANDLE         hFile,
  const FILETIME *lpCreationTime,
  const FILETIME *lpLastAccessTime,
  const FILETIME *lpLastWriteTime
);

The Windows subsystem directs SetFileTime exclusively to the $STANDARD_INFORMATION (0x10) attribute. The Windows kernel API explicitly denies user-mode processes the ability to modify $FILE_NAME (0x30) timestamps. As a result, the forged timestamps appear in Windows Explorer, but the genuine historical creation and modification times remain permanently recorded in the 0x30 attribute.

---

The Four Definitive Signatures of Timestomping

Forensic examiners detect timestomping by evaluating four distinct anomalous signatures:

+-------------------------------------------------------------------------+
|                    TIMESTOMPING ANOMALY TAXONOMY                        |
+-------------------------------------------------------------------------+
|  1. 0x10 vs 0x30 CHRONOLOGICAL INVERSION                                |
|     $STANDARD_INFO Born date precedes $FILE_NAME Born date.             |
|     Logically impossible: a file's metadata cannot exist before its     |
|     directory filename entry is allocated by the kernel.                |
|                                                                         |
|  2. NANOSECOND ZERO-PADDING TRUNCATION (.0000000Z)                      |
|     Win32 APIs round time values to seconds or milliseconds.            |
|     True NTFS timestamps record 7 decimal places (100-nanosecond).      |
|                                                                         |
|  3. MFT RECORD NUMBER VS. CREATION DATE SKEW                            |
|     High MFT Record Number (e.g., #185,420) paired with an ancient      |
|     creation date (e.g., 2021 OS install) among low MFT records.        |
|                                                                         |
|  4. $UsnJrnl / $LogFile TRANSACTION DISCREPANCIES                       |
|     Non-volatile transaction records reveal true file creation events   |
|     and file system operations that bypass MFT timestamp alterations.   |
+-------------------------------------------------------------------------+

1. Chronological Inversion ($STANDARD_INFO vs. $FILE_NAME)

When an attacker copies a staging payload (dropper.exe) to a system on September 22, 2026, and timestomps its creation date to match a 2021 operating system baseline:

• $STANDARD_INFORMATION (0x10) Created: 2021-05-18 12:45:00 UTC
• $FILE_NAME (0x30) Created: 2026-09-22 03:14:22 UTC

Forensic Rule: In an unmanipulated NTFS file system, $FILE_NAME timestamps are established when the file is created on that volume. $STANDARD_INFORMATION timestamps can be modified during standard copy/move operations, but a file's $STANDARD_INFORMATION creation timestamp can never legitimately predate its $FILE_NAME creation timestamp on the target volume. A discrepancy where $0x10 < 0x30$ is definitive proof of timestamp manipulation.

2. Nanosecond / Millisecond Zero-Padding Anomalies

Windows NTFS represents time as a 64-bit integer tracking the number of 100-nanosecond intervals that have elapsed since January 1, 1601 (UTC). This provides a temporal precision of seven decimal places:

$\text{Timestamp Format: } \text{YYYY-MM-DD HH:MM:SS.1234567Z}$

When legitimate operating system processes create or modify files, the lower-order sub-millisecond nanosecond counters contain genuine, high-entropy clock ticks. However, when user-space APIs (such as older versions of Metasploit timestomp, standard PowerShell assignments, or command-line wrappers) write timestamps:

1. The API truncates or zeroes out the sub-millisecond resolution.
2. The resulting timestamp ends with unnatural trailing zeroes (e.g., .0000000Z or .1230000Z).

Legitimate Windows Binary (svchost.exe):
  Created:  2021-05-18 12:45:03.8492015Z  <-- Authentic 100-ns tick entropy

Timestomped Binary (beacon.dll):
  Created:  2021-05-18 12:45:00.0000000Z  <-- Truncated: Nanoseconds zero-padded!
  Modified: 2021-05-18 12:45:00.0000000Z  <-- Truncated: Nanoseconds zero-padded!

3. MFT Record Sequencing Inconsistencies

The Master File Table allocates 1024-byte record structures sequentially. As files are written to disk over time, newly allocated MFT records receive monotonically increasing MFT Entry Indices (Record Numbers):

• Records 0–15: Reserved for NTFS system metadata files ($MFT, $LogFile, $Volume, $Bitmap).
• Records 16–45,000: Typical allocation range for the base operating system installation.
• Records 100,000+: Files created weeks, months, or years after initial deployment.

If an examiner encounters a file claiming to have been created during the initial operating system installation (e.g., May 2021) with an MFT Record Number of #189,450, while all surrounding system binaries created in May 2021 occupy MFT Record Numbers between #18,000 and #24,000, the file is flagged for severe sequence skew, confirming late introduction to the volume.

---

Correlating with NTFS Transaction Journals: $UsnJrnl and $LogFile

Even when advanced adversaries attempt kernel-level direct disk writes to modify both the 0x10 and 0x30 attributes, secondary NTFS transaction logging architectures defeat the anti-forensic attempt.

The Update Sequence Number (USN) Journal ($UsnJrnl:$J)

The USN Journal is an alternate data stream located at $Extend\$UsnJrnl:$J. It provides an append-only log that tracks every modification made to files and directories on the volume. Each record contains:

• MFT Record Number & Sequence Number
• Parent Directory MFT Record Number
• Timestamp of Transaction (UTC)
• Update Reasons (Bitmask Flags):
  • USN_REASON_FILE_CREATE (0x00000100): File was created.
  • USN_REASON_DATA_EXTEND (0x00000002): File size increased / data written.
  • USN_REASON_BASIC_INFO_CHANGE (0x00008000): Metadata altered (e.g., attributes changed via SetFileTime).
  • USN_REASON_FILE_DELETE (0x00000200): File deleted.
  • USN_REASON_CLOSE (0x80000000): Handle closed; operation finalized.

Crucially, timestomping tools do not alter the historical entries in $UsnJrnl. When a threat actor timestomps a file, the action itself triggers an operating system event that appends a new record to the journal flagged with USN_REASON_BASIC_INFO_CHANGE bearing the true current system time!

Chronological Reconstruction from $UsnJrnl:$J Parsing:

USN Offset   Timestamp (UTC)            MFT Ref   File Name    Update Reasons
----------   ---------------            -------   ---------    --------------
0x0041F800   2026-09-22 03:14:22.184Z   #142010   beacon.dll   FILE_CREATE | DATA_EXTEND
0x0041FA20   2026-09-22 03:14:23.901Z   #142010   beacon.dll   DATA_OVERWRITE | CLOSE
0x0041FB80   2026-09-22 03:14:28.415Z   #142010   beacon.dll   BASIC_INFO_CHANGE | CLOSE

Result: Proves conclusively that beacon.dll was born on Sept 22, 2026 at 03:14:22 UTC
and timestomped 6 seconds later (BASIC_INFO_CHANGE at 03:14:28 UTC)!

---

Forensic Tooling & Practical CLI Analysis Workflow

Digital forensic examiners utilize Eric Zimmerman's MFTECmd, The Sleuth Kit (TSK), and Python parsing utilities to uncover timestomping artifacts.

1. Automated Detection with Eric Zimmerman's MFTECmd

:: Parse the raw $MFT into a comprehensive CSV analysis structure
MFTECmd.exe -f "E:\Evidence\C\$MFT" --csv "C:\Analysis\Output" --csvf mft_parsed.csv

MFTECmd parses both 0x10 and 0x30 attributes into adjacent columns in the output CSV:

• Created0x10 vs. Created0x30
• LastModified0x10 vs. LastModified0x30
• LastRecordChange0x10 vs. LastRecordChange0x30
• LastAccess0x10 vs. LastAccess0x30
• Copied0x30: MFTECmd flag asserting if a file was copied or altered.

PowerShell Command to Filter Timestomped Files from MFTECmd Output:

# Query parsed MFT records where 0x10 Born date predates 0x30 Born date
Import-Csv C:\Analysis\Output\mft_parsed.csv | Where-Object {
    [DateTime]$_.Created0x10 -lt [DateTime]$_.Created0x30
} | Select-Object EntryNumber, FileName, Created0x10, Created0x30, LastModified0x10, LastModified0x30 |
Format-Table -AutoSize

2. Low-Level Inode Inspection via The Sleuth Kit (TSK) istat

# Inspect MFT record index 142010 directly from a raw bit-stream disk image
istat -o 2048 /evidence/disk_image.raw 142010

Output Analysis:
MFT Entry: 142010
Sequence: 1
Allocated File

$STANDARD_INFORMATION (0x10):
  Created:       2021-05-18 12:45:00.0000000 (UTC)  <-- Zero-padded sub-seconds
  File Modified: 2021-05-18 12:45:00.0000000 (UTC)
  MFT Modified:  2026-09-22 03:14:28.4150124 (UTC)  <-- MFT record change untouched!
  Accessed:      2026-09-22 03:14:22.1841102 (UTC)

$FILE_NAME (0x30):
  Name:          beacon.dll
  Created:       2026-09-22 03:14:22.1841102 (UTC)  <-- TRUE CREATION TIME!
  File Modified: 2026-09-22 03:14:23.9014521 (UTC)
  MFT Modified:  2026-09-22 03:14:23.9014521 (UTC)
  Accessed:      2026-09-22 03:14:22.1841102 (UTC)

Notice the clear forensic proof:

1. The $STANDARD_INFORMATION created date was forged to 2021 with .0000000 zeroes.
2. The $FILE_NAME created date remains firmly anchored at 2026-09-22 03:14:22 UTC.
3. The $STANDARD_INFORMATION MFT Modified (C) timestamp reveals the exact moment the timestomping tool modified the record (2026-09-22 03:14:28 UTC).

---

Real-World Forensic Case: The Trojanized DLL in System32

Case Background

During a suspected nation-state incident response on an Active Directory Domain Controller, threat hunters observed an unusual outbound beacon over HTTPS to an external IP. The executable communicating was identified as rundll32.exe invoking a dynamic link library: C:\Windows\System32\networkdiag.dll.

The Forensic Challenge

A preliminary triage performed by an IT administrator reported that networkdiag.dll was harmless because Windows Explorer reported its creation and modification date as April 12, 2021 09:15:22 AM—the identical date when Windows Server was initially installed on the physical host.

The Examiner's Investigation

1. The CHFI investigator acquired a bit-stream physical image of the system drive using a hardware write-blocker.
2. Running MFTECmd to parse the $MFT, the investigator queried networkdiag.dll (MFT Entry #210,482):
   • Created0x10: 2021-04-12 09:15:22.0000000Z
   • Created0x30: 2026-09-20 22:11:05.6124501Z
3. The chronological inversion ($0x10 < 0x30$) and nanosecond zero-padding immediately confirmed timestomping.
4. Parsing $Extend\$UsnJrnl:$J using Zimmerman's extractUsnJrnl revealed an entry for networkdiag.dll at 2026-09-20 22:11:05 UTC with reasons FILE_CREATE and DATA_EXTEND, followed by a BASIC_INFO_CHANGE event at 22:11:09 UTC.
5. Correlating with Windows Event Log ID 4688 (A new process has been created) and PowerShell Script Block Logging (Event ID 4104), the examiner discovered a PowerShell command that staged the DLL and immediately invoked SetFileTime using the timestamp of kernel32.dll.
6. The evidence of timestomping was successfully presented in court to prove deliberate manipulation and intentional concealment of malicious software.

---

CHFI Exam Tips & Pitfalls

[!TIP]

• 0x10 vs. 0x30 MFT Attributes: Remember that 0x10 ($STANDARD_INFORMATION) is the attribute altered by user-space APIs and seen by Windows Explorer. 0x30 ($FILE_NAME) is updated exclusively by the NTFS kernel driver and cannot be modified by standard Win32 calls like SetFileTime.
• The Inversion Indicator: An exam question asking for definitive proof of timestomping will frequently present timestamp tables. Look for $STANDARD_INFORMATION Created date earlier than $FILE_NAME Created date.
• Sub-second Rounding: Authentic NTFS timestamps contain 7 decimal digits of precision (100-ns intervals). Timestomped entries created by standard APIs often exhibit .0000000Z or round to full seconds.
• USN Journal Resilience: Even if an attacker uses direct hex editing or custom kernel drivers to overwrite both 0x10 and 0x30, the $UsnJrnl:$J journal captures the BASIC_INFO_CHANGE and file creation transactions with non-forgeable timestamps.