Is Windows ShimCache a threat hunting goldmine?

Enterprise-wide threat hunting sounds like a daunting task and for inexperienced forensic analysts it certainly can be. However, there are various techniques that can be used to provide the most bang for your buck and start producing results quickly.

This article, will focus on how to leverage a computer’s Windows Application Compatibility Cache, a.k.a. ShimCache, and discuss the benefits in doing so, given the wealth of information that can be stored within such a small cabinet of the Windows OS.

What is the ShimCache?

Microsoft first introduced the ShimCache with the release of Windows 95 and to this day it remains the mechanism for ensuring backward compatibility with older binaries. This was an effort to prevent legacy applications from breaking as new versions of the operating system were released. The cache will store a record of binaries that have executed on the system, in addition to tracking executables that have not executed but may have been browsed through explorer.exe.

There are of course some limitations to contend with. On Windows XP for instance, the ShimCache can only maintain up to 96 entries (on a first in first out basis), whereas on Windows 7 and up it can maintain up to 1,024 entries, making it much more useful to threat hunters.

In order to view the contents of a computer’s ShimCache, you first need to either forensically collect the SYSTEM file located in c:\windows\system32\config, or export the registry file via an administrative command prompt:

reg export “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache” c:\windows\temp\shim.reg

Once complete, the required file will be located in the Windows Temp directory.

With the data in hand, the next step is to use a parser to extract the contents. There are many to choose from but Mandiant’s freeware tool on GitHub is a good choice for anyone that’s unsure what to pick. When the parser is run, it will produce a wealth of information on each entry such as last modified time, last update, file’s full path, file size and execution flag.

Now it’s time to start looking a bit more closely. As you traverse the list of entries, it’s important to look out for suspicious programs that have run, odd directory locations, misspelled binaries, etc. All of these will provide clues about possible compromise of the machine in question and allow you to pivot around that timeframe for any additional indicators. Often times this may require a deeper forensic dive on the device such as inspecting $MFT, event logs, and registry data. However, for now the intention of ShimCache analysis is to seek out that initial thread to start pulling on.

From one to many

This method is great when looking at a single machine, but enterprises rely on a lot more than one endpoint. So how can you take this concept and apply it enterprise-wide?

The first step is collecting all ShimCache registry keys from across the environment. There are a variety of methods for pulling this data, depending on the technology you have deployed, you can even write a custom script to do so. It may sound time consuming but it’s absolutely worth it.

Once this data is pulled back, you can use the Mandiant script to churn through all of the output and store it in CSV format, creating a repository of historical process execution across the entire enterprise.

Now, there are a couple of options when it comes to how best to analyse this data. The most straightforward is to install a Splunk forwarder on this box and ingest it into an analytics tool. However, if you don’t have Splunk, you can also leverage an ELK stack (Elastic/Logstash/Kibana).

Next, you want to build out a dashboard to visualise this information into various sections, with queries that focus on suspicious activity across your ShimCache artefacts. Below is a list of some of the key areas to focus on:

• Single character binaries
• Two Character Binaries
• Execution from Temp
• Execution from Secondary Drive
• Misspelled Binaries
• Password Dumpers
• Suspicious Binaries
• Suspicious Folder Execution
• PsExec Usage.

This is really just a handful of queries that can be leveraged for your threat hunting dashboard. Ultimately applying contextual knowledge about your own environment and removing any noise will be your end goal here as you build in additional searches across the enterprise. The PsExec usage query can be particularly helpful because it can uncover suspicious directories that the lateral movement tool is being run from. Investigating these types of findings can often lead to some very interesting results for seeking out potential intrusions.

If you are yet to engage in ShimCache analysis as part of your threat hunting programme, don’t wait any longer. An important lesson for every security professional to learn is “never let an incident go to waste.” Although it’s always unfortunate when a successful intrusion takes place, it’s also an opportunity to gain additional funds, resources and insight to assist in continuing the good fight in future.