File Times

A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC). The system records file times when applications create, access, and write to files.

The NTFS file system stores time values in UTC format, so they are not affected by changes in time zone or daylight saving time. The FAT file system stores time values based on the local time of the computer. For example, a file that is saved at 3:00pm PST in Washington is seen as 6:00pm EST in New York on an NTFS volume, but it is seen as 3:00pm EST in New York on a FAT volume.

Time stamps are updated at various times and for various reasons. The only guarantee about a file time stamp is that the file time is correctly reflected when the handle that makes the change is closed.

Not all file systems can record creation and last access times, and not all file systems record them in the same manner. For example, the resolution of create time on FAT is 10 milliseconds, while write time has a resolution of 2 seconds and access time has a resolution of 1 day, so it is really the access date. The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.

To retrieve the file times for a specified file, use the GetFileTime function. GetFileTime copies the creation, last access, and last write times to individual FILETIME structures. You can also retrieve file times using the FindFirstFile and FindNextFile functions. These functions copy the file times to FILETIME structures in a WIN32_FIND_DATA structure. When writing to a file, the last write time is not fully updated until all handles that are used for writing are closed.

To set the file times for a file, use the SetFileTime function. This function lets you modify creation, last access, and last write times without changing the content of the file. You can compare the times of different files by using the CompareFileTime function. The function compares two file times and returns a value that indicates which time is later or returns 0 (zero) if the times are equal.

If you plan to modify file times for specified files, you can convert a date and time of day to a file time by using the SystemTimeToFileTime function. You can also obtain the system time in a FILETIME structure by calling the GetSystemTimeAsFileTime function.

To make a file time easy to display to a user, use the FileTimeToSystemTime function. FileTimeToSystemTime converts the file time and copies the month, day, year, and time of day from the file time to a SYSTEMTIME structure.

File Times and Daylight Saving Time

You must take care when using file times if the user has set the system to automatically adjust for daylight saving time.

To convert a file time to local time, use the FileTimeToLocalFileTime function. However, FileTimeToLocalFileTime uses the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, it takes daylight saving time into account, even if the file time you are converting is in standard time.

The FAT file system records times on disk in local time. GetFileTime retrieves cached UTC times from the FAT file system. When it becomes daylight saving time, the time retrieved by GetFileTime is off an hour, because the cache is not updated. When you restart the computer, the cached time that GetFileTime retrieves is correct. FindFirstFile retrieves the local time from the FAT file system and converts it to UTC by using the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, FindFirstFile takes daylight saving time into account, even if the file time you are converting is in standard time.

The NTFS file system records times on disk in UTC. To account for daylight saving time when converting a file time to a local time, use the following sequence of functions instead of using FileTimeToLocalFileTime:

File Times and CDFS

The date and time stamps of files that are located on or originate from media using Compact Disc File System (CDFS) are adjusted for the local time zone. ISO 9660 states that CDFS is to display the date information correctly for the local time zone. This is done so that dates for files on CDFS are displayed the same as those on Universal Disk Format (UDF). UDF is the newer standard for distribution media. If your code depends on the unmodified date information for a file that resides on or originates from media using CDFS, it may not function correctly.

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 )

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.

File System	M	A	C	B
Ext4	Modified	Accessed	Changed	Created
Ext2/3	Modified	Accessed	Changed	N/A
FAT	Written	Accessed	N/A	Created
NTFS	File Modified	Accessed	$MFT Modified	Created
UFS	Modified	Accessed	Changed	N/A

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 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:

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:

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:

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:

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:

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:

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.