Not long ago, I posted about When Windows Lies, and that post really wasn’t so much about Windows “lying”, per se, as it was about challenging analyst assumptions about artifacts, and recognizing misconceptions. Along the same lines, I’ve also posted about the (Mis)Use of Artifact Categories, in an attempt to address the reductionist approach that leads analysts to oversimplify and subsequently misinterpret artifacts based on their perceived category (i.e., program execution, persistence, lateral movement, etc.). This misinterpretation of artifacts can lead to incorrect findings, and subsequently, incorrect recommendations for improvements to address identified issues.
I recently ran across this LinkedIn post that begins by describing AmCache entries as “evidence of execution”, which is somewhat counter to the seminal research conducted by Blanche Lagney regarding the AmCache.hve file, particularly with more recent versions of Windows 10. If you prefer a more auditory approach, there’s also a Forensic Lunch where Blanche discussed her research (starts around 12:45), thanks to David and Matt! Suffice to say, data from the AmCache.hve file should not simply be considered as “evidence of execution”, as it’s far too reductionist; the artifact is much more nuanced that simply “evidence of execution”. This overly simplistic approach is indicative of the misuse of artifact categories I mentioned earlier.
Unfortunately, misconceptions as to the nature and value of artifacts such as this (and others, most notably, ShimCache) continue to exist because we continue to treat the artifacts in isolation, rather than as part of a system. Reviewing Blanche’s paper in detail, for example, makes it clear that the value of specific portions of the AmCache data depend upon such factors as which keys/values are in question, as well as which version of Windows is being discussed
[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.
Read the original article: