The State of Windows Digital Analysis, pt II

On the heels of my previous blog post on this topic, I read a report that, in a lot of ways, really highlighted some of the issues I mentioned in that earlier post. The recent IDC report from Binalyze is telling, as it highlights a number of issues. One of those issues is that the average time to investigate an issue is over 26 days. As the report points out, this time could be greatly reduced through the use of automation, but I want to point out that not just any automation that is purchased from an external third party vendor is going to provide the necessary solution. Something I've seen over the years is that the single best source of intelligence comes from your own incident investigations, and what we know about our infrastructure and learn from our own investigations can help guide our needs and purchases when it comes to automation.

Further, making use of open reporting and applying indicators from those reports to your own data can be extremely valuable, although sometimes it can take considerable effort to distill actionable intelligence from open reporting. This is due to the fact that many organizations that are publishing open reports regarding incidents and threat actors do not themselves have team members who are highly capable and proficient in DF analysis; this is something we see quite often, actually. 

Before I go on, I'm simply using the post that I mention as an example. This is not a post where I'm intent on bashing anyone, or highlighting any team's structure as a negative. I fully understand that not all teams will or can have a full staffing complement; to be quite honest, it may simply not be part of their business model, nor structure. The point of this post is simply to say that when mining open reporting for valuable indicators and techniques to augment our own, we need to be sure to understand that there's a difference between what we're reading and what we're assuming. We may assume that the author of one of the reports we're reading did not observe any Registry modifications, for example, where others may have. We may reach this conclusion because we make the assumption that the team in question has access to the data, as well as someone on their team to correctly interpret and fully leverage it. However, the simple truth may be that this is not the case at all. 

So, again...this post is not to bash anyone. Instead, it's an attempt to bring awareness to where readers may fill gaps in open reporting with assumptions, and to not necessarily view some content as completely authoritative.

Consider this blog post originally published on 5 May 2022, and then most recently updated on 23 Mar 2023. I know through experience that many orgs, including ones I've worked for, will publish a blog post and then perhaps not revisit it at a later date, likely because they did not encounter any data on subsequent analyses that would lead to a modification in their findings.

Within the blog post, the section titled "Initial Access" includes the statement highlighted in figure 1.

Fig. 1: Initial Access Entry

This statement appears to (incorrectly) indicate that this activity happens automatically; however, simple testing (testing is discussed later in the post) will demonstrate that the value is created when the LNK file on the USB device is double-clicked. Or, you could look to this recent Wired.com article that talks about USB-borne malware, and includes the statement highlighted in figure 2.

Fig 2: Excerpt from Wired article

The sections on "Command and Control" and "Execution" mention the use of MSIExec, but neither one mentions that the use of MSIExec results in MsiInstaller records being written to the Application Event Log, as described in this Huntress blog post.

Figure 3 illustrates a portion of the section of the blog post that addresses "Persistence".

Fig. 3: Persistence Section

As described in this Cybereason blog post, the Raspberry Robin malware persists by writing a value to the RunOnce Registry key. When the value is read and deleted, the malware rewrites the value once it is executed, allowing the malware to persist across reboots and logins. This method of persistence is also described in this Microsoft blog post. Otherwise, the malware would simply exist until the next time the user logged in. One should also note that "Persistence" is not mentioned in the MITRE ATT&CK table in the Appendix to the blog post.

Even though the blog post was originally written and then updated at least once over the course of ten months, there's a dearth of host-based artifacts, including those from MsiExec. Posts and articles published by others, between May 2022 and Mar 2023, on the same topic could have been used to extend the original analysis, and fill in some of the gaps. Further, the blog post lists a bunch of "testing" in a section of the blog post of the same name, but doesn't illustrate host-based impacts that would have been revealed as a result of the testing. 

Just to be clear, the purpose of my comments here are not to bash anyone's work or efforts, but rather to illustrate that while open reporting can be an invaluable resource for pursuing and even automating your own analysis, the value derived from the open reporting often varies depending upon the skill sets that make up the team conducting the analysis and writing the blog, article, or report. If there is not someone on the team who is familiar with the value and nuances of the Windows Registry, this will be reflected in the report. The same is true if there is not someone on the team with more than a passing familiarity of Windows host-based artifacts (MFT, Windows Event Log, Registry, etc.); there will be gaps, as host-based impacts and persistence mechanisms are misidentified or not even mentioned. We may read these reports and use them as a structure on which to model our own investigations; doing so will simply lead to similar gaps.

However, this does not diminish the overall value of pursuing additional resources, not just to identify a wider breadth of indicators but also to get different perspectives. But this should serve as a warning, bringing awareness to the fact that there will be gaps.

With respect to host-based impacts, something else I've observed is where analysts will 'see' a lot of failed login attempts in the Security Event Log, and assume a causal relationship to the successful login(s) that are finally observed. However, using tools like Events Ripper, something I've observed more than a few times is that the failed login attempts will continue well after the successful login, and the source IP address of the successful login does not appear in the list of source IP addresses for failed login attempts. As such, there are not a flurry of failed login attempts from a specific IP address, attempted to log into a specific account, and then suddenly, a successful login for the account, from that IP address. Essentially, there is no causal relationship that has been observed on those cases.