www.it-connect.fr
How to Find Windows Forensic Traces with ShimCache – Part 1
In this article, we are going to step slightly outside the usual scope of system administration and take a closer look at Windows forensics.
The goal is to understand how to identify traces of activity on a system, and especially what the first reflexes should be during a post-incident analysis. Without going into advanced analysis, we will focus on simple but effective techniques that help quickly recover actionable clues.
To begin, we will explore a well-known artifact: ShimCache (also called AppCompatCache). This element can contain valuable information about files that were present or executed on a system. We will see how to use this data to identify suspicious files and start a first forensic analysis.
Table of Contents
Introduction to Forensics
Forensics, or digital forensics, is a discipline focused on collecting, analyzing, and preserving digital evidence in order to understand activity or an incident on a system.
On Windows, this means leveraging different data sources to reconstruct a timeline of events, identify suspicious actions, and, in some cases, attribute those actions to a user or process.
In the context of a forensic analysis, it is essential to distinguish between several types of data, as each has its own characteristics, lifespan, and level of volatility. We can group them into three broad categories:
Persistent data (physical)
This refers to data stored durably on disk. It remains present even after a system reboot.
These include:
- Windows event logs
- artifacts such as ShimCache or Amcache
- system and application files
- traces left in the registry
These data form the basis of any forensic analysis, because they make it possible to go back in time and build a history of activity.
Centralized data (sequential)
These data correspond to information collected and forwarded to external systems, such as a SIEM or an EDR.
They offer several advantages:
- they can be accessed without directly interacting with the compromised machine
- they may contain events that have already been correlated or enriched
- they make it possible to retain traces even if the system has been altered or cleaned
Examples:
- logs sent to a SIEM
- EDR telemetry
- logs centralized on a log server
These data are especially useful in a remote incident detection and response approach.
Volatile data (temporary)
These are data that exist only at a given moment, usually in memory or in temporary locations.
They are critical, but very fragile, because they can disappear after a reboot or when the system is shut down.
Examples include:
- memory contents (RAM)
- running processes
- active network connections
- temporary files
These data are often the richest in information during an ongoing compromise, but they require a rapid response to capture them before they disappear.
Understanding ShimCache
To understand ShimCache, you first need to understand how Windows internally handles application compatibility.
When an application encounters a compatibility issue—for example, because of an API change between Windows versions—the system relies on a database of compatibility called Shim Database (SDB). This database contains fixes that adjust program behavior without modifying their code.
These SDB files are stored on the system, for example in:
C:\Windows\AppPatch\
These include in particular:
sysmain.sdbdrvmain.sdbmsimain.sdbpcamain.sdb
When a program is executed, Windows can intercept certain calls through compatibility layers called Shims. In practical terms, instead of calling a Windows API directly, the application goes through this intermediary mechanism, which adjusts the request or the response.
The Shim therefore acts as an interception layer between the application and the system.
This mechanism is notably driven by internal Windows functions (such as BasepCheckBadApp in kernel32.dll), which consult the SDB database to determine whether a fix should be applied. In this context, ShimCache (AppCompatCache) is used as a fast cache containing information about executables encountered by the system.
To simplify the flow:
- A program is launched
- Windows checks its compatibility through the SDB database
- API calls can be intercepted by shims
- The system analyzes the file
- An entry is added to ShimCache
- This information is then stored in the registry
This mechanism was never designed for security, only for application compatibility. However, it leaves behind exploitable traces, which makes it a very useful forensic artifact today.
ShimCache is stored in the Windows registry under the following path:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCacheAnd in the physical file of the SYSTEM hive:
C:\Windows\System32\Config\SYSTEM\Limitations of ShimCache analysis
ShimCache does have a few limitations that are important to keep in mind during a forensic analysis.
First, it has a limited size (for example, around 1024 entries depending on the Windows version). This means older entries are gradually overwritten by newer ones, which can result in loss of history.
Second, it does not contain only executed programs. ShimCache can also reference files that were simply opened, browsed, or scanned by the system. In other words, the presence of a file in this cache does not guarantee that it was actually executed. For that, it should be supplemented by sources such as Prefetch, RecentFileCache, and Amcache, which we will cover in a future article.
Analyzing the ShimCache file
We will now move on to analyzing this file.
First, if you open the registry key containing the AppCompatCache value directly, you will quickly see that the data is in binary format. As a result, this information is not usable as-is and remains difficult to read without an appropriate tool.
To make analysis easier, we will use a well-known tool in the forensic world, developed by Eric Zimmerman. His tool suite makes it easy to parse ShimCache content.
You can download the tools here:
Download the AppCimpartCacheParser tool and place it in a folder after extraction; as for me, I put it in the C:\Temp folder.
Then open an elevated Command Prompt and run the tool with the following parameters:
--csv C:\temp\ --csvf Test1.csv
First analysis
Before running the command, I simply browsed the SysInternals folder up to the Autoruns64.exe file, without launching the program. So this is only file navigation.
After rebooting the system, I run the previous command to generate the Test1.csv file.
When analyzing the file, we can see that the items we browsed do appear in ShimCache, up to the level reached during the exploration.
Second analysis
In a second test, I went a little deeper into the folder, all the way to the procexp64.exe file, again without running the program.
After another reboot, I once again run the command to generate a Test2.csv file.
This time again, the files seen during navigation appear in the output. In particular, we can see the presence of .exe files, but not necessarily other file types.
Real-world case: a deleted file
To go further, I downloaded a WannaCry malware sample. It was immediately deleted by the antivirus. Even so, a trace still appears in ShimCache. This shows a very interesting point in forensics: even if a file is deleted quickly, it may still leave an exploitable trace in the cache
Note: contrary to a common misconception, the presence of an entry in ShimCache does not mean that a shim was applied. An application can be fully compatible with Windows and still appear in the cache without any correction mechanism being used.
ShimCache therefore reflects files observed by the system, and not only applications modified by shims.
Conclusion
As you can see, ShimCache contains information and timestamps about files encountered by the system: files opened, browsed, or scanned... but not necessarily executed.
It is therefore an excellent starting point for a forensic analysis, especially to identify suspicious tools such as BloodHound, Mimikatz, or other executables. However, given the limitations mentioned above, it should be correlated with other artifacts such as Prefetch, Amcache, or event logs.
