Last Nov, I published a blog post titled Program Execution: The ShimCache/AmCache Myth as a means of documenting, yet again and in one place, the meaning of the artifacts. I did this because I kept seeing the “…these artifacts illustrate program execution…” again and again, and this is simply incorrect.
I recently ran across Mat‘s post on Medium called Chronos vs Chaos: The Art (and Pain) of Building a DFIR Timeline. Developing timelines is something I’ve done for a very long time, and continue to do even today. The folks I work with know that I document my incident reviews with a liberal application of timelining. I first talked about timelining in Windows Forensic Analysis 2/e, published in 2009, and by the time Windows Forensic Analysis 3/e was published 3 yrs later, timelining had it’s own chapter.
In his post, Mat quite correctly states that one of the issues with timelining is the plethora (my word, not his) of time stamp formats. This is abundantly true…64-bit formats, 32-bit formats, string formats, etc. Mat also states, in the section regarding “gaps”, that “Analysts must infer or corroborate from context, which is tricky”; this is very true, but one of the purposes of a timeline is to provide that context, by correlating various data sources and viewing them side-by-side.
Not quite halfway into the post, Mat brings up ShimCache and AmCache, and with respect to ShimCache, refers to it as:
A registry artifact that logs executables seen by the OS. Specifically, it records the file path and the file’s last modified time at the moment the program was executed…
So, “yes” to “executables seen by the OS”, but “no” to “at the time the program was executed”.
Why do I say this? If you refer back to my previous blog post on this topic, and then refer to Mandiant’s article on on ShimCache, the following statement will stand out to you:
It is important to understand there may be entries in the Shimcache that were not actually executed. [emphasis added]
So, a program doesn’t actually have to be executed to appear in the ShimCache artifact.
With respect to the AmCache artifact, Mat states that it “does record execution times”, but that is perhaps a too general, too broad-brush approach to the artifact. When considering the AmCache artifact in isolation, please refer to Analysis of the AmCache v2. For example, pg 27 of the linked PDF, under the “AmCache” section, states:
Furthermore, for the PE that is not part of a program, this is also a proof of execution. As for the last modification date of a registry File key, it corresponds with a run of ProgramDataUpdater more often than not.
This states that for Windows 10 version 1507, the File key LastWrite time is the last execution time, but not for the identified executable file.
Finally, as an additional resource, Chris Ray over at Cyber Triage recently posted an Intro to ShimCache and AmCache, where he stated:
Due to the complex nature of these artifacts, it’s best to think of this data under evidence of existence rather than evidence of execution. In certain scenarios you can show a file executed with a high degree of confidence, but should never be the definitive proof that something ran.
Mat also states in his post, “AmCache is often used in conjunction with ShimCache…”, which may be the case, but the “conjunction” part should not end there. If you’re attempting to demonstrate program execution, for example, you should use all of the artifacts that Mat mentions in his post (MFT, Prefetch, UserAssist, ShimCache, AmCache, etc.), if available, in conjunction with others, to not only demonstrate program execution, but to also provide much greater insight and context than you’d get from just one of the artifacts.
When I was taking explosives training in the military, they had a saying for detonators: One is none, two is one. The idea is that one detonator, by itself, could fail, and has failed. But the likelihood of one of two detonators failing is extremely small. This idea can also be applied to demonstrating any particular category in digital forensics, including program execution…one artifact by itself, in isolation, is essentially “none”. It could fail to do it’s job, particularly if we’re talking about ShimCache or AmCache by themselves.
You should also consider additional artifacts to provide more granular context around the execution. If Process Tracking is enabled, the Security Event Log can be valuable, particularly if the system also has the Registry value set enabling full command lines. If Sysmon is installed, the Sysmon Event Log would prove incredibly valuable. The Application Event Log may provide indications of application failures, such as Application Pop-up or Windows Event Reporting failures. The Application Event Log may also contain DCOM/10028 messages referring to netscan or Advanced IP Scanner being executed. The Windows Defender Event Log may contain ../1116 records indicating a detection, followed by ../1119 records indicating a critical failure in attempting to quarantine the detected behavior.
So, What?
Why does any of this matter? Who cares?
When I was performing PCI forensic investigations, one of the things Visa (the de facto “PCI Council”, at the time) wanted us to include in our reports was a value called “window of compromise”. This equated to the time from when the endpoint was compromised and the credit card gathering malware was placed on it, to the point where the compromise was detected and responded to/remediated. During one investigation, I found that the endpoint had been compromised, the malware dropped and launched, and then shortly thereafter, the installed AV detected and quarantined the malware. The threat actor then returned about 6 weeks later, on about 6 Jan, and put the malware back on the endpoint; this one wasn’t detected by the AV.
Now, if I had simply said that the “window of compromise” began when the malware was first placed on the system, without qualification or context, then Visa could have assessed a fine based on the number of credit cards processed over that 6 week period. That period was over the Thanksgiving-to-Christmas time frame is historical when more purchases are made, and the assessment of processing volume would have had a significant impact on the retailer.
At the time, the malware that a lot of threat actors were using had a component that was “compiled” Perl code, and each time it was launched, the “compiled” Perl runtime was extracted into a unique folder path. Using the creation and last modification times of those folders, we could determine when and how often these components were run. As the malware had been quarantined by the AV, as expected, we found no indication of these folders during that 6 wk period.
The outcome of an investigation…your findings…can have a profound impact on someone, or on an organization. As such, having context beyond just the ShimCache or the AmCache, incorrectly put forth as “evidence of execution” solely and in isolation, is extremely important.
Source: Read MoreÂ
