Shimcache
Last updated
Last updated
Windows DFIR notes are no longer maintained on InfoSec-Notes. Updated versions can be found on: .
Files:
%WinDir%\System32\config\SYSTEM
Registry keys:
>= Windows Server 2003 and Windows XP 64-bit
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache
Windows XP 32-bit
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatibility\AppCompatCache
Yield information related to programs execution, for Windows operating systems before the Windows 10 / Windows Server 2016 operating systems.
The Application Compatibility Cache, also known as Shimcache, was introduced in Windows XP as part of the Application Compatibility Infrastructure (Shim Infrastructure) feature. The Shim Infrastructure is designed to identify application compatibility issues and maintain support of existing software to new versions of the Windows operating system. As stated in the Microsoft documentation, the Shim Infrastructure "implements a form of application programming interface (API) hooking" in order to redirect API calls made by an application to an alternative library containing stub functions, known as the Shim. The process of making an application compatible to a new version of Windows through Shims is referred to as "shimming".
As a part of this framework, the Application Compatibility Database references the applications that have known shimming solutions. Upon execution of an application, the Shim Engine will query this database to determine whether the applications require shimming. The Shimcache contains metadata about the files that have been subject to such lookup, for optimizing and improve the speed of eventual later lookups.
A Shimcache entry is created whenever a program is executed from a specific path. However, starting from the Windows Vista and Windows Server 2008 operating systems, entries may also be created for files in a directory that is accessed interactively. Indeed, browsing a directory using explorer.exe will generate Shimcache entries for the executables stored within the directory (if the executable was visible in the Windows Explorer windows).
Shimcache entries are only written to the registry upon shutdown of the system. The Shimcache entries generated since the last system boot are thus only stored in memory.
While the Shimcache entry is not removed upon deletion of the associated file, Shimcache entries may be overwritten and information lost as the oldest entries are replaced by new data. A maximum of 96 Shimcache entries are stored in Windows XP / Windows Server 2003 and up to 1024 entries starting can be stored starting from the Windows Vista and Windows Server 2008 operating systems.
Each Shimcache entries contain the following information, varying depending on the version of the Windows operating system in use:
The associated file full path.
On Windows 2003 and XP 64-bit and older, the file size.
The LastModifiedTime ($Standard_Information) timestamp of the file, which does not necessarily reflect the execution time. Indeed, Shimcache entries are not directly associated with an insert / executed timestamp.
The cache entry position, as a numerical value starting from 0, which represents the insertion position in the Shimcache. The lower the value, the more recently the program was shimmed.
From Windows Vista / Windows Server 2008 up to Windows 8.1 / Windows Server 2012 R2, the (undocumented) Insert Flag flag which, when set, seems to indicate that the entry was executed. This flag is no longer present starting from Windows 10 / Windows Server 2016, and thus a Shimcache entry does not necessarily reflect an execution** (as entries may also be created for files in a directory that is accessed interactively).
On Windows XP 32-bit, the file Last Update Time timestamp.
Entries stored on disk
Eric Zimmerman's AppCompatCacheParser.exe tool (KAPE's 'AppCompatCacheParser module) and the ShimCacheParser.py Python script can be used to parse Shimcache entries.
By default, both tools will parse all the ControlSet found in the SYSTEM hive.
Entries only present in memory
The Volatility2's shimcache plugin can be used to extract the Shimcache entries living in memory (generated since the last system boot).
For more information on how to capture memory and use Volatility for memory analysis, refer to the [DFIR] Memory note.
https://www.fireeye.com/content/dam/fireeye-www/services/freeware/shimcache-whitepaper.pdf https://www.fireeye.com/blog/threat-research/2015/06/caching_out_the_val.html http://www.alex-ionescu.com/?p=39 https://docs.microsoft.com/en-us/windows/win32/devnotes/application-compatibility-database https://lifars.com/wp-content/uploads/2017/03/Technical_tool_Amcache_Shimcache.pdf https://github.com/mandiant/ShimCacheParser