Behind the clock | Detecting Timestomping in Windows

Hello! and welcome back everyone. In this write-up we’ll go through few methods to detect timestamp manipulation of files in NTFS. We’ll first try to manipulate the timestamps of a particular file using the known available free timestomping tools and then try to check if timestomping took place using various NTFS forensic filesystem artifacts. Later we’ll verify the timestomping and try to find the original timestamps of the file.

◼️ What is timestomping?

It is an anti-forensic technique that involves modifying filesystem metadata timestamps to hide or cover any tracks of operations and interactions with a file. If a forensic tool shows a timeline of events, a timestomped file may not show in a suspicious timeframe or if a malware was executed and exists with back-dated timestamps it may not show up in a rule like “executable created within last 24 hours AND executed”

◼️ Key Terminologies:

1. MACB timestamps: Windows file-time stored in 64-bit format. “M” means “Last Modified Time” . “A” means “Last Accessed Time”. “C” means “MFT Record Change Time”. “B” means “The Birth or Creation time of file”. Sometimes it is also called as MACE times.
2. $STANDARD_INFORMATION ($SI)($10) attribute: We know that this attribute is found in MFT records and it stores the file timestamps.
3. $FILE_NAME ($FN) ($30) attribute: Another attribute found in MFT record which also stores the file timestamps.
4. $MFT: The Master File Table contains an entry for every files and directories in the volume including itself. It contains the $SI and $FN timestamps. It is a hidden, system file.
5. $UsnJrnl: System file, hidden which records high-level operations like file creation, deletion, renaming, data change in the volume. Stores timestamps.
6. $LogFile: System file, hidden, keeps the low-level changes record like metadata changes to the volume. Also keeps timestamps.
7. $I30 (NTFS INDX records): System file, hidden. It stores a structured list of files in a folder/directory. It also stores the MACB timestamps along with the filename and file sizes. The $I30 timestamps are usually reflected in the Windows explorer.

◼️ Below is a SANS poster which shows in what scenarios a particular file-time can change:

Without further do let’s get started. First we will test the timestomping on a NTFS VHD attached as physical drive and then we move on to an NTFS formatted USB thumb drive and view the same.

◼ ️Tool Links: 1. nTimetools 2. SetMace 3. Zimmerman Tools 4. LogFileParser 5. INDXParse

◼️ CASE 1:

We create a VHD using virtual box or other such tools, attach the VHD and initialize and format the disk as NTFS file system. We then create a text file named “sensitive.txt” with random content and observe the file timestamps. To view the timestamps we can either image the drive using FTK and analyze the exported $MFT file or we can use the tool SetMace.exe to directly view the file record by point the file from the attached VHD volume. For now, we’ll use the SetMace.exe tool.

Above the setmace tool shows us the real MACB timestamps in both the $SI and $FN attributes. We observe that all the timestamps are from date 2026–06–11. Along with that we can observe a few more information such as MFT record entry no. of sensitive.txt is 50 which will help us later.

Now we use another tool ntimestomp by ntimetools and try to modify timestamps of the “sensitive.txt” file show below.

We see the ntimestomp tool ran succesfully and showed that the timestamps were modified. So we verify it with the setmace.exe tool.

In the above image it is interesting to note that the ntimestomp tool indeed modified the timestamps of the $STANDARD_INFORMATION attribute. But if we look closely, the $FILE_NAME attribute timestamps have not changed and remained the same as the original and having MFT Entry no. 50. Hence we can say that not all the timestamps were modified which can be detected easily. This can also be verified using the MFTEcmd tool by Eric Zimmerman which is shown below.

Now we’ll only use the SetMace.exe tool, which is also a timestomping tool and we’ll try to modify all the timestamps of the sensitive.txt file.

Above we can observe that the SetMace.exe tool ran successfully for sensitive.txt having MFT entry no. 50 and shows that it successfully wrote the new timestamps. Let’s verify it.

So, this time we can view that both the $SI and $FN attribute timestamps were modified and it is not possible to conclude about the timestomping from here. So, we now go check our $MFT file record no. 50 and see what’s still left there. We’ll first export the $MFT file using FTK imager and then use the same command line tool MFTEcmd by Eric Zimmerman and point it to the exact entry no. 50.

Now in the above image we can observe that both the $SI and $FN attribute timestamps were successfully modified by SetMace but there is another attribute that is $OBJECT_ID ($40) which keeps a record of the object Id creation time along with a GUID. The timestamp is of 2026–06–11 16:48:20.89, the date matches exactly the original filetime but there is a time difference which maybe due to the initialization of the VHD. So, we still can’t clearly deduce much here. So we need to analyze the $UsnJrnl to track all the changes that took place within the MFT entry no.50 . We’ll use the same MFTEcmd tool to parse the exported $J file.

Now we have a better view of the scenario. If we filter by the entry 50 on Timeline explorer we can see all the changes that took place from beginning till end of the file operations. And the timestamps also matches the original timestamps. Hence we can conclude that the timestamps were modified and also we have the original timestamps.

◼️ CASE 2:

What if there is no $UsnJrnl ? Then how’ll we track the file operations and timestamps? This time we will use a removable media, a SanDisk USB thumb drive formatted as NTFS. Windows doesn’t enable UsnJrnl in removable drives by default.

First we create a file named “timestomp.txt” inside the USB drive and run the SetMace.exe on the file. After that we image the USB drive and export the $MFT file $LogFile and $I30 file of the directory. Let’s see the SetMace output.

All timestamps are from the year 2024. Let’s see if the timestamps were modified. Let’s use the MFTEcmd tool on the MFT entry no. 39 which is the record number for the file “timestomp.txt”.

We observe that both the timestamps were indeed changed but again there is the $OBJECT_ID attribute which gives us a hint that something is not right. But this time we don’t have the $UsnJrnl:$J to track all the file operations. But we know that the $LogFile also keeps a track of the timestamps let’s check if we can find something there.

We’ll use NTFS $LogFile parser tool on the exported $LogFile.

We now open the $LogFile parser output and search for the file filename “timestomp.txt” and we’re able to view something, the timestamps, the $SI and $FN original timestamps. So we can conclude that the timestamps were modified and what we can view in the $Logfile are the original timestamps.

Now let’s analyze the exported $I30 file in a tool called INDXParse, as the tool name itself says that it parses INDX records. As we already know previously that it also contains the timestamps along with the filenames.

We redirect the output of the INDXParse tool to a csv file and open the csv in timeline explorer. (Ignore the errors in the stdout).

In the parsed $I30 output we observe the modified MACB timestamps and not the real one (2026–06–10). We know previously that both the $SI and $FN of the “timestomp.txt” are modiefied. To get a better perspective, we again create a new file named “I_30test.txt” with random content and this time use ntimestomptool to modify only the $STANDARD_INFORMATION timestamps. And run the INDXParse tool on the new exported $I30 file.

Now from the above three images and comparing the $I30 output, $LogFile output, $SI, $FN timestamps we can conclude that timestamps shown in the windows explorer for both the files are modified or stomped.

◼️ NOTE 1: The tested tools doesn’t work in modifying $FILE_NAME timestamps on locked NTFS drives as this needs to go through the Kernel level. The tools like SetMace operate on the raw device level, dismounting the drive, bypassing the NTFS driver entirely. On a locked system volume cannot get pass that lock because the OS itself holds it. To know more about how SetMace works tool link is already provided above.

◼️ NOTE 2: Certain timestamp modification tools modify only the $STANDARD_INFORMATION CreationTime and LastWriteTime that is “B” time and “M” time respectively. It keeps MFT record change time and LastAccessTime unchanged. They also keep $FILE_NAME MACB timestamps untouched. This makes it more convenient to detect the timestomping. An example is shown below:

Thank you very much for reading. Have a great day!! Please do comment if there is any errors or suggest best practices to follow :)

THE END…