Program Execution

By now, I hope you’ve had a chance to read and consider the posts I’ve written discussing the need for  validation of findings (third one here). Part of the reason for this series was a pervasive over-reliance on single artifacts as a source of findings that I and others have seen within the community over the past 2+ decades. One of the most often repeated examples of this is relying on ShimCache or AmCache artifacts as evidence of program execution.

ShimCache
ShimCache, or AppCompatCache (the name of the Registry value where the data is found) is often looked to as evidence of program execution when really what it demonstrates is that the file was on the system.

From this blog post from Mandiant:

It is important to understand there may be entries in the Shimcache that were not actually executed.

There you go. That’s from 2015. And this is why we need to incorporate artifacts such as the ShimCache into an overall constellation, rather then viewing artifacts such as these in isolation. This 13Cubed video provides a clear explanation regarding the various aspects of the ShimCache artifact as it relates to Windows 10; note that the title of the video includes “the most misunderstood artifact”.

AmCache
AmCache is another one of those artifacts that is often offered up as “evidence of program execution”, as seen in this LinkedIn post. However, the first referenced URL in that post belies the fact that this artifact is “evidence of program execution”, as well as other statements in the post (i.e., that AmCache is “populated after system shutdown”). From the blog post:

During these tests, it was found that the Amcache hive may have artifacts for executables that weren’t executed at all.

A bit more extensive treatment of the AmCache artifact can be found here. While you may look at the PDF and think, “TL;DR”, the

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.