During my short career in digital forensics I have seen and heard a number of defences. One that I have seen emerge a number of times is the claim that one of the parties has been ‘framed’ or ‘set-up’ by someone by changing the system clock and doing some nefarious deed before setting the clock back to the correct time.
If, for example, someone did this on my computer and browsed to some inappropriate website, all the internet history records and cached files would reflect the changed time. To the casual observer, a judge, or a jury it may look like I was responsible. Even a seasoned forensic investigator may be fooled into believing that it was I that did the deed. Without digging deeper each of us could be fooled by such trickery.
Dependent on your position how would you support/dismiss such a claim? I’ve given this a bit of thought recently and come up with a few ideas.
Event Logs
These are the superb resources for many reasons but we’re going to focus specifically on the time stamps for the entries.
Event logs in Windows XP has a default size of 512KB. In both Vista and Windows 7 the default size on event logs is 20MB. In either circumstance the logs act the same way – they fill up in order of events. Once the log is full it goes back to the beginning implementing a first-in-first-out overwriting process of old records.
So, what would you expect to see if the system clock had been changed?
Depending on the software and services running on the computer the event logs could generate hundreds of entries every day. This means that we should be able to easily identify any discrepancies in the logs. As the logs are written in order of occurrence we should be able to tell if the system clock has been changed by parsing the event logs themselves and ordering them by file offset. If the dates suddenly jump backwards and then forwards again it is a good indication that the system clock has been changed. Conversely if you see no such activity it is a good indication that the system clock has not been changed.
If someone changed the system clock from inside Windows (in Vista and Windows 7) then the clock change is also recorded in the event log as event ID 1. Such entries will appear as follows:
The system time has changed to 01/01/2011 08:51:43 from 15/01/2011 08:51:43.
Link Files
If files were accessed or created during a suspected changing of the system clock then evidence may also be found in the link files on the computer.
Harry Parsonage has done a lot of work on link files. As part of his research he has found that link files contain a sequence value. This value is incremented when the operating system is started/restarted. This means that all link files from a single session will retain the same sequence value, when the computer is rebooted the sequence value increases.
If the computer clock has not been changed then parsing the link files and ordering them by their sequence value should also mean that the links are in date order. If, in ordering the link files by sequence value, we see that the dates do not align it is fair to say that the system clock has been changed.
More information on Harry’s research can be found here: http://computerforensics.parsonage.co.uk/downloads/TheMeaningofLIFE.pdf
EDIT: After speaking to Harry I need to make a small correction. It appears as if the sequence value is only consecutive in XP. Apparently they were changed in Vista and Windows 7.
Restore Points
Since Windows XP restore points have been used by Microsoft. They have changed somewhat since being introduced but they essentially serve the same purpose. In each version of Windows the restore points are stored in the folder “System Volume Information”.
In XP the restore points are named incrementally. Each restore point will be contained in a folder with a naming convention of “RP##” where “##” is the incremental restore point number. If a restore point was created during a clock change there will be anomalies. What an analyst would see is ordered restore points but, when looking at the “RP” folders in order of creation datesthe incremental numbers would not match up. If this is the case then it is likely that the system clock has been changed.
The same thing goes for Vista and Windows 7. Although the restore points (shadow volumes or difference files) are different the same principles would apply. If a restore point was created during a clock change the order of the shadow volumes would be changed. The file named {3808876b-c176-4e48-b7ae-04046e6cc752} is an index of shadow volumes and is kept in order of creation, meaning that the most recent shadow volume will be last in the file. Each of these is recorded with the creation time of the difference file so an analyst could simply look at the creation times of the difference files and, if any are out of order it is evidence that the system clock has been changed.
HTML
A number of web pages include date and time stamps. The most obvious of these are forums, but time stamps are also found in web-based email, blog entries, Facebook, Twitter, and so on. Each of these would provide a clear indication of clock adjustment when looking at the creation and download dates of the data.
Others
Each of these provide a very systematic method for detecting clock manipulation but there are other ways for detecting such things. For example, a prefetch file may contain information about accessing specific files that may not have existed on the computer at the changed time, or an email message header will contain information about the date and time sent, HTTP response headers also have time information taken from the web server, etc.
Summing Up
If someone claims that the system clock has been changed we can provide substantial evidence supporting or refuting such claims. It may well be the case that a computer clock has been changed but it is then up to us to provide evidence to support our claims and not just suggest that it may have happened.
Do you have any other methods for detecting clock changes? Please feel free to add them in the comments.
7 responses to “Detecting CMOS Clock Changes”
Thank you, this is a great article!
Id also add that the UserAssist will also pick up if the clock is changed using the GUI via the control panel applet. Good article Lee. Well worth the read and appreciate the research.
Thanks Rob.
Great article Lee! Look forward to more articles like this.
Nicely done! Love your podcast, and I share with students and staff here at Vanderbilt. Great work!
So, your trusting computer logs (say a web browser history) to blame someone for some action but then are willing to trust alternate evidence on the same computer that the clock was tampered with? Well, I would just tampler with the browser logs first if I was going to frame you and then never need to mess with the clock.
I can understand your point but think you’ve got the wrong end of the stick. I looked at all of these items (and more) in order to show that the clock had NOT been tampered with. It would be foolish to look at only one piece of evidence to draw conclusions. You would have to look at several items for corroboration or disproving of your hypotheses.
Editing the internet history and browser logs would be a clever way of manipulating evidence but that would also leave evidence that would need to be cleaned up. Think of the time stamps inside the actual pages, the time stamps of the cache files created, if you opened the file/folder in Windows you have registry entries showing the date and time you access those files for manipulation, you have the last-write times of the history logs… as you can see the list goes on.
I’m not sure if it is possible to completely hide the evidence of manipulation. Windows records so much for every single action that you’d need expert knowledge of the system, and a lot of time, to clean up your access afterwards.