I worked a case where I checked the Windows Install date and it was a couple days before we received the system. GREAT....did the user reformat their drive and do a fresh install before handing over the laptop? Did they reinstall the OS? This would not have been the first time a laptop or system was rebuilt after an incident (either on purpose or by accident).
Checking basic information like the Operating System and Installation date can help a examiner prioritize the systems they need to examine and check for evidence spoliation issues. If you have 20 systems to go through, and the Operating System has been installed AFTER the date of the incident you may want to focus on some other systems first. In civil or criminal cases, an installation date right before you receive the evidence may raise some red flags.
So now that we have established why the Operating Installation date can be important, there is a registry key you can retrieve it from, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. RegRipper has a great plugin for this, named OSVersion that pulls not only the OS version, but the install date from the registry key . Running this against my test system I got the following output:
----------------------------------------
winver v.20081210
(Software) Get Windows version
ProductName = Windows 10 Home
InstallDate = Fri Feb 3 15:58:47 2017
----------------------------------------
What??? Install date of February 3rd, 2017?? 2 weeks ago??? Since this is my system, I know I did not install Windows 10 February 3rd. I have had Windows 10 Home since the roll out in 2015!
Just to be a thorough, I verified the date was being parsed correctly and looked at the raw data in the registry:
Install date is 0x5894a8b7 which is Fri, 03 February 2017 15:58:47 UTC.
Ok, one last check... running the systeminfo command it clearly shows "Original Install Date" as 2/3/2017 8:58:47 AM. I am UTC -7, so this information matches my above results.
OK - Windows, I think you are lying to me. I'm hurt. But, to add insult to injury, with some more digging around I find out that YOU MESSED WITH MY LOGS during this supposed install.
I have a snapshot of my system previous to the supposed install date of February 3rd, 2017. Note the created dates on the Event Logs - 12/12/2015 and a size of 20MB:
Now I look at the current created dates and files sizes of my event logs. Note that the created date is the same of this supposed install date, 2/3/2017. Not only that, but my log files are much smaller, some about 2MB:
When I opened my logs, as expected, there are no entries before 2/3/2017, and the first entry matches with this supposed install date:
I was curious what may have caused this. Since Windows updates have caused issues with artifact timestamps before, such as USB devices, I checked the Windows Update history. Sure enough, there was a Windows update, "Feature update to Windows 10, version 1607" which ran on 2/3/2017.This date matches the supposed install date:
Since my update history contained more than one update ran on 2/3/17, I wanted to check some other Windows 10 systems to see what I could find out. I knew approximately when both of these systems had their operating systems installed, and both had incorrect installation dates listed, as well as the Feature Update v. 1607 that ran on the same day.
System 1 (Windows 10 Home)
Registry Install Date: 9/27/2016 11:22:39
Event Log created Dates: 9/27/2016 11:11
Feature update to Windows 10, version 1607: 9/27/2016
System 2 (Window 10 Pro)
Registry Install Date: 10/1/2016 3:47
Log created Dates: 10/1/2016 3:42
Feature update to Windows 10, version 1607: 10/1/2016
So, my working hypothesis is that the Feature update to Windows 10, version 1607 is updating the Windows Installation time and deleting the logs.
This may just be a matter of semantics.. maybe "Operating Install Date" really means - latest major version update??? This artifact may be open to misinterpretation if that is the case.
Why is this important?
Possible Incorrect conclusion of evidence spoliation
Imagine you are working a civil case where the opposing side is supposed to produce and turn over a laptop. If you see the installation date was recent, you might incorrectly conclude that they installed the OS right before handing over the system. Or, in Incident Response you may incorrectly assume that the operating system was just installed and there may not be too many goodies to find.
You loose event logs
Event logs can make up a critical component of an exam. In the case I was working, this update happened right before I received the laptop. The event logs only had about a day in them. Yes, there may be backups, or a SIEM collecting them, but it just makes the exam more involved.
Other Artifacts????
These are just the two inconsistencies I have found so far... there are probably more...
I would like to test this more formally by setting up a virtual machine and tracking the updates to see what happens, however, based upon the systems I have looked at, I think Windows is lying.
As always, correlating findings against multiple artifacts could help determine if this install date is accurate.
Just a note and something else to be aware of - in many corporate environments the Operating System install date may be incorrect due to clones/images being used to push out machines. However, I don't consider this as Windows lying because the date would reflect the install date of the original before it was cloned.
Fascinating stuff, Mari! Great find, and thanks for sharing!
ReplyDeleteDo you think you would have found this if you had created a timeline and added the 'new' InstallDate to it? Do you think you would have seen the updates in the file system and Registry metadata?
Any thoughts on getting Windows Event Logs from, say, a VSC?
Thanks!
I did create a timeline for the case in question, and one thing that tipped me off was the amount of entries located just prior with references to "C:/Windows/SoftwareDistrubutions/Download. However, it would not be uncommon for Windows to download something while it was installing I suppose. Another tipoff was the amount of entries in the timelime prior to the supposed install date. VSC for event logs is a great idea. Interestingly enough, Windows was nice enough to drop a copy of the old event logs in a Windows.old directory. However, I'm not sure how long the Windows.old directory sticks around, as it wasnt on all the systems I looked at. Throwing the registry entries for installed programs (uninstall_tln.pl) into the timeline may also help point out the inconsistencies that would show a installed programs before a OS install date. I think a macro timeline of the software registry would be very helpful in detecting this.
ReplyDeleteI have found this update/install artifact as well. In one system it started out as an XP box -> Win7 and finally Win10 Home Edition. I also used (always do) RegRipper and then Timeline analysis and saw major Windows Updates changing the installation date. Timeline analysis helped to point me in the right direction.
ReplyDeleteSo, some more thoughts on your post, specific to the value of historical data on systems...
ReplyDelete1. For Windows 10 systems, the LastWrite time for the "Windows NT\CurrentVersion" key is now something that is of interest.
2. VSCs and RegBack copies of the Software hive will perhaps now have more relevance.
3. Using EVTXtract will likely help recover *.evtx data, if the VSCs don't hold what you're looking for...
Again, thanks for sharing and continuing to lead within the community, by your example.
Hi Mari! I believe we may have been in class together at some point at Champlain. Regardless, thanks for the heads up with this!
ReplyDeleteJust to state for the record, when any "feature" release is installed, it will indeed wipe out and start over the log files. All event logs to before the feature release are wiped and placed in the windows.old folder on the system. Not exactly the most forensically nice way to do it. Also be aware that the Windowsupdate.log file is historically and horrifically now unreliable as they don't publish the symbol files. The Get-windowsupdate powershell command may post out unusable output.
ReplyDeleteI am assuming from the "Windows.old" reference that these are updates to Windows 10 and not a clean install of the full OS ?? I checked my installs which were Windows 10 Pro 64-bit and Windows Home 64-bit and the install dates were correct Dec. 2016 and April 2017. But since the install disks were newer I speculate that the update that tripped your dates and times was already on the OS I installed. Although the Pro was prior to Feb 2017. At least the new Redstone 3 "Creators Update" that installed just earlier this week did not muck up the install dates and times. J. Jones
ReplyDeleteSo the Windows 10 OS has yet another registry subkey, this one in the SYSTEM hive file: "\Setup\Source OS." The InstallDate information here is the original computer OS install date/time. It also tells you when the update started, ie; "\Setup\Source OS (Updated on xxxxxx)." This may of course not be when the update ends, the user may choose to turn off instead of rebooting when prompted, etc. The update can actually complete on a different day, and "\Setup\Source OS (Updated on xxxxxx)" will reflect the date/time it started the update.
ReplyDeleteYou can also find instances of multiple "\Setup\Source OS (Updated on xxxxxx)" subkeys, each one reflecting an update.
Great catch, appreciate the post.
ReplyDeletewe had the same situation and it also coincides with the windows 10 security/feature update dates. thanks for sharing.
ReplyDelete