I just started working in LE and during a computer forensics investigation my experienced colleague imaged a hard drive. I then proceeded to check the registry for the timezone. He asked me to look at the TimeZone name. I however insisted on checking the "StandardName" as this DLL could not be altered by the user.
We then established the time zone, but never checked the actual clock (by booting up the computer) he told me this is not part of the standard operational procedure.
I am a bit perplexed, shouldn't it be? Am I missing something? Sure, the NTFS keeps track of UTC time, but still?
We then established the time zone, but never checked the actual clock (by booting up the computer) he told me this is not part of the standard operational procedure.
I guess it makes sense that it is not "standard".
If you have the login credentials, once you have imaged the disk(s), then you can boot the computer, login and check the date/time of the OS.
But if you don't have the login credentials?
Are you going to decrypt/bypass/reset the current ones?
And what if - for any reason - the computer/OS doesn't boot?
Also there may be cases ? where you cannot (shouldn't) alter *anything* on the original disk/device.
jaclaz
In my experience, it is common practice to record the value of the real-time clock (RTC) on computers during forensic preservation. This does not involve booting up the OS; one can turn the computer on while the internal drives are disconnected and enter the BIOS, or boot into a forensic environment, to record the time kept by the computer vs local time at that moment.
While this might be a helpful data point, it does not prove by itself that the computer kept accurate time in the past when certain events took place. Here is a previous discussion on this topic
https://www.forensicfocus.com/Forums/viewtopic/t=14112/postdays=0/postorder=asc/start=0/
Also, here is an additional discussion that you may find helpful in establishing the accuracy of the system clock after the fact while working with a forensic image of a system
https://www.forensicfocus.com/Forums/viewtopic/t=467/postdays=0/postorder=asc/start=0/
I just started working in LE and during a computer forensics investigation my experienced colleague imaged a hard drive. I then proceeded to check the registry for the timezone. He asked me to look at the TimeZone name. I however insisted on checking the "StandardName" as this DLL could not be altered by the user.
We then established the time zone, but never checked the actual clock (by booting up the computer) he told me this is not part of the standard operational procedure.
I am a bit perplexed, shouldn't it be? Am I missing something? Sure, the NTFS keeps track of UTC time, but still?
He asked me to look at the TimeZone name.
Is that the TimeZoneKeyName?
I however insisted on checking the "StandardName" as this DLL could not be altered by the user.
If you check the permissions on the registry key (TimeZoneInformation), I think you'll find that it needs the same (or at least very similar) privileges to change as the dll file.
But that name is not really the important part – it's for display only. The important information is the remaining information in that key, as that's what directly influences any 'local time' logging. Checking TimeZoneKeyName only just assumes that the key content is assumed to be consistent. (Simple-minded changes can be identified is the security descriptor still as expected? – more complex fiddling is probably more difficult to detect.)
We then established the time zone, but never checked the actual clock (by booting up the computer) he told me this is not part of the standard operational procedure.
That sounds odd. I've looked at systems with clock set back around 120 days unless I had checked the R/T clock I would have had problems reconciling internal time stamps with external time stamps.
I am a bit perplexed, shouldn't it be? Am I missing something? Sure, the NTFS keeps track of UTC time, but still?
Is there perhaps anything else in SOP that addresses identifying time-keeping anomalies? If there is, current R/T clock settings may not be important. After all, if clock was changed only during one week, and then returned to 'real time', R/T clock would not show it, yet the effect would still be present in file timestamps, and possibly in system logs if they're kept. (Assuming NTP synching was disabled as well.)
Incidentally … NTFS does not keep UTC time, even if that is what everyone says. UTC incorporates leap seconds – but NTFS time stamping does not and can not take those into account the NTFS time stamp model does not allow for 61 seconds in some particular minute. Any connection between UTC and NTFS time stamps is through Windows time keeping, and thus through external time sources.
As long as you're not in a situation where millisecond precision (or even second precision) is important, it probably doesn't matter – but there are some situations where it is, such as financial transactions.
Note that Windows prior to WS16 / W10 does not keep time to a precision of even one second by default. See
https://
and KB939322 for some related info. (I recommend setting up a 'w32tm /stripchart' experiment on a default client and a local trusted time source over a week or two, and diagram the differences.)
In the training I have received, it is recommended to use the StandardName from the System registry hive (TZRES followed by a number). You can look up the number online. As far as the TimeZoneKeyName, that can be changed to anything the user wants it to be.
I would also recommend booting to the BIOS to get the date and time after all of the connected hard drives (if more than one) have been removed.
There are many "standards" and SOPs. Some are worse than others. mrgreen
I would suggest you use the vocabulary of "best practices", and go with multiple sources. that is, multiple location in registry, RTC, log file stamps, file system stamps, etc.
The more 'dissimilar' sources you have, the better your proof is. Best ones are that are not on that box (syslog off of proxy server, gateway, DHCPd, etc.?)