In Part 1 of this series, we looked at collecting volatile data from a machine and analyzing running processes and network connections. Those things are great for analyzing a running system, but what if we are looking at a machine that has been powered down and all we have is a disk image?
Thankfully, we can still piece together what was running on a machine and in some cases, even identify which processes had network activity using the Amcache, AppCompatCache (Shimcache) and the Srum DB.
First up, we will look at the Windows Shimcache. The DFIR community has already done lots of research on the Shimcache and its a fairly well documented item for forensics. The Shimcache is part of the System registry hive and can be found in the HKLM\System\CurrentControlSet\Control\Session Manager\AppCompatCache key
One important thing to note is that these entries are only updated when a system is shutdown. So, if you are looking at a disk image that was collected from a running system, you will not have the most recent entries. You can get around this by collecting a memory capture and utilizing the AppCompatCache volatility plugin. This will show you the entries from a running sytem
One of the things that I think gets overlooked, is how useful it can be when doing an IR and finding answers fast. For example, the Shimcache will contain entries for the last 1,024 items (Windows 8 and above) ran on a machine as well as including the full file path and the time that the binary was modified. This evidence can be crucial when trying to identify if suspect processes were running on a system.
To examine the Shimcache I will be using a free tool from Eric Zimmerman called AppCompatCacheParser. For parsing the data, you will need the SYSTEM hive as well as the SYSTEM.log files. Then its just a matter of running the tool with the switches you want. In our example I am using the -f and pointing to the SYSTEM hive and outputting the results as a csv file.
Opening the file in Excel shows us the execution of the Confidential-Corp_Financials_2019.xlsx.exe as well as a rubyw.exe process running from the users AppData\Local\Temp directory
Next we will take a look at the Amcache hive file. Much like the Shimcache, there has been lots of research on the Amcache hive file. This file is located in the %systemroot%\Appcopmat\Programs directory. The Amcache file will show us the full file name and path, time of execution along with the sha1 value of the most recently executed files on a system.
These artifacts can also be crucial for determining if a system is compromised. For example, an investigator could take all of the Sha1 values and perform a bulk lookup in Virustotal and detect any known malicious binaries already present on a system. In about 5 minutes of work you could already have found evil and made your client happy.
To parse the Amcache file, we will use another free tool from Eric Zimmerman called AmcacheParser
When examining the output with Excel we can see the Confidential-Corp_Financials_2019.xlsx.exe file being ran. Its also interesting to note that the Amcache does not show us the rubyw.exe processes that the Shimcache did.
The last artifact I want to look at is the System Resource Usage Monitor (SRUM) Database. The Srum DB was introduced in Windows 8 and is located in the %systemroot%\System32\sru\SRUDB.dat directory.
To parse this database I will be using the Srum Dump tool from Mark Baggett https://github.com/MarkBaggett/srum-dump
When you run the Srum dump tool you have the option to also include the Software registry hive, it is good practice to do this as you will gather additional information from this hive that can be combined with the srum.db file
Examining the output in the Application Resource Usage tab, we have several items that immediately stand out. We see the Confidential-Corp_Financials_2019.xlsx.exe running along with Rubyw, Cscript and a randomly named exe being launched.
These artifacts should be immediate red flags and are great indicators that our system is compromised.