Home Articles Windows 10 Time Rules

Windows 10 Time Rules


Timestamps play a very important role in many digital forensic examinations, so it’s very important for any forensic examiner or analyst to clearly understand how they work. SANS Institute has an amazing Windows Forensic Analysis poster illustrating Windows Time Rules, but recently a few of our DFIR friends noticed, that those rules are not working anymore. We have decided to prove or disprove it, and check if it’s Windows 10 who doesn’t play by the rules.


If you are a digital forensic examiner, you must know, that NTFS has not 3 timestamps regular users used to see in Windows Explorer, but 8. So what are MACB times? Here we go:

  • Modified
  • Accessed
  • Changed ($MFT Modified)
  • Birth (file creation time)

But why are we talking about 8 of them and not 4? This is because of two attributes: $STANDARD_INFO and $FILE_NAME. Both contain a set of 4 timestamps – MACB. What you must know about them is that $STANDARD_INFO can be modified by user level processes, for example, Timestomp, but $FILE_NAME can be modified only by the system kernel.


We have created two 50-gigabytes NTFS volumes. Using Windows 10 we created 8 files and 1 folder on the first volume. The second volume was used only for file moving to illustrate timestamps changes. So why 8 files? It’s pretty simple, to illustrate timestamp changes because of file renaming, local file moving, volume file moving, file copying, file accessing, file modification, file creation and file deletion. The folder was created to illustrate local file moving and file copying. After all file manioulations were done, we used Autopsy 4.6.0 to examine the results.


Let’s start from demonstrating Windows Time Rules according to SANS Institute:

If you look at “File Access” part of $STANDARD_INFO, you’ll notice, that access timestamp doesn’t change on Windows 7 and 8. This may indicate, that the table isn’t updated with Windows 10.

File Renaming

We renamed “File_Rename.docx” to “File_Renamed.docx” and here is what happened to its timestamps:

The only timestamp modified is $STANDARD_INFO MFT Modified. The same we can see in the table provided by SANS Institute, so file renaming in Windows 10 has the same effect on timestamps as in the previous versions.

Local File Moving

We moved “Local_Move.docx” to “Move and Copy” folder on the same volume. Here is what happened to its timestamps:

Again, only $STANDARD_INFO MFT Modified changed. But according to the SANS table, $FILE_NAME Modified and MFT Modified should change too, but in our case both stayed the same.

Volume File Moving

We moved “Volume_Move.docx” to the second volume. Here is what happened to its timestamps:

All timestamps except for $STANDARD_INFO File Modified and MFT Modified changed. According to SANS, only $STANDARD_INFO Created and File Modified shouldn’t change. So here we also have the difference.

File Copying

We copied “Copy.docx” to “Move and Copy” folder on the same volume. Here is what happened to its timestamps:

All timestamps except for $STANDARD_INFO File Modified and MFT Modified changed. If we look at SANS table, we’ll see the difference again, as we have not only $STANDARD_INFO File Modified stayed the same, but also MFT Modified.

File Accessing

We opened “Access.docx” with Microsoft Office Word 2016 and closed it. Here is what happened with file’s timestamps:

No timestamps were changed. The same you can see in the table by SANS.

File Modification

We opened “Modification.docx” with Microsoft Office Word 2016, typed “Modified” and saved changes. Here is what happened with the timestamps:

Created times both in $STANDARD_INFO and $FILE_NAME stayed the same, other timestamps changed. But according to SANS, only $STANDARD_INFO File Modified and MFT Modified should change.

File Creation

We created “Creation.docx” using right-button menu. Here is what happened with the timestamps:

Of course, all timestamps were newly created, so let’s say, they changed, same you can see in the table by SANS.

File Deletion

We deleted “Deletion.docx”. Here is what happened with the timestamps:

No timestamps changed. The same can be seen in the table provided by SANS Institute.


Based on the experiment results, we created our own Windows 10 Time Rules poster. Here is it:

We hope you will find it helpful in your digital forensic examinations. If you have different results, please let us know!

Happy forensicating!

About the authors

Oleg Skulkin, GCFA, MCFE, ACE, is a DFIR enthusional (enthusiast + professional), Windows Forensics Cookbook and Practical Mobile Forensics co-author.

Igor Mikhaylov, MCFE, EnCE, ACE, OSFCE, is a digital forensic examiner with more than 20 years of experience and Mobile Forensics Cookbook author.

Load More Related Articles
Load More In Articles


  1. Rob Lee

    March 31, 2018 at 4:52 am

    Oleg/Igor — Great job double-checking these results. I haven’t checked them in about 17 months or so. But I would recommend you modify your test baseline to not use “Office Documents” as we state in our courses and online that MS Office doesn’t follow the time rules and is considered an exception. When you open, modify, and save an office document, a new MFT is housing the document. This shows that each time you save an office document it is actually “creating” a new file and discretely modifying the timestamps. In this case, it sets the “creation time == modification time == access time” and backdates the creation time to the original’s creation time. Test it. You will see.

    Some advice I tell testers for time:

    1. Try to use bare-metal command prompt testing if possible that limits use of GUI application that might create exceptions. Command prompt commands such as “echo”, “copy”, “rename”, “move” are useful to try in testing times.
    2. Try both cut-paste and copy from Explorer in addition to “move” and “copy” from the command prompt. Our chart is based on “explorer” copy/moves. I have found that if a file is “moved” via the command line the “created” time will not be inherited and the Access Time and Created Times will always be the same. If the file is moved via Explorer then the created time. MFT change and the modified time will be inherited from the original. The Access time is the only time that will be not == to creation time in this instance.

    From my double checking the times today I do make some recommendations for some changes to our charts.

    + $FileName times are all == creation times when a file is created (File copied, File Created, Volume File Move) the local file move doesn’t look like it updates (so we need to change that) — Looks like you also found that out with the exception of the “file modification” which is the result of “office documents.”
    + On a volume file move, the MFT Change time is also inherited. I have to test on a Win7/8 system to see if this is new, but it looks that way for now.
    + Going to switch our public poster to the template we recently updated in class — moving from “no change” and “change” to “Inherited from original” and “Time of Copy/Move/Access” etc to make it more clear as to what is “original” and what is updated.

    Really great work. But watch out for those Office Documents. They will really throw time analysis off for you.


  2. Rob Lee

    April 2, 2018 at 11:37 am

    We are updating our poster slightly to differentiate the “Volume File Move” difference you noted! Thanks! Great job again. here is a preview if you want to see it:


    We are double checking it but currently, this is our draft. Let us know if we should make any additional updates! Thanks!

    Again great job on the testing — not enough people test. We need more.