Last access timestamp has been enabled under certain conditions on Windows 10.
Ref: DisableLastAccess and 2 (System Managed, Disabled)
I have tested which timestamps change about processes of a file on Windows 7. Now I have added test patterns and test environments including Windows 10. The results are as follows:
A value in a cell means:
- Y (Yes/Red) - Change
- N (No/Dark Blue) - No Change
- I (Inherited/Light Blue) - Inherited from another timestamp
- D (Depend/Purple) - Change under certain conditions
Each abbreviation in header means:
- (SI) - $STANDARD_INFORMARTION Attribute
- (FN) - $FILE_NAME Attribute
A concept of this table is similar to "Windows Time Rules" of SANS Poster. I swapped rows with columns in the table because most forensic tools show metadata horizontally. Additionally, in order to avoid confusion, I use expressions of timestamps in X-Ways instead of "MACtime", "MACB" and "MACE" on purpose.
In summary of results, behaviors of each timestamp are as follows:
- Created (SI) - indicates a time of creation of object on the file system. A file which is moved using cut & paste from another volume doesn't change this timestamp. The value of a decompressed file is inherited from Modified (SI) of an original file.
- Modified (SI) - indicates a time of last modification of content. This value tends to keep with processes such as moving from another volume, file copy and decompress. The value of folder changes when a file is created, updated or deleted in a folder.
- Record Changed (SI) - indicates a time of last modification of metadata. This value tends to be updated with various processes, but the value may keeps when moving from another volume using command or file copy.
- Accessed (SI) - indicates a time of last access of an object. However, behavior of this value depends on system configuration. If the configuration is disabled, last access of object doesn't change. Regardless of the configuration, the value tends to be updated with various processes. The value of a decompressed file may be inherited from Modified(SI) of an original file.
- Timestamps of (FN) - behave differently from timestamps of (SI). These values don't change or all of the values change at once. However, rename and moved in a local volume are exceptions. These processes are inherited from (SI) value then set corresponding (FN) value.
I'll explain what I have confirmed behaviors of timestamps for some patterns.
- Verification Environment
Windows 10 1809
DisableLastAccess = 2
Firefox 64.0
Google Chrome 71.0.3578.98
LibreOffice 6.1.3.2
fte 1.8.2
File Download
When I got a file using IE/Edge, Firefox, Chrome, and Invoke-WebRequest(PowerShell), the results were as follows:
All of the timestamps indicate a time of download. To be exact, there are small gaps between these timestamps. It seems that some timestamps of (FN) have different values because some browser creates a temporary file then rename.
File Modification
A way of file modification depends on the associated applications, I have verified Notepad and LibreOffice.
I ran Notepad, created and saved a new file, then typed some messages and saved. The result was as follows:
Modified(SI), Record Changed(SI), and Accessed(SI) were changed.
Next, I ran LibreOffice Writer. I created a new document file and closed. I moved to the file into another volume, opened the file with Writer, typed some messages, then saved. The result was as follows:
The moved file didn't change Created(SI) and Modified(SI). Others timestamps were changed. Modified file with LibreOffice changed Modified(SI), Record Changed(SI) and Accessed(SI). Additionally, all of the timestamps of (FN) also be changed. However, Created(FN) was inherited from Created(SI).
Unzipped File/Folder (7zip)
I uncompressed a zip file which I got from the Internet. Timestamps of the zip file and decompressed file were as follows:
Modified(SI) was inherited from the original value, and the value was set to Created(SI) and Accessed(SI). Record Changed(SI) and all of (FN) were changed.
File/Folder Rename
I rename the decompressed file. The result was as follows:
I confirmed all of the timestamps of (FN) were inherited of the original (SI) timestamps. I have already confirmed the behavior. If the timestamps of a file which have the same value at both (SI) and (FN), you can't find the timestamps of (FN) were changed. We should change intentionally each timestamp of target file when we test renaming behavior.
bitsadmin
On Windows 8, it is possible to get files over a network using bitsadmin command. Command syntax is as follows:
> bitsadmin.exe /TRANSFER JOB_NAME REMOTE_URL SAVE_LOCATION
I got a file using bitsadmin and the result was as follows:
Modified(SI) didn't change, and the value was set to other timestamps. Both Record Changed(SI) and Record Changed(FN) were changed.
File Access/File Open
If DisableLastAccess is 2, Accessed(SI) changes when we click a file on Explorer. However, it doesn't always change.
Ref: NTFS last access time and 1 hour (3) / The (in)consistency of last access timestamps
An opened file might change Record Changed(SI) if ObjectID of the file was added.
Note
I have tested some patterns, several times and environments. I have confirmed the behavior changes on Windows 7, or Windows 8 or above, using Explorer or command, decompressed with built-in function or 7-zip...so you may get another result compared to my result.