Battle of the Shims

Edit: Turns out this was the winning article!

I’ve previously had experience with the Amcache and Shimcache hives on incident response jobs but theses were mainly on Windows 7 boxes. David Cowen’s challenge in the tweet below was a good excuse to test a few things out that Windows 10 changed.

The Challenge:

Document the order that the following shims are executed/data written in Windows 10:

Tools and Artefacts

The VM I used was a Windows 10 Creators Update 64 Bit.
These artefact locations are for Windows 10 only. 
Check out my favourite SANS poster for more forensic artefact locations.

PECmd (Prefetch Parser) by Eric Zimmerman
Registry Entry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Control\Session Manager\AppCompatCache
AppCompatCacheParser by Eric Zimmerman
AmcacheParser by Eric Zimmerman
Registry Value: HKEY_USERS\{USER SID} \Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist
UserAssistView by Nir Sofer
srum-dump by Mark Baggett

The Test

The executable I used for this test was a GUI application, AlternateStreamView.exe (another DFIR tool created by Nir Sofer), that I had not run yet on the machine.

AlternateStreamView.exe was executed at 7:24:45 PM 4/12/2018 AEDT. Most of the tools I used print the timestamps in UTC time unless specified otherwise. I converted it to local time for my analysis.


The prefetch file was created at 7:24:55 PM AEDT and PECmd listed that it was executed at 7:24:45 PM AEDT. So we have a 10 second delay for Prefetch.

PECmd.exe -f "C:\Windows\Prefetch\"
All time stamps are UTC here which I converted to AEDT

EDIT: I ended up parsing all the times for files running for the first time. Using the file creation time minus executed time, the average time for the prefetch to be created was 8.15 seconds from 73 entries on my box.

I only used entries of Run Count = 1


I had the most trouble with the Shimcache. It wasn’t populated until I restarted the machine but entry of 7:23:45 PM AEDT was the time when the file was created and not executed.


Unlike David’s findings previously in his Forensic Lunch series, I needed to run the Application Appraisal Scheduled task before the entries for AlternateStreamView.exe showed up.

The machine I was using is running the Creators Update of Windows 10. This update is renowned for changing a lot of formatting for the Amcache and unfortunately MFT information was been removed from the registry file entries. I would like to retry this test later on another version of Windows 10 to investigate further on the differences.


The tool UserAssistView.exe claimed the user assist key in the registry was modified at 7:24:45 PM.

Using Sysmon, we can see that the UserAssist registry key was updated with the ROT13 file path of the executable. This was at 7:24:47 PM according to the Sysmon log. The 2 second gap makes UserAssist one of the fastest to shim but should be verified with a larger data set.


After researching the about the SRUM database, it seems to only pushing new data in batches every hour, or on a shutdown. I ran a TESTEXE.exe at a different time to test this and the output was that the AlternateStreamView.exe and TESTEXE.exe entries entered the srudb.dat at the same time at 7:39PM AEDT. There was no indication of execution time either.

Edit: Found out after the test that before the data is pushed to srudb.dat, it is stored in the registry here - HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\Extensions but had no data in it when I looked back at the SOFTWARE hive.


The dotted lines indicate where I needed to intervene

The registry based shims seem to be the quickest in this race. SRUM and the Amcache are dependant on the next task that populates the data. I found it interesting that I could not verify David’s finding on the instant population of the Shimcache. When I get some more free time I would like to run the same process on some different scenarios:

  • Try it on a different version of Windows 10
  • Launch non-GUI exe from cmd line
  • Remotely execute the file (GUI/Non-GUI)

Thanks for the opportunity David to do this. I’m still pretty new to DFIR so if you notice any mistakes or inconsistencies please reach out, because I’m keen to learn!