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
[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.
Read the original article: