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.
I would suggest you add some different file types to your test cases. In my testing, some time stamps that appear to be updated by the OS are actually being updated by applications. For example, when I modify a txt file using Notepad, the last accessed date is not updated in Windows 10.
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.
Amen. In spades.
Unfortunately, it cuts both ways. Don't test timestamps unless you understand them, and have a reasonable idea of what affects them. Or are able to take all those precautions that are necessary when you don't.
There is no such thing as a Windows 10 timestamp, or at least none worth discussing. There is NTFS timestamps, and as far as I know we practically nothing important about them. (We don't even seem to know exactly how many bits they contain … ) There are Windows Shell timestamps, because Windows Gui overrides some NTFS timestamps to make some things 'better'. And then there are all the application timestamps – and they require indivudal study to disentangle. But established 'suites', such as Office very often do their own thing, possibly for no better reason that backwards compatibility.
So, when you test 'File modifcation', what are you testing? Looks like it might be Microsoft Word timestamps. And when you compare it with that SANS Poster Time of Rules, are you comparing the same apples with apples? Did those tests also use Word 2016? Or did they just juse Notepad, as kzrhodes seems to suggest? Or perhaps neither, perhaps they used CMD CLI. (I've never seen any description of just how those 'Time Rules' test are performed. I've concluded that they aren't repeatable, so I've never trusted in them or in any conclusions based on them without separate verification. But perhaps you know?)
And when you do test File modification, what are you really looking at? I mean, the main source of errors in a scenario with a major application would easily be if the application does backup files or not. Iif Windows 2016 saves the original file as backup, and performs the change on a copy, … are you really testing file modification? Was the MFT entry number the same before or after? Did you verify?
Without knowing how the old tests were made … how do we know that Windows changed? Perhaps it was the test methodology that changed? Or perhaps Window GUI changed … I seem to recall a 'Move to folder…' command in older Windows, but I don't seem to find it in Windows 2016. Was *that* how the old tests were performed?
The 'Local File Moving' test raises similar question just how was it performed? Was it a drag and drop? Or cut and paste? Or was it a CMD CLI 'MOVE'? Or perhaps PowerShell? Or … ? Or do we know that they have the same effect?
And when we get into serious testing, where we have to admit that we might not be able to control the testing environment completely, we have to take unknown or random processes into account. tests need to be repeated a number of time, just in case some unknown event affects the time stamp.
Were the timestamps of the original files documented? And compared with the timestamps that were presumed to be unchanged after the tests? Or the time frame in which the testing event was performed recorded, and verified to 'contain' the changes observed after the test?
Were any null tests performed? Any configuration done to reduce any effects unknown processes may have? And how did you guard against time stamp tunnelling effects?
But perhaps I overreact. I want to be able to rely on research for the conclusions I am able to draw from the signs that I collect from a system. Amateur forensics doesn't help me do that, so I usually end up criticizing it, though it might never have been intended to be anything but some more junk science good enough for a blog page. (Which is more or less where I saw those Windows 7 Time Rules the first time. A blog page.)
And no, the fault is probably not yours. SANS had the opportunity once, and they blew it. These days everyone seem to believe their Time Rules is the way to do this job.
From a purely historical point of view, the guys in "MS Office" team (which includes Word and Excel) have traditionally gone "astray" (for the good or for the bad) compared to the same guidelines/instructions by Microsoft, whilst the core OS team have traditionally been very cautious in changing anything, particularly on the filesystem, so I would also vote for the opportunity on making the same tests on other kinds of files.
And athulin is also right, there is not actual evidence (or not good enough evidence) on how the original "Sans" poster was created, and though most probably it is "mostly right" I wouldn't take it (nor your new one - no offence intended ) ) as the ultimate and absolute truth, there are to many variables and methods/ways to be sure, and with recent windows there are two "new" subsystems (powershell and Linux on Windows) that may (or may not) behave differently from what expected.