Methods to identify historical Time Zone configuration associated with a Windows PC

David Cowen at HECFBlog recently posed the following question:

On a Windows 10 system what are the different ways you could determine what timezones a user was in prior to the whatever timezone is stored in the registry?

In this post we will explore some of the ways you can determine historical timezone information associated with a device, specifically the time zone a Windows 10 system was configured with prior to it’s current configuration. 

Windows Event Logs

When looking to confirm whether or when a system event has occurred the Windows event logs tend to be a good place to start. Manual modification of the date/time will result in an event within the Windows Security log, specifically ‘Event ID 4616: The system time was changed’ events are generated:

Event ID 4616 in the Windows Security Log

This event will detail the time before and after the change as well as the account which was responsible for the change. A review of most Windows 10 systems will identify a number of these log entries associated with the NTP service. 

All very useful information… However, the question posed relates to a change in system time zone and NOT a change in system time. Unfortunately, this event is not generated when the system time zone is modified, whether automatically or by the user.

Notably however, modification of the time zone on a system will generate a log entry, specifically Event ID 1 within the System Log. There are many events which will cause this log entry to be created but we are interested in those which detail “Change Reason: System time adjusted to the new time zone”. An example is displayed below:

Event ID 1 in the Windows System Log

The keen-eyed reader will note that this event also displays an OldTime and NewTime value, however the keener-eyed reader will note that these are recorded in UTC and as the time zone change does not have any impact on the time itself they both contain the same value. Ace!

But we aren’t completely giving up on event logs just yet. A further entry, Event ID 6013 within the System log does provide us insight into the time zone configuration of a system. In normal usage this event occurs every 24 hours and records the system uptime:

Event ID 6013 in the Windows System Log

On the face of it this doesn’t look too helpful, but if we select the details tab we can see that the event data does in fact include the system time zone at the time the event is recorded.

Details tab for Event ID 6013 in the Windows System Log

On this basis, if we have event log visibility for an adequate time window and the time zone of the system remains the same for at least 24 hours then we are guaranteed to be able to answer the posed question by combining the information from Event 1 and Event 6013 within the System log. On my system the uptime value is updated at 1200hrs UTC daily, and although I have not performed further testing I would hypothesise that this is likely to be the same for other systems. Additionally, this event appears to also be populated at system startup with an initial value (commonly detailing an uptime of between 9-12 seconds), thus adding to the likelihood that you will have one available within your in-scope window. For reference, in this post the ‘in-scope window’ refers to the time between the old time zone configuration being applied and the current time zone configuration being applied, during which the time zone configured is unknown.

In the absence of useful logs, if for instance event logs have been cleared or rotated, or if we don’t have any useful Event 6013s, there are other ways in which we may be able to confirm the previous time zone configuration.

Windows Registry

The time zone information associated with a system is recorded within the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation 

While we are specifically not interested in the values in the active registry because these have been changed one notable piece of information we can derive from analysing the registry in it’s current state is the Last Write Time associated with this registry key. This key is updated if the time zone is changed and as such the Last Write time will also be updated, potentially indicating when the time zone was last changed. This can be used to corroborate findings from event logs or replace them where event logs are not available.

Volume Shadow Copy

Noting that we are interested in historical data from the registry we can look to Volume Shadow Copies to see if these can help.

If we have a volume shadow copy that was created during the in-scope timeframe then we can determine the time zone of the system at the time the shadow copy was created by extracting and analysing the registry from the VSC. We can determine what time zone the system was in and the last modified time of the key at that time to determine how long the unknown configuration was in place for.

Additionally, while we may be lacking in logs in the active system, there may be useful copies of Windows Event Logs captured within Volume Shadow Copies, these can be analysed as detailed previously.

By way of a worked example, on my personal system I was able to identify a Volume Shadow Copy which was dated 2018-07-19 00:09:14, examining the TimeZoneInformation key from within the SYSTEM hive in the VSC I identified that the TimeZoneKeyName was ‘GMT Standard Time’ which is consistent with its current state (Don't forget to account for the other Bias keys). The key was last modified on 2018-07-05 13:07:56 UTC. A review of the System log recovered from the VSC identified an Event ID 1 at 2018-07-05 13:07:56 UTC which indicates that the time had changed with “Change Reason: System time adjusted to the new time zone” and I was able to confirm that there was no similar log event for the preceding 24 hours. Analysis of the Event 6013 log entries confirmed that for a number of days prior to this event, system uptime had been recorded and that the system time zone listed in the details of each log entry was ‘600 AUS Eastern Standard Time’. 

Volume shadow copies can be a great resource when looking for historical data on a system, particularly for recovering old copies of the registry or otherwise overwritten log files. But what if there wasn’t a VSC generated at a convenient time? All hope is not lost. One other way we may get access to historical registry information could be the Hibernation File.

Hibernation File

A copy of the registry is resident in RAM while a system is online and causing a system to hibernate will result in RAM being written to disk as hiberfil.sys. If the system last hibernated during the in-scope period (while configured with the previous time zone) then analysing the hibernation file may prove fruitful.

It should be noted that Volatility has limited profile support for recent versions of Windows 10, as such it may not be possible to use the hibernation file in all instances. However, if you are dealing with a supported version of Windows 10, Hiberfil.sys can be converted to a regular image using the following command:

vol.py imagecopy -f hiberfil.sys -O hiberfil.img

Then the below command can be used to search memory resident hives for the TimeZoneInformation key: 

vol.py -f hiberfil.img --profile=[PROFILE] printkey -K "SYSTEM\CurrentControlSet\Control\TimeZoneInformation"

I have not personally used this method in anger to try to review TimeZoneInformation, but I have used it successfully to examine other keys in the past. The presence of a hibernation file at the perfect time may be slim and if none of the above have worked then we might be getting a bit desperate. One option if all else fails is to examine the system to look for any Third Party Application Logs which might be able to shed light on the situation.

Third Party Application Logs

Windows systems are commonly littered with various log files associated with Windows activity and that of third party applications. Additionally, while it is an undisputed fact that the 11th commandment is “Thou shalt record your application logs in UTC”, many applications do not conform to this standard. This may be the bane of many an investigation, but in this case such logs can be useful.

One trick to try and determine the time zone of a system at a particular point in time is to find a logfile which was created during the in-scope period. Simply searching for files with a ‘.log’ extension and a created date prior to the last time zone change is often effective. Two different log types can be of use here:

• Logs which record the time zone of the system along with timestamps (duh)
• Logs which record the time zone in local time

The latter is more common than the former unfortunately, but they can often still be useful. A couple of examples are shown below:

Kaspersky:

Extract from Kaspersky Log File

The associated log file had a created date of 2017-06-14 17:27:58 (UTC), per the filesystem metadata.

Garmin:

Extract from Garmin Log File

The associated log file had a created date of 2017-08-17 08:15:34 (UTC).

Log files will sometimes have an opening entry detailing that logging has commenced, alternatively we may have to rely upon the time of the first logged event. In both these examples we see that the filesystem recorded a file created time in UTC which was one hour behind the time as recorded in the log files first entries, this is consistent with the system having been configured to UTC+1. 

This method is of course not fool proof and as such it is best to be used in combination with other techniques. If it really is the only available evidence, then it would be recommended to test the logging behaviour of the specific application(s) which have produced suitable logs before relying upon these findings too heavily.

If logs don’t float your boat then there are alternative artefacts we can use. Forensicators love a bit of USB device analysis and in this instance the behaviour of setupapi.dev.log can be helpful.

setupapi.dev.log

The Setupapi.dev.log records timestamps in local system time. Therefore, if the user connected a USB device for the first time during the period of the unknown time zone configuration we can determine what the local system time was at that time. 

We can then analyse the registry keys associated with USB device activity as their last modified time will be recorded in UTC. The difference between these two timestamps will be the UTC offset in use at the time that the device was connected. 

In the example below, we have used USBDeview to view a listing of USB devices and selected one which was last interacted with during the in-scope period:

USBDeview displaying details of one USB Mass Storage Device

A search of the setupapi.dev.log for the device serial number identifies log entries associated with its installation.

Extract from setupapi.dev.log

Notably the UTC timestamp derived from registry artefacts states 21:28:54 while the local time recorded in the log is 22:28:56 indicating that a time zone offset of UTC+1 was in use at the time.

On the subject of USB devices… exFAT to the rescue.

exFAT Volumes

In the (granted unlikely) event that the system was used to write to an exFAT volume during the in-scope period, and if you have access to that same exFAT volume then you are in luck! Windows 10 when writing files to an exFAT volume will populate the timestamp of a file with the date/time as they appear on the system at the time and will populate the timezone offset field such that the time zone offset in use on the computer as a 7-bit signed integer, the integer itself represents 15-minute increments from UTC. Further information can be found in my recent blog post on the topic.

While the likelihood of having a useful exFAT volume interacted with during the period is pretty slim other activities are more commonplace, particularly on business issued equipment. The use of an email client to reply to email messages can give away clues as to the time zone of a system at a particular time.

Replied Email Analysis

By default, when an email message is replied to in Outlook the child message is appended onto the reply. The appended message will be displayed as well as metadata such as the ‘Sent’ time and notably the time displayed will be that as seen on the local system with any time zone adjustment applied. 

If we examine a mailstore on the in-scope system and can pair up a reply in ‘Sent Items’ to an original message as received we can compare the time listed for the original message as shown in the reply and can compare this to the UTC timestamp stored within the mailstore, thus deriving the time zone offset in use on the system at the time that the reply was sent. 

Below we see a sent item, this is a reply to another message and was sent during the time that the unknown time zone was set:

Email message reply

This message shows a sent time for the original email as being 09 July 2018 at 1647hrs. The original email message as it exists within the mailbox, viewed in Kernel OST Viewer and with the timestamps displayed as UTC is shown below:

Original Message (as replied to)

From this we can derive that the system was configured with a system time of UTC+4 at the time the reply was sent.

This behaviour is true of other email applications besides just Outlook but it is important to remember that mailbox synchronisation across multiple devices (with different time zone information) could cause confusion. Extended MAPI properties may be used to rule out messages which are not good candidates for this type of analysis and mailboxes configured with pop3 will not have this issue.

Other suggestions

While the above suggestions did get progressively more obscure and less reliable there were several other even more questionable ideas I had with varying degrees of usefulness. These included:

• Calendar analysis – If ‘Use local time zones for each event’ is enabled maybe something can be derived from calendar events created during the time period.
• Tracking cookies – I’m sure there will be some tracking cookies which might be helpful here.
• Screenshots – Screenshots if saved can potentially capture the time the system is displaying while also having metadata indicating when the screenshot was made.
• Read the user’s emails – Maybe they sent an email saying what time zone they were in…

Summary

In summary, I would look to the following evidence sources in this order:

1. Windows Event Logs (System Event IDs 1 and 6013)

2. Windows Registry

3. Volume Shadow Copies (for historical copies of the registry)

4. Hibernation File (to dump historical copy of the registry)

5. setupapi.dev.log vs. registry entries

6. Third Party Application Logs

7. exFAT volumes

8. Email Reply Analysis

9. Other miscellaneous suggestions