Shim Shady: Live Investigations of the Application Compatibility Cache
Forensic analysis of the Windows Application Compatibility Cache currently suffers from a significant limitation: the data in the cache is only serialized to the registry when the system is shutdown or restarted. Why is this so significant?
It is significant because to parse the Application Compatibility Cache the tools available today all rely on the serialized cache found in the Windows registry, meaning the data is only as recent as the last system reboot. This includes Mandiant’s own Shim Cache Parser, and memory analysis frameworks like Volatility that rely on the copies of the Windows registry found in memory.
The current toolset leaves investigators with two choices: restart the system to force a flush of the cache – possibly destroying other forensic evidence – or limit the analysis to the data available at the time of the last system reboot. On servers that are not restarted regularly, crucial forensic evidence could be missed. The solution to this problem is to parse the Application Compatibility Cache directly from kernel memory.
This blog entry will detail the in-memory structures of the Application Compatibility Cache that allow for real-time retrieval of the last recently used (LRU) applications that have been executed. It will also introduce a Volatility plugin (ShimCacheMem) that implements the real-time Application Compatibility Cache retrieval based on the in-memory structures. The usefulness of the plugin will be shown with a real-world example of malware that drops and executes additional malware.
A review of the Application Compatibility Cache
As the Windows operating system evolves from version to version, changes to the implementation of some functions may affect the proper execution of legacy applications. To mitigate this, Microsoft introduced the Shim Infrastructure to specify targeted fixes, commonly referred to as “shims,” for a particular version of an application.
The Application Compatibility Cache, or Shim Cache, is a component
of the Application Compatibility Infrastructure used by the Windows
Operating System to quickly identify the applications that require
shimming due to compatibility issues. The information stored in the
cache is Operating System dependent and contains the file metadata for
all the applications that require shimming.
The Application Compatibility Cache is stored in the kernel and is serialized to the registry at shutdown. In Windows 10, the serialization happens at restart as well.
In this example, a piece of malware, the launcher, makes an HTTP request to a website to retrieve the URL of the CnC server from which the launcher downloads an executable file to disk and executes it.
Figure 1 shows the launcher in the Temp folder before being executed:
Figure 1: Launcher
Figure 2 shows the launcher making an HTTP request to a website to
get the CnC server URL:
Figure 3 shows the content of the %Temp% folder after the executable file has been downloaded successfully; notice the randomly generated name of the downloaded file, 0CD8:
Figure 3: Downloaded executable
The downloaded executable file starts by deleting the launcher from disk before performing its functionality.
Figure 4 shows that the launcher has been deleted:
Figure 4: Launcher deleted
Without a file monitoring application in place, the detail of this activity could be missed during a forensic investigation of the system.
As stated earlier, the investigator could reboot the system and analyze the serialized Application Compatibility Cache in the registry using the Shim Cache Parser tool. A better solution is to parse the Application Compatibility Cache directly from kernel memory by acquiring a memory dump and using the ShimCacheMem Volatility plugin.
Figure 5 provides the output of the ShimCacheMem Volatility plugin prior to the execution of the IntelRC.exe malware; notice that the malware has not executed yet.
Figure 5: ShimCacheMem Volatility plugin output prior to malware execution
Figure 6 provides the output of the ShimCacheMem Volatility plugin after the execution of the IntelRC.exe malware. The order in the list provides the actual execution order, with entry 1 being the most recently executed application. Observe entry 4, IntelRC.exe, and its downloaded malware in entry 1, 0DE9.exe. The ShimCacheMem Volatility plugin successfully identified the malware that executed on the compromised system, despite the fact that some files had been deleted from disk.
Figure 6: ShimCacheMem Volatility plugin output after malware execution
To continue reading and learn
about the technical details, please click here.