NTFS Forensics: Detecting Timestamp Manipulation

 

Timestamp modification on NTFS volumes may arise from both legitimate operational requirements and malicious intent. A representative legitimate use case involves modern cloud synchronization clients. Services such as Dropbox strive to preserve temporal fidelity across devices: the last-modified timestamp of a file should reflect the actual moment of user modification, regardless of when or where the file is subsequently synced.

When the Dropbox client (or similar) is installed on a new host and performs an initial synchronization, the operating system perceives the incoming files as newly created. By default, Windows assigns the current system time to all $STANDARD_INFORMATION timestamps of newly created files. To maintain consistency with the authoritative metadata stored in the cloud, the client invokes Windows APIs (e.g., SetFileTime) to deliberately backdate the relevant timestamps—most commonly the modified time and, in some implementations, the Creation time as well—to align with the cloud-recorded last-modified value. The precise timestamps propagated vary by provider and client version, but the preservation of the Modified timestamp is nearly universal.

Conversely, malicious actors routinely manipulate timestamps to achieve concealment. The primary objective is to embed malware within the temporal “noise” of the file system, reducing the likelihood of detection during forensic timeline analysis. A canonical tactic involves placing trojanized binaries in high-trust directories such as C:\Windows\System32, renaming them to mimic legitimate system processes, and adjusting their timestamps to harmonize with surrounding legitimate files. This practice, widely known as timestomping (derived from the seminal tool “timestomp”), enhances blending and complicates anomaly detection.

Historically, offensive tools exhibited limitations that aided detection. Many operated with only second-level precision, lacking the 100-nanosecond granularity native to Windows FILETIME structures. Consequently, timestamps landing exactly on the second boundary (with zero sub-second components) represented a statistical outlier and a strong indicator of manual intervention. Another reliable artifact was the divergence between the $STANDARD_INFORMATION and $FILE_NAME Creation timestamps, since most early tools could only modify the user-accessible $SI set.

Contemporary timestomping utilities have evolved to counter these detection vectors. Advanced tools can designate a “reference” legitimate file and atomically copy its full complement of $SI and $FN timestamps (including 100-nanosecond precision) to the target. This technique largely neutralizes both sub-second anomaly detection and cross-attribute comparison methods, necessitating more sophisticated analytic approaches—such as statistical timestamp distribution analysis, correlation with USN Journal entries, prefetch artifacts, and behavioral context—to identify sophisticated timestamp forgery.

Detecting timestomping relies on either finding traces of the very act itself, or on finding inconsistencies introduced by the tampering. While previous research had focused on using timestamp rules to identify specific user actions, Xiaoqin Ding and Hengming Zou (2010) were the first to use these rules to identify timestamp manipulation using a set of conditions. For all file types, timestamps should satisfy conditions: $SI.M <=$SI.E, $SI.C<=$FN.C, $SI.C<=$SI.A. If any is false, the timestamps were probably tampered with anti-forensic tools. They were able to prove timestamp manipulation in an example case by comparing the values in the $FNA to the values in the $SIA and identifying inconsistencies. But some intra volume replacement may cause $SI.C>$FN.C or $SI.C>$SI.A and the corresponding $SI.E indicates the time of replacement. If $SI.E< $FN.E, the timestamps are unreliable.

If $SI.C<$FN.C and $FN.M=$FN.A=$FN.C=$FN.E, we can conclude that the file was moved from another volume and $FN.C is the last moving time. Meanwhile, the file has not been renamed or moved after being relocated to the current volume.

If the condition $FN.M=$FN.A=$FN.C=$FN.E is false, while $SI.C<$FN.C and $SI.E>$FN.E is true, the file is replaced by another file with the same name and type in the same volume, and this file is created after the creation of the file that has been replaced. If $FN.M=$FN.A=$FN.C=$FN.E is false, but $SI.C=$FN.C, then $FN.MACE is copied from the $SI.MACE before the last renaming or moving within the volume.  

If $SI.C>$SI.M, then the contents and the summary property of the file have not been modified in the current volume; If $SI.C=$SI.M, the file have not been modified since its creation; If $SI.C<$SI.M, $SI.M is the last modification time of the content or summary property of the file in the current volume. 

For office files, if $FN.M=$FN.A=$FN.E>$SI.C, then $FN.M is the last modification time of the file contents in the current volume. If $SI.E=$FN.M also holds, then no renaming or intra-volume move happened after the modification. If $SI.E>$SI.M, the $SI.E is the time of last renaming/intra-volume moving/general property modification. If $SI.M=$FN.M is not satisfied, the timestamps must be altered. If $SI.M=$SI.E>$SI.A>=$SI.C, the $SI.M is the time of last modification on general property of the file.

For .exe files, $SI.E time of the .exe file must be newer or equal than the other seven timestamps. If this is not true, then they are not reliable.

For directories,  the timestamps should satisfy $SI.M<=$SI.E, $SI.C=$FN.C, $SI.C<=$SI.A. If anyone is false, the timestamps are unreliable. If $SI.M=$SI.A=$SI.E>$SI.C, $SI.E indicates the last time of content change in the target directory. For each file or subdirectory, if its $SI.E times is the same as that of the parent directory, then this file or subdirectory is recently added or renamed. If no such file or subdirectory is found, then delete operations must have been performed within the directory.

Because timestomping tools and techniques are capable of altering all eight timestamps in the $MFT with nanosecond precision, none of the aforementioned rules can be utilized to identify timestamp manipulation (as long as an attacker followed the rules). This, therefore, compels an analyst to consider other detection methods.

In practice, digital forensic examiners must evaluate timestamp sets holistically, remaining cognizant of both benign synchronization behaviors and the increasing sophistication of anti-forensic capabilities. A multi-faceted analytic approach is essential for identifying timestomping and other forms of temporal forgery on NTFS volumes. The following techniques leverage inherent structural and behavioral characteristics of the file system:

1. Cross-Attribute Timestamp Comparison: Systematically compare the four-timestamp quartet in the $FILE_NAME ($FN) attribute(s) against the corresponding values in $STANDARD_INFORMATION ($SI). Many legacy and even some contemporary timestomping utilities fail to update the kernel-protected $FN timestamps, particularly when a perpetrator manually specifies arbitrary values. This discrepancy remains a reliable indicator of manipulation. Recommended tools capable of exposing both attribute sets include: MFTECmd, fls (from The Sleuth Kit), istat, and FTK Imager (version 2+).
2. Sub-Second Precision Analysis: Scrutinize timestamps for zeroed fractional seconds (i.e., values landing exactly on a second boundary with all decimal places zeroed). Windows FILETIME structures support 100-nanosecond resolution; natural system-generated timestamps rarely exhibit perfect second alignment. This artifact is especially pronounced with tools that lack high-precision API usage. Effective tools offering sub-second visibility (outside bodyfile output) include MFTECmd and istat.
3. ShimCache (AppCompatCache) Correlation: For executable files, compare the $STANDARD_INFORMATION Modified (M) timestamp against the entry recorded in the Application Compatibility Cache (ShimCache) within the SYSTEM registry hive. The Application Compatibility subsystem typically records the $SI last-modified time and file size upon process execution; note, however, that on some OS versions (notably Windows 7/Server 2008 R2), entries could also be populated via Explorer enumeration or other shell activity rather than execution alone, so the trigger condition should not be assumed uniform across versions. Because executables are infrequently modified—and virtually never legitimately backdated—significant temporal inversion (current $SI M-time predating the ShimCache-recorded value) constitutes a strong corroborating indicator of forgery, though it should be read alongside the artifact's known triggering ambiguity rather than treated as conclusive on its own. Extract $SI modification times using standard filesystem parsers; parse ShimCache with AppCompatCacheParser.exe or ShimCacheParser.py.
4. PE Compile Timestamp Validation: For Portable Executable (PE) files, cross-reference on-disk $STANDARD_INFORMATION timestamps against the embedded compile timestamp in the PE header (IMAGE_FILE_HEADER.TimeDateStamp). Compilation necessarily precedes final disk writes, so a compile time later than the file's Creation or Modified timestamp is anomalous and worth investigating. However, this field is a single, unauthenticated DWORD — trivially editable with any PE editor or hex editor, independent of and unprotected by any NTFS-level mechanism. It is also increasingly unreliable as a baseline for legitimate reasons: reproducible-build toolchains (e.g., Go binaries, MSVC/LLD with /Brepro) routinely zero or normalize this field regardless of attacker involvement. Treat compile-time inversion as a prompt for deeper analysis — never as a standalone proof — and corroborate with SI/FN comparison, ShimCache, or import-table/digital-signature analysis before drawing conclusions. PE parsing tools such as Sysinternals Sigcheck and ExifTool (by Phil Harvey) efficiently extract compile times for comparison.
5. $I30 Directory Index Residuals: Examine stale entries in the parent directory’s $I30 index records. These indexes store filename, a full set of $FN-derived timestamps, and the MFT reference (record number + sequence). Backdating may leave residual entries with more recent timestamps than the current file record, revealing prior states. Detailed analysis of $I30 structures is addressed here.
6. USN Journal Correlation: Query the NTFS Change Journal ($UsnJrnl) for the original creation or modification events. The journal often preserves the authentic creation time of a backdated file, enabling direct comparison with current $SI/$FN values and highlighting discrepancies. Filtering UsnJrnl(J) records for the USN_REASON_BASIC_INFO_CHANGE (0x8000) flag can serve as a triage heuristic when correlated against $STANDARD_INFORMATION (SI) versus $FILE_N​AME(FN) timestamp deltas in the $MFT—since most timestomping utilities (e.g., SetMace) manipulate only $SI attributes, leaving $FN as an immutable forensic baseline.  
   However, recurrent 0x8000 entries for a single file are not, in isolation, anomalous; legitimate processes (AV scanning, indexing services, ACL/attribute modification, and backup agents) routinely generate multiple BasicInfoChange records. Elevated 0x8000 frequency should therefore be treated as a candidate indicator warranting deeper triage—not dispositive evidence of anti-forensic timestamp manipulation absent corroborating SI/FN inconsistency. Furthermore, UsnJrnl is itself a volatile, circular-buffer artifact subject to truncation, journal resets, or deliberate spoliation; it cannot be assumed immune to anti-forensic interference. An attacker could move the journal into unallocated space by running the fsutil usn deletejournal /d c: command and create a new journal in the same location by running the fsutil usn createjournal m=1000 a=100 c: command. While wiping $USNjrnl is straightforward, these commands do trigger Windows to record an event in its application event log: Windows event ID 3079 is created when the $USNjrnl is deleted. This can be a good indication for an examiner that further data manipulation may have occurred on the system. Robust timestomping detection requires cross-artifact correlation—$LogFile transaction analysis, ShellBags, Prefetch residue, and $SI/FN comparison in concert—rather than reliance on a single USN reason-code frequency heuristic.
7. During routine NTFS file-system activity, the $LogFile may record one or several 0x07 (UpdateResidentValue) redo operations against a given MFT record, as this opcode is attribute-agnostic and fires for any resident attribute modification — not timestamps exclusively. Consequently, raw 0x07 occurrence frequency, in isolation, lacks discriminating forensic value as a timestomping indicator. ⁣ A methodologically sound approach requires parsing each 0x07 transaction's target attribute offset to confirm the modification specifically affected $STANDARD_INFORMATION timestamp fields, rather than unrelated resident attributes (e.g., security descriptors, filename attributes, or index data). Where multiple offset-confirmed $SI timestamp rewrites are identified within a compressed LSN sequence—particularly absent corresponding $FILE_NAME attribute updates—this constitutes corroborating evidence of anti-forensic timestamp manipulation, since most timestomping utilities selectively alter $SI while leaving $FN as an immutable baseline. Such LogFile transaction-level analysis should be triangulated against $SI/FN comparison, MFT slack analysis, and $UsnJrnl correlation, rather than relied upon as a standalone opcode-frequency heuristic.
8. MFT Record Number Sequencing Leverage the NTFS allocation strategy: newly created files are typically assigned sequential (or near-sequential) MFT record numbers, especially during bulk operations such as OS installation in C:\Windows\System32. Malware introduced later and backdated to blend temporally will frequently exhibit an outlier MFT record number incongruent with surrounding legitimate files. Timelining tools that output comprehensive MFT metadata—sortable by both temporal values and record number—such as MFTECmd and fls, are particularly effective for this anomaly detection.

Collectively, these methods compensate for the evolving sophistication of anti-forensic tools. No single indicator is dispositive; instead, convergence of multiple anomalies, contextualized with behavioral artifacts (Prefetch, ShimCache, USN, etc.), provides the highest evidentiary confidence in identifying timestamp manipulation.

Windows event logs do not record file timestamps directly. You cannot see a forged timestamp in an event log. What you can detect are:

• Processes, tools, and APIs commonly used to timestomp.
• Suspicious timing relationships between events and NTFS artifacts.
• Metadata-changing behaviour without corresponding file creation.

This makes Event logs corroborative evidence, not a standalone proof. High value event log sources include:

• Event ID 4688 - Process Creation. This is the single most important event. Look for processes known to alter timestamps: powershell.exe, cmd.exe, wmic.exe, python.exe, custom malware loaders, living-off-the-land binaries (LOLBins). Look for suspicious command-line indicators like the PowerShell command (Get-Item file).CreationTime=. Also, look for offensive tools like timestomp.exe, metasploit payloads, and Cobalt Strike BOFs. Process execution times after the forged $SI timestamps but before the $J BASIC_INFO_CHANGE possess a strong correlation value.
• Event ID 4663 - File Access. Look for an Access mask including WRITE_ATTRIBUTES, WRITE_DAC, and access to suspicious files without write activity. Attribute write without content write is a classic timestomp pattern.
• PowerShell operational logs event IDs 4103/4104 detect Script block logging and timestamp manipulation via .NET - [System.IO.File]::SetCreationTime() Set-ItemProperty. Even if the attacker clears $SI, PowerShell logs often persist.
• Event IDs 1, 35, 36, 37 (Microsoft-Windows-Time-Service), and Security event ID 4616 detect system clock changes and time synchronization anomalies. Some attackers change the system time before file creation, then revert it. Sudden clock rollback + old-looking file timestamps + recent USN activity provides strong correlation.

Prefetch files are not stored on NTFS timestamps alone and are harder for attackers to perfectly manipulate compared to $SI/$FN timestamps. They provide:

• Independent execution timing
• Execution frequency
• Referenced file paths (DLLs, EXEs)
• Volume metadata and last execution times

This makes Prefetch an excellent cross-validation for detecting timestomping.  Each Prefetch file stores up to eight last execution times (Win 8+), which are stored internally in FILETIME format, and are not dependent on $SI/FN. If the Prefetch LastRunTime precedes file creation time or postdates file deletion or backdated modification, this is a strong indicator of timestomping. 

Prefetch also maintains an execution counter. If the file claims ancient timestamps (e.g., 2016) but the execution count is greater than 1 and clusters around a recent incident, timestamp manipulation may likely have occurred. 

Prefetch files are created on the first execution of an executable. Compare the prefetch file $SI Creation time with the executable $SI Creation time. If, for example, a pattern such as the one indicated below was detected, the executable was likely introduced recently but backdated.

• Executable Creation Time: 2017
• Prefetch Creation Time: 2025

Each Prefetch file contains a Volume Serial Number and a Volume creation timestamp (from NTFS). This allows for the detection of volume recreation and the detection of copy-in artifacts. If the executable's timestamps predate volume recreation, it is impossible without manipulation.

LNK files are created or updated when a user launches a file via Windows Explorer, the Start menu, Desktop, or Taskbar. Importantly LNK timestamps are independent of the target file timestamps and are rarely modified by attackers. They often capture the true execution timeframe. Thus, discrepancies between the LNK timestamps and target file MACB times can indicate tampering.

Each LNK file has its own NTFS MACE times. Whenever a file is opened on the local machine (either by clicking directly on it or locating it in the File Explorer), the associated LNK's $SI.A and $SI.E times are updated as well. Thus, the $SI.A and $SI.E timestamps for the LNK should approximately match those timestamps for their associated file. This rule excludes the file's $SI.M and $SI.C timestamps because they can vary between a file and its corresponding LNK. However, if a shortcut references an executable whose modified or created time predates the LNK creation by years, the executable may have been tampered with. A LNK cannot be created for a file that does not exist, i.e., the file's $SI.C time is not allowed to be in the future. The LNK's $SI.C time should be equal to or after the $SI.C time listed for its associated file. Similarly, if a LNK's $SI.A time is updated, the corresponding file's $SI.A time should be updated as well. A LNK's $SI.A time should be equal to or before the actual file's $SI.A time. 

Beyond NTFS metadata, LNK files store internal timestamps, including creation time, Modification time, Access time, and File size. These are captured at the time the shortcut was created, not live, and do not update. If the current file timestamps differ from those stored inside the LNK, this suggests post-execution timestamp manipulation.

Timestamp Differences Between NTFS and FAT File Systems

NTFS date-time stamps differ from those recorded on FAT systems in several key ways. First, it is essential to note that NTFS and FAT date-time stamps are not stored in the same locations. Whereas NTFS utilizes the $MFT as its primary repository for date and time metadata, FAT systems record dates and times within folder entries. Another major difference is that NTFS date-time stamps are recorded in UTC, regardless of the time zone set for the system, whereas FAT date-time stamps are recorded in local time; this distinction is important, particularly when interpreting the date-time stamps manually. In addition, NTFS represents date-time stamps using the FILETIME format, which represents the number of 100-nanosecond intervals since January 1, 1601, and can be interpreted by most forensic tools, including free tools such as DCode by Digital Detective.

The FILETIME format is different from the DOSDATETIME, which is primarily used in FAT, which is 4 bytes and starts on January 1, 1980. To confuse matters, on FAT systems the resolution of create time on FAT is 10 milliseconds (additional bytes are used to record hundredths of a second), whereas write time has a resolution of 2 seconds, and access time has a resolution of 1 day, allowing the examiner to be less specific about when a file or folder was last accessed on the file system. Even within NTFS, the use of Last Accessed date-stamps can vary. For example, NTFS delays updates to the last access date-time stamps by up to 1 hour after the last access. Furthermore, by changing (or adding) the registry value HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\NtfsDisablelastAccessUpdate in Windows XP+ to “1” (DWORD), XP+ versions will no longer update the Last Accessed times/dates of files and folders.