Another fantastic Windows intrusion analysis artifact! Shimcache! Although this artifact is heavily used in intrusion analysis cases, it is also one of the most misunderstood. Lets break this down and talk all things Shimcache!
The Rundown
Used to perform compatibility checks on various applications present on the system
If there is a compatibility issue, shimcache will attempt to "shim" the application, which will modify the file's properties in an effort to run it on the current system
Also known as "AppCompatCache"
Great artifact to determine if a file had presence on a system
Can be useful to compare timestamps for evidence of time stomping
Located in the 'SYSTEM' registry hive
Can no longer be confidently used for program execution on Windows 10+
May have an "executed" flag to help determine if the application was executed
On Windows 10+, files may be "shimmed" automatically just by viewing the file within a GUI application, such as Windows File Explorer
Timestamps are the "last modified" timestamp of the file, not when it was executed
AppCompatCache/Shimcache key is only written to the registry upon system shutdown/reboot
Will need to be extracted and analyzed with a forensics tool
Okay, now that we got the TL;DR information out of the way, lets dig a bit deeper into the mysterious Shimcache. As mentioned above, this artifact is heavily misunderstood or at the very least, misinterpreted. Why is this? Well, on newer systems, starting with Windows 10, the process of "shimming" is automatically done by the OS now. Sounds convenient right?! Absolutely! However, from a forensics perspective, this can no long be used to prove program execution. Essentially, there isn't a way to prove that the application in question was executed (unless this strictly has the "executed" flag value as "YES"). Its been proven that Windows 10+ will now attempt to automatically "shim" an application just by viewing it within a GUI application, such as Windows File Explorer. Due to this, we should only use Shimcache as a way to prove that a file existed on the system in question in some way. This is still a fantastic artifact if the Threat Actor (TA) attempted to delete files on the system.
Depending on the Operating System (OS), this artifact can be located in one of two locations:
Server 2003/2008/2012/2016+ and Windows 7-10+
SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatCache\AppCompatCache
512 entries on Server 2003
1024 entries on the others
Windows XP
SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatibility\AppCompatCache
96 entries
So now we know a little bit about it and know where Shimcache is located! We can just open "Registry Editor" and view it right? Nope! You'll need a forensics tool to properly analyze this key and its data. Don't believe me? Well, lets take a look at this directly in the default Registry Editor built into Windows. We'll discuss how to analyze this further along in this post.
I also mentioned above that another misunderstanding with Shimcache are the timestamps associated with it. These timestamps are actually the "last modified" timestamps of the file, not the time of execution. With that said, be extremely cautious when including Shimcache in your report or your timeline. If you see that the "Shimcache" timestamp is from 2015, it may not necessarily mean that the TA had access since then! Shown below, we can see that the timestamps are a bit all over the place. Again, these are the last modified timestamps.
Okay, so we discussed the misinterpretation with proving execution as well as the timestamps; not to add to the list of potential "cons" of Shimcache (I promise its a great artifact and I check it with 100% of my cases), but lets discuss when Shimcache is written to the 'SYSTEM' registry hive. Unfortunately, the AppCompatCache/Shimcache key is only written to the registry upon system shutdown/reboot. Otherwise, these values only exist in memory as a "buffer" until committed to the registry once the system is powered off. What does this mean from a forensics view? Well, unless the TA or the owner of the system powered it down or restarted it, the Shimcache key may not contain the most up to date information. However, we can definitely extract this from a memory dump using a tool such as Volatility!
Shown below are two comparisons of my system. The first being before a reboot and the second after a reboot. We can see that after the system restart, the Shimcache key was updated with new information.
Anyone who has read my other posts, knows that I'm a huge fan of showing how to do something that I talk about. So lets analyze some Shimcache! In this example, I'll be using "AppCompatParser.exe", which is a tool written by the almighty Eric Zimmerman.
Once downloaded, the tool is fairly easy to use, as there are typically only a few arguments you'll have to provide. If we're doing this on a live system, navigate to the AppCompatParser executable within PowerShell, CMD or your favorite shell and execute the following command:
.\AppCompatParser.exe --csv OutputDirectoryHere --csvf OutputNameHere.csvJust be sure to replace the "OutputDirectoryHere" and "OutputNameHere.csv" with where you want to place the output file and the file name. Shown below is my example of running this. Please note the "1024" entries found, as stated earlier in this post.
If you want to run this against a target registry hive, we can use the following command:
.\AppCompatCacheParser.exe -f PATH_TO_REGISTRY --csv OutputDirectoryHere --csvf OutputNameHere.csvAgain, be sure to replace the values with the full path of where the target "SYSTEM" hive is, your specified output location and the name for the output file. Once that's complete, you'll have a nice CSV file containing the Shimcache artifacts found! Note that when viewing this output, Shimcache uses an "EntryPosition" value. This will determine in order which executables were observed first.
Although there has been controversy surrounding this artifact, it is fairly straightforward to understand and as you can see, it can be invaluable during a forensics analysis. Just be sure you're interpreting the artifact correctly and this will artifact will prove to be one that should be collected each time analysis is performed on a system.