Can Windows Update fool you during the investigation?

Yes… it can.

Recently, I observed that major windows updates modify or just delete some forensics artifacts, which DFIR analysts use on the regular basis.

Based on my tests, Windows Update can:

– delete Windows Event Logs
– delete PREFETCH files
– modify the LastWrite Time for NTUSER.DAT hives
– clear information from setupapi.dev.log
– and maybe even more more…

To better understand what is happening on the system during the update, I took my old VM and tried to update to Windows 10, version 20H2. Based on https://en.wikipedia.org/wiki/Windows_10_version_history#Version_20H2_(October_2020_Update) version 20H2 points to the build 19042 from October 2020.

Once I started the update, I found out that a folder called $WINDOWS.~BT was created on the C:\ partition (screenshot below).

Inside that folder I could find another two folders: 

Opening DUDownload -> Setup I found one more folder called Windows.10.0-KB5007402-x64 (as the name suggest there were files related to the update KB5007402-x65, screenshot below):

Interesting thing is that it was not the only one place where the system put some files, in addition to that system also created another directory called WUDownloadCache. I am not sure what is the default location for that folder, because in my case there was not enough space on my disk, therefore I had to choose a different place (external disk) to save it. 

“The WUDownloadCache folder is used by Windows update wizard for storing temporary files of the different updates. All the files we find use the ESD extension, which is the one used by the update system.”

Link: https://hardwaresfera.com/en/articulos/que-es-wudownloadcache/

When I started installing the update (which previously was only downloaded by Win10) the content of  $WINDOWS.~BT changed (screenshot below). 

Finally when the update was completed and I rebooted the system the folder called Windows.old had appeared on my C:\ partition. 

As it is easy to observe, the Windows Update is VERY noisy and I think that we should be able to find out that reviewing forensics artifacts like for example $UsnJrnl.

But are there any other ways to find the information about all updates that took place on the machine you are investigating? Of course they are, googling that topic I found few ways to get that information from the “life” machine. Link: https://www.thewindowsclub.com/check-windows-update-history-using-powershell

1. First option is to use WMIC. The command looks like that: wmic qfe list (screenshot below).

2. Second option is to use PowerShell, it requires you to install one extra module called PSWindowsUpdate, once it is installed you can use a command Get-WUHistory to list all updates and the date of the installation. In contrast to WMIC method, here you can also get the information about the time! (screenshots below).

If the output is not fully readable, you can pipe it to “format-list” and get more readable output (screenshot below).

Of course there are much more ways to get that information from the “life” machine, but DFIR analysts very often deal with artifacts that were collected from the compromised machine, rather than with the “life” machine (obviously it depends, your organization can have some kind of EDR solution like Crowd strike or Carbon Black, which can make it easier). But for the scenario that you only work with the targeted collection, you can get information about updates and upgrades from the REGISTRY.

3. Third option is to use REGISTRY, there are two places that can help you get that information:
– SYSTEM\Setup
– SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages

I created two RegRipper plugins, that can automate the process of extraction. The first one is called updateshistory and has to be run against the SYSTEM hive. The output looks like that:

The second plugin is called packageshistory. This one in turn has to be run against a SOFTWARE hive. It will print all packages that were installed on the system which you are investigating. The screenshot below illustrates just last few entries of the plugin’s output:

Both RegRipper plugins can be found on my GitHub page: https://github.com/gajos112/RegRipperPlugins.

Now it is time to jump to the Forensics Artifacts. Once I updated my system, I did a standard forensics collection (for that purpose you can use tools like: Kape or FTK Imager).

WINDOWS EVENT LOGS

First I started reviewing Windows Event Logs. I parsed them using wevtx.bat, but there are other tools that you can use for that purpose, like for example Eric Zimmerman’s tool EvtxECmd. As I have been using that VM for some time, I was very surprised seeing logs for only one day. The oldest log was from 2022-01-11 18:45:52 (the application logs themselves should cover last week or even more, and there are other event logs that rotate even less often). If you look at the previous screenshots again, you will see that this time cover the LastWrite Time for the registry key System\Setup\Upgrade.

PREFETCH

Moving further, I checked PREFETCH files. The same situation, the oldest timestamp from parsed PREFETCH files points to 2022-01-11 18:52:33 (GMT).

SETUPAPI.DEV.LOG

Another deleted artifact is setupapi.dev.log. “In Windows Vista and later versions of Windows, SetupAPI logs information about device installation in a plain-text log file that you can use to verify the installation of a device and to troubleshoot device installation problems.” (Link: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-device-installation-log-entries).

If you are unware of that file, I recommend you to read this article.

I can see that during the time of the UPDATE and UPGRADE, that file was deleted and a new version was created.

Grabing that file from the standard location (C:\Windows\INF\setupapi.dev.log) I could find only 270 lines, and GREPing a keyword “Section start” I found four dates only:

Timestamps point to 2022-11-01 19:52 (GMT +1), which one more time is around the system update time.

In turn the same file collected from $Windows.old contains 24758 lines of logs and, and GREPing a keyword “Section start” I found 1151 unique dates.

NTUSER.DAT

Now time for the most important finding (at least in my opinion) – NTUSER.DAT. I parsed that hive, and discovered that all Last Write Timestamps have been modified and point to the time the system was updated. You can say: “okay it seems to be nothing new…” actually it is something new. We are not talking about the deletion of artifacts, but this time we have the modification, please take a look at an example below:

ShellBags entries from the NTUSER.DAT file, that I grabbed from the user’s directory:

ShellBags entries from the NTUSER.DAT file, that I grabbed from the Windows.Old directory:

I hope you see what I am talking about. The Last Write Time for all SHELLBAGS entries has been modified. We use that artifact to determine if and when an user opened a folder, based on the information above we could accuse the user that he visited the Download directory on 2022-01-11 18:48:34 (let’s say it is the day of the infection), which in combination with other artifacts could indicate that he purposely downloaded the malicious file. Which might not be true.

Another example:

EulaAccepted values from the registry (Software/Sysinternals/*) – NTUSER.DAT file, that I grabbed from the user’s directory:

EulaAccepted values from the registry (Software/Sysinternals/*) – NTUSER.DAT file, that I grabbed from the Windows.Old directory:

This time we could accuse the user that he used SDelete on 2021-01-11 18:30:53, which in fact could be used by the IT guy on 2018-03-13 05:45.

Recapping, the modification of NTUSER.DAT can lead to a significant mistake in the investigation!

I am afraid that this is just the beginning, and we have to continue our tests.