“Mass Triage Part 4: Processing Returned Files – AppCache/Shimcache”

Our story so far…

Hermes starts reviewing malware review of wde.exe, ght.exe, and vc.exe procured through FRAC. Meanwhile Frank, starts on the Shimcache review now that the AT jobs review has been completed. Frank asks another team member Chris, to start on conducting forensics on some of the boxes that have a higher number of suspicious AT jobs and tools. Up to now they have about they have 15 boxes accessed by the actor.

Sponsorships Available

Sponsorships Available

Sponsorships Available

AppCache/Shimcache Introduction

In a nutshell, the AppCache isused by Windows to help make sure older applications will work with newer versions of Windows. Mr. Tim Newton written a MS blog post (https://blogs.technet.microsoft.com/askperf/2011/06/17/demystifying-shims-or-using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff/) explaining how the Shims work. The AppCache details are stored in the SYSTEM hive. In regards to the forensics value of the Shimcache, the details recorded in the registry can be used to help determine if malware has executed on the system, the last modified timestamp of the file executed from $Standard_Information, and file size. In essence, it goes to back viewing the registry as a log of what was ran on the system.

The table below shows some example output from Carvey’s RegRipper converted to table format for easier viewing.

For further details regarding conducting forensics on the Shimcache please see:

• https://www.fireeye.com/blog/threat-research/2015/0 /caching_out_the_val.html
• https://countuponsecurity.com/2016/05/18/digital-forensics-shimcache-artifacts/
• Harlan Carvey’s Windows Registry Forensics books

ShimCache Analysis

The first part of conducting ShimCache Analysis is pulling all of the SYSTEM hives from all of machines on the network. Make sure there is plenty of space to house the hives as these files can fairly big. Next is to process all of the SYSTEM hives with RegRipper. To do this I use a modified version of the appcompatcache plugin. The modifications I did to the plugin was print out a tag, followed by the Shimcache line, and then the machine name. All of the lines printed out are sorted by filename and path. To run regripper on a set of files, I use the following command:

Windows:

find {directory with SYSTEM hives} -print -exec rip.exe -r {} –p appcompatcache_tln ; >> appcache{datetime}.txt

*NIX:

find {directory with SYSTEM hives} -print -exec rip.pl –r {}
-p appcompatcache_tln ; >> appcache{datetime}.txt

An example line is below from the modified appcompatcache_tln plugin. The modification of the plugin adding the hostname to the output and some other minor things.

1395137092|REG|||M...|AppCompatCache|SYSVOLWindowsTemp9C23D78B-21D2-47E5-8697-783FE408CAF6DismHost.exe|MACHINE1

The goal was to be able to quickly grep out the tag, AppCompatCache, from the output for processing. Note that the “|” was used to differentiate between fields.

The third step is to extract the AppCompatCache lines from the output. Then cut out the tag, sort the lines, and then unique with counts so that frequency analysis can be conducted.

Here is a summary of the steps so far:

1) Gather up SYSTEM hives

2) Run RegRipper on all system hives. Make sure to use the modified version.

Windows: find {directory with SYSTEM hives} -print -exec rip.exe -r {} –p appcompatcache_tln ; >> appcache{datetime}.txt

*NIX: find {directory with SYSTEM hives} -print -exec rip.pl –r {} -p appcompatcache_tln ; >> appcache{datetime}.txt

3) grep AppCompatCache appcache{datetime}.txt | cut -d| -f7 | sort | uniq -c | sed ‘s/^[ t]*//g’ | sort -t” ” -k2 > appcache{datetime}_freq.txt

At this point the {filename}.txt file can be reviewed. Like with the AT jobs, the number on the left is the number of times the file path and filename have been seen. The higher the counts, the more likely it is a benign file. As to what a high count is, depends on the environment. For example, if there is 8,000 counts for “C:Windowshh.exe” in a 10,000 desktop network, then most likely hh.exe is benign.

One of the problems with reviewing the output (step 3) at this point is the file can be quite huge. It all depends on the environment and how strict the security policy is. The looser the security policy, which means users can run anything they download, equals more lines to review. One of the ways to combat this is remove known good files.

ir_distill

ir_distill is a python script that takes the output from step 3 and compares the filename and full path to known good filenames and full paths. Shimcache doesn’t contain MD5 hashes or any other hash type, so the comparison has to be done on filenames and full paths. An SQLite database is included with the script which contains the complete list of files and full paths for various MS operating systems. The database was generated using clean installs of the OS in a virtual machine. Then Sleuthkit’s fls was used to pull back the filesystem information.

The command line arguments are the following:

-f SQLITE, -filecheck SQLITE SQLite database to check against

-i FILE, -infile FILE Input file

-o OUT, -out OUT Output results to file; creates a

OUT_nomatch.txt file

-showallmatches Shows all OS matches in output

-ignorecase Ignore case when doing db lookups

I usually run the script like this:

./ir_file_distill_v0.3.py -f os.sqlite –i appcache{datetime}_freq.txt -o appcache{datetime}_distill —showallmatches —ignorecase

The “-i FILE” is used to designate the output from step 3. The script will go through this file line by line and lookup the full path and filename in the database. If there is no match, then it will write the output to the filename given in the -o option. Please note that the filename for items that do not match will have a “_nomatch.txt” added to the filename.

The “showallmatches” option is nice in that it will list all of the matches found during the comparison between the input file and the SQLite db. That way there no question later on what was and wasn’t matched. This option will create file with the filename given with the -o option and will add a “_match.txt” to the filename.

Keep in mind that all matching is case sensitive. Typically, I run the command with the “ignorecase” option. This will turn off the case sensitivity within the database. It also makes the script run much longer. The script was designed for portability vs speed. A database like MySQL would probably be faster for the comparison vs SQLite.

Once the script is finished running, the analyst should review the “_nomatch.txt” file to look for badness. Below is a sample of the output.

1|Windowsdchcfg64.exe
1|Windowsdcmdev64.exe
1|WindowsDfsrAdmin.exe
2|Windowssystem32rar.exe
3|Windowsmf.bat
3|WindowsdwrcsDWRCSh.DLL
5|Windowssystem32za86.exe

The first column is the number of occurrences seen, followed by the “|” as the column delimiter. The last column is the full file path and filename. As you go through the list, remember Google is your friend. Lookup filenames and filenames with paths to try to determine what the executable is. Any filenames that appear random, that are short, or just look funny should be reviewed. The “rar.exe”, “mf.bat”, and “ga86.exe” were examples of APT malware. While the “rar.exe” file was not malware, it was sitting in the “C:Windowssystem32” directory. That is not normal.

Like the AT jobs, I put a “#km” after the line to mark it. Be sure to save the file often after marking something. Just in case the text viewer being used crashes or something else happens. Once I have reviewed the file I pull out all of the lines that have a “#km” in it using grep. Then it is a matter of using grep to pull the relevant lines from the output in step 2 (find command above) for the machine name. The machine name will be the last field in the line. FRAC or RIFT can then be used to pull the files for analysis to determine if the files are bad or not.

For example, to pull the interesting lines out and find the source machines:

1. grep “#km” appcache{datetime}_distill_nomatch.txt | cut -f2- -d| | cut -f1 -d# | sed ‘s/[[:blank:]]*$//’ | sed ‘s//\/g’ | sed ‘s/”//g’ > appcache{datetime}_findings
2. grep -i -f appcache{datetime}_freq_nomatch.lines appcache{datetime}.txt > appcache{datetime}_pullfiles.txt

In matters of time it takes to conduct the review all depends on how many lines that have to be reviewed and your experience with your environment. There have been times where I have reviewed 5000 Shimcaches in about an hour. Other environments have taken a day or two to conduct analysis. Remember that since there are no hashes associated with the analysis, thus potential badness could be missed. Working with the tool and adding your own whitelisting to the SQLite database is key to reducing the time it takes to review the Shimcaches and being able to spot badness.

All of the tools in this post can be downloaded at:

https://github.com/chaoticmachinery/mass_triage_tools

Next in Part 5

In Part 5, I will discuss reviewing amcache found in Windows 7 and above.