Something that I’ve seen and been concerned about for some time now is the state of digital analysis, particularly when it comes to Windows systems. From open reporting to corporate blog posts and webinars, it’s been pretty clear that there are gaps and cracks in the overall knowledge base when it comes to the incidents and issues being investigated. These “gaps and cracks” range from simple terminology misuse to misinterpreting single data points on which investigation findings are hung.
Consider this blog post, dated 28 April. There is not year included, but checking archive.org on 11 Sept 2023, there are only two archived instances of the page, from 9 and 15 June 2023. As such, we can assume that the blog post was published on 28 April 2023.
The post describes ShimCache data as being “a crucial tool” for DFIR, and then goes on…twice…to describe ShimCache entries as containing “the time of execution”. This is incorrect, as the time stamps within the ShimCache entries are the file system last modification times, retrieved from the $STANDARD_INFORMATION attribute in the MFT record for the file (which is easily modified via “time stomping”). The nature of the time stamp can easily be verified by developing a timeline using just the two data sources (ShimCache, MFT).
The blog post also contains other incorrect statements, such as:
Several tools are available for analyzing shimcache, including the Microsoft Sysinternals tool, sdelete…
The description of the sdelete tool, captured from the SysInternals site on 11 Sept 2023, is illustrated in figure 1.
 This article has been indexed from Windows Incident Response
Read the original article: Post navigation |