In this article, we will delve into the significance of ShimCache and explore various investigation scenarios where examining Shimmed files becomes pivotal. This analysis is crucial for tracing potential attackers within your environment, shedding light on their activities, and enhancing your ability to respond effectively to security incidents.
ShimCache, aka AppCompatCache, is a feature in Windows that allows the OS to run older applications on a newer system without the need to edit the code of old applications to be compatible with the newer versions of Windows.
To know if an application is using Shim Cache or not, check the properties of the program.
What is the value of ShimCache for forensics?
A lot of stuff, actually, like:
- First, it stores information about every executable on the system (only if it got shimmed, and we are going to talk about how and when files get shimmed).
- Even if the file got deleted or renamed, the shim record will still exist.
- Attackers can’t manipulate the Shimmed files and it’s not easy to delete them.
- Everything the attacker has used in your system or even in the network shares, USB will be shimmed.
Recognizing that entries in the Shimcache may exist even if they were not genuinely executed is crucial. According to our present comprehension of the Shimcache, three actions can trigger the recording of an entry:
- If the files are written on the local file system.
- If you are going to a network share or a USB using Explorer or anything else and there is a file sitting there, for example, if a directory contains the files “hi.txt” and “hi.exe”, these files will be shimmed.
- The first execution of a native file program
- The main reason why it’s not shimmed before that point is that the OS isn’t running when these files are initially copied into System32 and the other folders.
- In simpler terms, the previous statement is highlighting that the operating system isn’t actively processing or “shimming” files as they are initially copied into critical system folders. The ShimCache process occurs at a later point when the OS is running, and the files have settled into their designated locations.
Locations
Windows XP -> SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatibility\AppCompatCache
Server 20xx/WIN7–10 -> SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatCache\AppCompatCache
Parsing
AppCompatCacheParser.exe -f .\SYSTEM (HIVE) --csv out ShimCacheParser.py -i SYSTEM (HIVE) --bom -o out.csv Investigation Notes
- In old versions of Windows, like XP, normally you will see like 96 entries with a field called Last execution time = Last update time. In Server 2008/2012/2016 WIN7-10, we have 1024 entries and also a new feature, the Execution Flag, which indicates if this executable was executed before or not.
- If you change a file’s name or replace its content, it gets shimmed again with the new name or data. The old file name sticks around, but the OS is not smart enough to know that this is the same file; it just got renamed.
If you want to know if a file got renamed or not, just by looking at Shim cache artifacts, you can filter for the modification time of the old named file, if there is another file popped with the same time modification, it is probably the same file, but the name just changed.
- The timestamp in the Shim cache is the same as the modification time of the file (Last Modified Time = the original modification time of the file).
If the Shim Cache modified time doesn’t equal the file modified time, then maybe the attacker did time stomped attack (which is changing the time of the malware to try to hide in plain sight among legitimate processes) “Anti Forensics”
- Another thing is that the order of the output of Shim cache doesn’t depend on anything but the time when the executable got shimmed.
- Shim Cache doesn’t shim files directly but stores them in memory until the next reboot, and then after the reboot, it loads the files into the registry.
That will bring us the to the point that I stated earlier *Attackers can’t manipulate the Shimmed files and it’s not easy to delete them*. Let’s discuss it in a scenario so you understand me better.
What would an adversary do if he wants to clear the shimmed files of his malware?
→ Now that we understand that files get shimmed after a reboot, it means they are initially shimmed in memory and then after the reboot in the SYSTEM Hive.
→ If an attacker wants to erase their entry, they will need to initiate a reboot first and then not just clear the shimCache but wipe it completely using a wiping tool like sdelete for example. (although such techniques are rarely seen in real-world scenarios).
- Since entries in the Shimcache are typically sequential, proximate entries indicate which files were executed within the same timeframe. Therefore, if an entry in the Shimcache contains a reliable timestamp, the analyst may be able to infer the execution date of other files in its proximity. When investigating lateral movement as part of an intrusion, the aforementioned scenario often occurs when the remote execution utility “PsExec” executes on a system. More on this later.
To know more about the last point, I recommend you read this blog from MANDIANT.
That’s it for now.
Cya geeks
