Pages

Monday, February 20, 2017

When Windows Lies

Wait, What? Windows lies? I believe so...

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:

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.

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.

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.

I 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.

Just 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.

I 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

So 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.

You can also find instances of multiple "\Setup\Source OS (Updated on xxxxxx)" subkeys, each one reflecting an update.

About Me

I am a Cyber Security professional specializing in Digital Forensics and Incident Response. I also enjoy Raspberry Pi projects and playing poker. Follow me on twitter @maridegrazia. Opinions are my own and not the views of my employer.