NTFS Timestamp changes on Windows 10

During my File System Tunneling related investigation I tested NTFS timestamp changes in case of different operations on Windows 10. I used SANS’s DFPS_FOR500_v4.9_4-19 and Cyberforensicator’s timestamp posters for comparison. I found out that my results were different from theirs. In my tests, some of the operations produced different timestamp changes and inheritance than the previously mentioned posters show. These timestamp rules can change in every Windows version so it is worth checking them from time to time. I experimented with some basic operations, compared them to the above mentioned posters and documented my findings in this post.

MACB / MACE timestamps

Windows systems handle four different types of timestamps for a file. These timestamps are:

1. Modification ( M )
2. Access ( A )
3. Change ( C ) / $MFT Entry modified (and not Creation)
4. Birth ( B )

Or

1. Modification ( M )
2. Access ( A )
3. Created ( C )
4. Entry Modified ( E )

I’m going to use the first abbreviation in this post. Some of the timestamps exist on one file system but can be non-existent on other. Also their meaning can vary depending on the different filesystems. Here is a table from sleuthkit’s site about the meaning of timestamps.

Windows stores these timestamp values in the $MFT (Master File Table). Every NTFS volume has its own $MFT file which is stored in the special MFT zone on the given volume. Read more about the $MFT here.

NTFS timestamps are stored as 64-bit unsigned little-endian integers. The resolution of the timestamps is 100 nanoseconds counting from Jan 1, 1601, and all of them are stored in UTC format. This kind of high resolution allows the forensicator to easily differentiate between actions and put them into order. Unlike in case of FAT timestamps in which the resolutions are 10 ms / 2 s / 1 day (for different timestamps) that makes the ordering much harder.

$STANDARD_INFORMATION vs. $FILE_NAME

The MACB timestamps are stored in two different attributes in the $STANDARD_INFORMATION and $FILE_NAME attribute. These attributes store different metadata and while only one $STD can exist for an entry, there can be multiple $FNs for a file. “Multiple FN attributes may exist, since there are four name spaces; for DOS 8.3 names, Windows names, POSIX names, and a shared namespace for filenames compatible with both DOS and Windows. An entry can thus have up to three FN attributes” (Timestomping NTFS - July 7th, 2014 - by Wicher Minnaard).

One important difference is that $STD can be modified by user-level processes, therefore, most of the timestamp manipulating tools only modify this value. $FN can only be changed by the system kernel. According to reports, no anti-forensic utility can modify the $FN values yet. (At least I don’t know any of them, but this can be done by directly accessing the $MFT file so there is a chance it already exists somewhere. The system can be forced to change the $FN values as well, but this post is not about anti-forensics).

Testing environment and methods

Used system: Windows: Win 10 Pro, V1803, Build: 17134.706

I used [CyLR] (https://github.com/orlikoski/CyLR) to collect MFT files and parsed the values with analyzeMFT.py.

The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate registry key was left on the default value which is: dword:80000003. This value means: System Managed, the “Last Access” updates are disabled.

For the CLI based testing, I used Powershell commands which will be detailed in the section of the given test.

I didn’t just want to make a test but I wanted to compare them to already existing and reliable results. For this, I used the already mentioned two posters.

Cyberforensicator’s poster:

The relevant part of the SANS’s Windows poster:

This was the most relevant information publicly available from SANS I could find.

Tests

Throughout my tests, I’m marking the non-changed/inherited values with green and the changed timestamps with yellow. The change of the time is the time of the command execution like create, copy, rename, etc.

File Creation and Deletion

Evidently, in case of a file creation, every timestamp is going to be new. Since no file existed earlier, none of the timestamps could be inherited. Therefore every one of them is going to be a new one. A good exception is the File System Tunneling though. In case of FST, the creation time is going to be inherited from a previously existing file with the same name. For more details read my post about File System Tunneling.

The deletion may not be that trivial but it is stilll logical. When it comes to file deletion, the timestamps are not changed. No timestamps are touched but the file is marked as Inactive so the removal of the file is still going to be marked in the metadata.

For this test, I’m not going to provide values or comparisons.

File Rename

According to my test, the rename operation only changes the metadata timestamp the others are going to stay intact. The same can be seen on the linked posters. I copied the timestamp rules from the posters into my picture for better comparison.

The commands I used for creating and renaming the file:

New-Item "file_rename_test.txt" -ItemType file
Rename-Item -Path "file_rename_test.txt" -NewName "file_rename_newname_test.txt"

File Modification

Based on my test the $STD Modification, Access and Metadata timestamps were the only ones which were updated. The interesting value here is the time of the Access timestamps. The Modification and Metadata got the values of the execution time and date while the Access was set to a bit later time (~2 secs). I have done this test multiple times and in every scenario, the Access timestamp was differed from the other two.

I got different results from Cyberforensicator or SANS. In case of the former one, some of the $FN values are also updated but none of the $FN timestamps are changed during my test. The $FN values are untouched according to SANS but in its case, the Access timestamp is not changed. However, it was changed in mine. Thus, it looks like all three of the results are a little bit different in relation to file modification.

The command I used to create and modify the file:

New-Item "file_modification_test.txt" -ItemType file
Set-Content -Path .\file_modification_test.txt -Value 'Modified Content'

File Copy

I performed two different copy tests. During the first test, I copied the file to a different directory while in the second one, I copied it to a different volume. I got the same results so I’m not going to differentiate between them. I also performed some tests in the past for Windows 7 and I made a GUI based CTRL+C CTRL+V test as well. The Win7 copy test resulted in different timestamp changes which can be seen in this pdf of mine or in this URL on David Cowen’s blog. For Windows 10 the GUI and CLI based tests generated the same results.

In case of file copy, I got the same outcome as Cyberforensicator and SANS. SANS’s poster is not exactly clear in this case though. The color of the $STD Metadata refers to timestamp inheritance from the original file while the label says “Time of File Copy”. I think the label is not correct here simply because me and Cyberforensicator got different results which align with the coloring of the SANS poster.

The following changes are valid in case of Windows 10 for GUI or CLI based copy operation:

Powershell command for this test:

New-Item "file_local_copy_test.txt" -ItemType file
New-Item -Path "dest_folder" -ItemType directory
Copy-Item -Path "file_local_copy_test.txt" -Destination "dest_folder\file_local_copy_test.txt"

BITS Transfer Job copy

I tested a file copy with the BITS (Background Intelligent Transfer Service) Transfer as well. I copied a file with the Start-BitsTransfer Powershell command. (this test wasn’t performed by Cyberforensicator or SANS)

The intriguing results I found is the update in the $FN timestamps. Only the Metadata timestamp is updated from the $FN attribute. This is interesting because this is the only operation between the tested ones which resulted only in the change of the Metadata timestamp from the $FN attribute. In my previous File System Tunneling test I also found a set of operations which resulted in the change of Metadata timestamp only between the $FN timestamps. Earlier I thought this change can be used to identify a specific type of File System Tunneling but it looks like BITS Transfer Job can cause similar changes on the $FN values. The difference is that this time the $FN Modification was changed to the execution time while in case of FST it was set to the time of a previous action (and not the time of the recent operation).

Powershell commands for this test:

New-Item "E:\file_volume_bits_test.txt" -ItemType file
Start-BitsTransfer -Source "E:\file_volume_bits_test.txt" -Destination "file_volume_bits_test.txt"

Local File Move

In this test, the source and the destination of the file move is the same volume/partition. CLI and GUI based testing resulted in the same timestamp changes. I also made this test in the past which I used to participate in David Cowen’s Sunday Funday. For more details, one can check the previously mentioned link or download my pdf.

I did not find any difference/discrepancy during this test.

Powershell command for this test:

New-Item "file_local_move_test.txt" -ItemType file
New-Item -Path "dest_folder" -ItemType directory
Move-Item -Path "file_local_move_test.txt" -Destination "dest_folder\file_local_move_test.txt"

Volume File Move - Powershell

Moving a file from a certain volume to a different one via Powershell (or cmd). Find my previous test on this link and in this pdf. No difference/discrepancy was found by me.

User powershell command:

New-Item "file_volume_move_test.txt" -ItemType file
Move-Item -Path "file_volume_move_test.txt" -Destination "E:\file_volume_move_test.txt"

Volume File Move - GUI

This test was performed by me in the past when I participated in David Cowen’s Sunday Funday. I didn’t repeat this test now so I won’t' be able to provide precise timestamps. But I’m still going to provide a comparison with SANS’s poster. Cyberforensicator didn’t test this situation so I can’t compare it with that results. According to this earlier test of mine, there is some discrepancy from SANS’s results. In my test the $STD Metadata was changed as well but this is the only difference I found in this case. The test was performed with CTRL+C CTRL+X shortcuts.

For more information about this test see the link or download the given pdf.

Timestamp rule table

I created a table to show in which cases I found a difference.

1. Green “Match”: my result matches the value on the given poster
2. Red “No Match”: my result is different
3. Grey “No Test”: the given test wasn’t documented on the given poster

I made a merged timestamp rule table as well from the results of my investigation. One can see that my results are a little bit different from the other tests. I did not generate a fancy poster for now, I think the results can be seen properly on the following image as well. I hope you will find these results useful during your investigation.

Update 2019-05-07: Cyberforensicator created its test by using Office. MS Office doesn’t follow the time rules though, this can be the reason behind some of the differences between my tests and Cyberforensicator’s tests.