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.

The State of Windows Digital Analysis

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.

Fig. 1: Sdelete tool description

As you can see, the sdelete tool has nothing to do with "analyzing" ShimCache.

Suffice to say, there is a great deal more that is technically incorrect in the blog post, but there are two important items to note here. First, when searching Google for "shimcache", this blog post is the fourth entry on the first page of responses. Second, the blog post is from a company that offers a number of services, including digital forensics and incident response.

I'd published this blog post the day prior (27 Apr 2023), listing references that describe ShimCache entries, as well as AmCache, and their context. One of the ShimCache references, from Mandiant, from 2015, states (emphasis added):

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

There are a number of other free resources out there that are similarly incorrect, or even more so. For example, this article was the tenth listing on the first page of results from the Google search for "shimcache". It was apparently published in 2019, and starts off by equating the ShimCache and AmCache artifacts. Further, the title of the blog post incorrectly refers to the ShimCache as providing "evidence of execution", and the browser tab title for the page is illustrated in figure 2.

Fig. 2: Browser Tab Title

Similarly, artifact misinterpretation applies to AmCache entries. For example, this blog post that discusses Raspberry Robin includes the following statement:

...it is possible to evidence the execution of msiexec with the user's Amcache.hve artifact.

Aside from the fact that there is apparently no such thing (that I'm aware of) as "the user's Amcache.hve artifact", multiple rounds of testing (here, here) have demonstrated that, similar to ShimCache, the AmCache data source can contain references to executables that were not actually executed. This clearly demonstrates the need to cease relying on single artifacts viewed in isolation to support findings, and a need to rely upon validation via multiple data sources and artifact constellations.

I will say this, though...the blog post correctly identifies the malware infection chain, but leaves out one piece of clarifying, validating information. That is, when the msiexec command line is launched, a great place to look is the Application Event Log, specifically for MsiInstaller records, such as mentioned briefly in this Huntress blog post regarding the same malware.

These are just a couple of examples, but remember, these examples were all found on the first page of responses when Googling for "shimcache". So, if someone's attended training, and wants to "level up" and expand their knowledge, they're likely going to start searching for resources, and a good number of the resources available are sharing incorrect information. 

And the issue isn't just with these artifacts, either. Anytime we look to single artifacts or indicators in isolation from other artifacts or data sources, we're missing important context and we're failing to validate our findings. For example, while ShimCache or AmCache entries are incorrectly interpreted to illustrate evidence of execution, where are the other artifacts that should also be evident? Are there impacts of the execution on the endpoint, in the file system, Registry, or Windows Event Log? Or does the Windows Event Log indicate that the execution did not succeed at all, either due to an antivirus detection and remediation, or because the execution led to a crash?

So, What?
Why does any of this matter? Why does it matter what a DFIR blog or report says?

Well, for one, we know that the findings from DFIR engagements and reports are used to make decisions regarding the allocation (or not) of resources. Do we need more people, do we need to address our processes, or do we need another (or different) tool/product?

On 26 Aug 2022, the case of Travelers Insurance vs ICS was dismissed, with judgement in favor of Travelers. ICS had purchased a cyber insurance policy from Travelers, and as part of the process, included an MFA attestation signed by the CEO. Then, ICS was subject to a successful cyber attack, and when they submitted their claim, the DFIR report indicated that the initial means of access was via an RDP server that did not have MFA, counter to the attestation. As a result, Travelers sought, via the courts, to have the policy rescinded. And they succeeded. 

This case was mentioned here to illustrate that, yes, what's in a DFIR report is, in fact, used and relied upon by someone to make a decision. Someone looked at the report, compared the findings to the policy documentation, and made the decision to file in court to have the policy rescinded. For Travelers, the cost of filing was clearly less than the cost of paying on the policy claim. 

What about DFIR report contents, and what we've got to look forward to, out on the horizon? On 21 Aug 2023, JD Work shared this tweet, which states, in part:

Threat actors monetizing nonpayment negotiations by issuing their own authored breach reporting...

Okay, wow. Yes, "wow", and that does seem like the next logical step in the the development and growth of the ransomware economy. I mean, really...first, it was encrypt files and demand a ransom to be able to decrypt them. Then, it was, "oh, yeah, hey...we stole some sensitive data and we'll release it if you don't pay the ransom." During all of this "growth" (for want of a better term), we've seen reports in the media stating, "...sophisticated threat actor...", implying, "...there's nothing we could do in the face of overwhelming odds." So, it makes sense that the next step would be to threaten to release a report (with screen captures) that clearly demonstrated how access was achieved, which could have an affect on attestation documentation as part of the policy process, or impact the responding DFIR firm's findings.

But is this something that will ever actually happen? Well, there's this LinkedIn post that contains the offering illustrated in figure 3.

Fig. 3: Snatch Ransom Note Offering

"We will give you a full access gaining report of the company". Given what Travelers encountered, what impact would such a report have on the policy itself, had the DFIR report not mentioned or described the means by which the threat actor accessed the ICS environment? Or, what impact would it have on the report issued by the DFIR firm recommended by the insurance provider?

But wait, there's more! In 2007, I was part of the IBM ISS X-Force ERS team, and we became "certified" to conduct PCI forensic investigations. At the time, we were one of 7 teams on the list of certified firms. Visa, the organization that initially ran the PCI Council, provided a structure for reporting that included a "dashboard" across the top of the report. This dashboard included several items, to include the "window of compromise", or the time between the initial infection (as determined by the forensic investigation) and when incident was addressed. This value provided a means for the PCI Council to determine fines for merchants; most merchants had an idea of how many credit cards they processed on a regular basis, even adjusted for holidays. As such, the "window of compromise" could be used as an indicator of how many credit card numbers were potentially at risk as a result of the breach, and help guide the Council when assessing a fine against the merchant.

In 2015, an analyst was speaking at a conference, describing a PCI forensic investigation they'd conducted in early summer, 2013. When determining the "window of compromise", they stated that they'd relied solely on the ShimCache entry for the malware, which they'd (mis)interpreted to mean, "time of execution". What they hadn't done was parse the MFT, and see if there was an indication that the file had been "time stomped" ($STANDARD_INFORMATION attribute time stamps modified) when it was placed on the system, which was something we were seeing pretty regularly at the time. As a result, the "window of compromise" was determined (and reported) to be 4 yrs, rather than 3 weeks, all because the analyst had relied on a single artifact, in isolation, particularly one that they'd misinterpreted.

Breakin' It Down
The fundamental issues here are that (a) analysts are not thinking in terms of validating findings through the use of multiple data sources and artifact constellations, and (b) that accountability is extremely limited.

Let's start with that first one...what we see a good bit of in open reporting is analysts relying on a single artifact, in isolation and very often misinterpreted, to support their findings. From above, refer back to this blog post, which includes the statement shown in figure 4.

Fig. 4: Blog statement regarding evidence of execution

First, as I've tried to illustrate through this post, this artifact is regularly misinterpreted, as are others. Further, it is clearly an artifact viewed in isolation; when msiexec commands are run, we would expect to find MsiInstaller records in the Application Event Log, so there are corroborating artifacts within the constellation. These can be very useful in identifying the start of the installation attempt, as well as the success or failure of the installation, as was observed in this Raspberry Robin blog post from Huntress.

With respect to "accountability", what does this mean? When a DFIR consulting firm responds to an incident, who reviews the work, and in particular, the final work product? A manager? I'm not a fan of "peer" reviews because what you want is for your work to be reviewed by someone with more knowledge and experience than you, no someone who's on the same level.

Once the final product (report, briefing, whatevs) is shared with the customer, do they question it? In many cases I've seen, no, they don't. After all, they're relying on the analyst to be the "expert". I've been in the info- and cyber-security industry for 26 yrs, and in that time, I've known of one analyst who was asked by two different customers to review reports from other firms. That's it. I'm not saying that's across the hundreds of cases I've worked, but rather across the thousands of cases worked across all of the analysts, at all of those places where I've been employed.

The overall point is this...forensic analysis is not about guessing. If you're basing your findings on a single artifact, in isolation from everything else that's available, then you're guessing. Someone...whomever is receiving your findings...needs correct information on which to base their decisions, and from which they're going to allocate resources...or not, as the case may be. If the information that analysts are using to keep themselves informed and up-to-date is incorrect, or it's not correctly understood, then this all has a snowball effect, building through they collection, parsing, and analysis phases of the investigation, ultimately crashing on the customer with the analyst's report.

Addendum
I ran across this tweet from @DFS_JasonJ recently, and what Jason stated in his tweet struck a chord with me. The original tweet that Jason references states that it's "painful to watch" the cross examination...I have to agree, I didn't last 90 seconds (the video is over 4 min and 30 seconds long). Looking through more of his tweets, it's easy to see that Jason has seen other issues with folks "dabbling" in DF work; while he considers this "dangerous" in light of the impact it has (and I agree), I have to say that if the findings are going to be used for something important, then it's incumbent upon the person who's using those results to seek out someone qualified. I've seen legal cases crumble and dissolve because the part-time IT guy was "hired" to do the work.

Further, as Red Canary recently pointed out, the SEC is now requiring organizations to "show their work"; how soon before that includes specifics of investigations in response to those "material" breaches? Not just "what was the root cause?", but also, "...show your work...".

Addendum, 17 Sept:
Something I've seen throughout my time in the industry is that we share hypotheticals that eventually become realities. In this case, it became a reality pretty quickly...following publication of the ransomware attack against MGM, someone apparently from the ALPHV group shared a statement clarifying how they went about the attack. Of course, always take such things with a grain of salt, but there you have it, folks...it's already started.

On a side note, Caeser's was also attacked, apparently be the same group, and paid the ransom.

Book Review: Effective Threat Investigation for SOC Analysts

I recently had an opportunity to review the book, Effective Threat Investigation for SOC Analysts, by
Mostafa Yahia. 

Before I start off with my review of this book, I wanted to share a little bit about my background and perspective. I started my grown-up "career" in 1989 after completing college. I had a "technical" (at the time) role in the military, as a Communications Officer. After earning an MSEE degree, I left active duty and started consulting in the private sector...this is to say that I did not stay with government work. I started off by leading teams conducting vulnerability assessments, and then over 22 yrs ago, moved over to DFIR work, exclusively. Since then, I've done FTE and consulting work, I ran a SOC, and I've written 9 books of my own, all on the topic of digital forensic analysis of Windows systems. Hopefully, this will give you some idea of my "aperture".

My primary focus during my review of Mostafa's book was on parts 1, 2, and 4, as based on my experience I am more familiar with the material covered in part 2. My review covers about 7 of the 15 listed chapters, not because I didn't read them, but because I wanted to focus more on areas where I could best contribute.

That being said, this book serves as a good introduction to materials and general information for those looking to transition to being a SOC analyst, or those newly-minted SOC analysts, quite literally in their first month or so. The book addresses some of the data sources that a SOC analyst might expect to encounter, although in my experience, this may not always be the case. However, the familiarization is there, with Mostafa demonstrating examples of each data source, and how to use them, addressed in the book.

I would hesitate to use the term "effective" in the title of the book, as most of what's provided in the text is introductory material, and should be considered intended for familiarization, as it does not lay the groundwork for what I would consider "effective" investigations.

Some recommendations, specifically regarding the book:

Be consistent in terminology; refer to the Security Event Log as the "Security Event Log", rather than as "Security log file", the "security event log file", etc. 

Be clear about what settings are required for various records and fields within those records to be populated. 

Take more care in the accuracy of statements. For example, figure 6.5 is captioned "PSReadline file content", but the name of the file is "consolehost_history.txt". Figure 7.1 illustrates that Run key found within the Software hive, but the following text of the book incorrectly states that the malware value is "executed upon user login".

Some recommendations, in general:

Windows event IDs are not unique; as such, records should be referred to by their source/ID pair, rather than solely by event ID. While the Microsoft-Windows-Security-Auditing/4624 event refers to a successful login, the EventSystem/4624 event refers to something completely different. 

What's logged to the Security Event Log is heavily dependent upon the audit configuration, which is accessible via Group Policies, the Local Security Editor, or auditpol.exe. As such, many of the Security Event Log event IDs described may not be available on the systems being examined. Just this year (2023), I've examined systems where successful login events were not recorded.

Analysts should not view artifacts (in this case, Windows Event Log records, Run key values, etc.) in isolation. Instead, viewing artifacts or data sources together, based on time stamps (i.e., timelining) from the beginning of an investigation, rather than manually developing a timeline in a spreadsheet at the end of an investigation, is a much more efficient, comprehensive, and effective process.

Multiple data sources, including multiple Windows Event Logs, can provide insight into various activities, such as user logins, etc. Do not focus on a single artifact, such as an event ID, but instead look to develop artifact constellations. For example, with respect to user logins, looking to the Security Event Log can prove fruitful, as can the LocalSessionManager/Operational, User Profile Service, Shell-Core/Operational, and TaskScheduler Event Logs. Developing a timeline at the beginning of the investigation is a great process for developing, observing, and documenting those constellations.

The Next Step: Integrating Yara with RegRipper, pt II

Okay, so we've integrated Yara into the RegRipper workflow, and created "YARR"...now what? The capability is great...at least, I think so. The next step (in the vein of the series) is really leveraging it by creating rules that allow analysts to realize this capability to it's full potential. To take advantage of this, we need to consider the types of data that might be present, and leverage what may already be available and apply to the use case (data written to Registry values) at hand.

Use Available Rules
A great place to start is by using what is already available, and applying those to our use case; however, not everything will apply. For example, using a Yara rule for something that's never had any indication that it's been written to a Registry value likely won't make a great deal of sense to use, at least not at first. That doesn't mean that something about the rule won't be useful; I'm simply saying that it might make better sense to start by looking at what's being written to Registry values first, and start there.

It certainly makes sense to use what's already available as a basis for building out your rule set to run against Registry values. Some of the things I've been looking around for, to see what's already out there and available, are looking for indications of PE files within Registry values, using different techniques and not relying solely on the data beginning with "MZ"; encoded data; strings that include "http://" or "https://"; etc. From these more general cases, we can start to build a corpus of what we're seeing, and begin excluding those things that we determine to be "normal", and highlighting those things we find to be "suspicious" or "bad".

Writing Rules
Next, we can write our own rules, or modify existing ones, based on what we're seeing in our own case work. After all, this was the intention behind RegRipper in the first place, that analysts would see the value in such a tool, not just as something to run but as something to grow and evolve, to add to and develop.

For writing your own rules, there are loads and loads of resources available, one of the most recent from Hexacorn, with his thoughts on writing better Yara rules in 2023. Also be sure to check out Florian's style guide, as well as any number of repositories you can find via Google.

Speaking of Florian, did you know that Thor already has rules for Registry detection? Very cool!

What To Look For
Okay, writing RegRipper plugins and Yara rules is a bit like detection engineering. Sometimes you have to realize that you won't be able to write the perfect rule or detection, and that it's best to write several detections, starting with a "brittle" detection that, at first glance, is trivial to avoid. I get it..."...a good hacker will change what they do the next time...". Sure. But do you know how many times I've seen encoded Powershell used to run lsassy? The only thing that's changed is output file names; most of the actual command doesn't change, making it really easy to recognize. Being associated with SOCs for some time now, and working DFIR investigations as a result, there are a lot of things we see repeatedly, likely due to large campaigns, tool reuse, etc. So there is value in a brittle detection, particularly given the fact that it's really easy to write (and document), usually taking no more than a few seconds, and if we leverage automation in our processes, it's not something we have to remember to do.

So, What?
Why is adding Yara capability to RegRipper important or valuable?

The simple fact is that processes are created, executed, and measured by people. As such, they will break or fail.

In 1991, AFOSI was investigating one of their own in the death of his wife. During an interrogation, floppy disks collected from the Sgt's home were placed on the table, and he grabbed some of them and cut them up with shears. This story is usually shared to demonstrate the service's capability to recover data, even when the disk is cut up, which is exactly what was done in this case. However, over the years, few have questioned how the Sgt was able to get the shears into the interrogation room; after all, wouldn't he have been patted down at least once?

The point is that processes (frisking, checking for hidden weapons) is a process created, executed, and managed/measured by people, and as a result, things will be missed, steps skipped, things will go unchecked. So, by incorporating this capability into RegRipper, we're providing something that many may assume was already done at another point or level, but may have been missed. For example, the findexes.pl plugin looks for Registry values that start with "MZ", but what if the value is a binary data type (instead of a string), and the first two bytes are "4D 5A" instead? Yara provides a fascinating (if, in some cases, overlapping) capability that, when brought to bear against Registry value data, can be very powerful. With one rule file, you can effectively look for executables (in general), specific executables or shell code, encoded data, etc.

Yet Another Glitch In The Matrix

It's about that time again, isn't it? It's been a while since we've had a significant (or, depending upon your perspective, radical) shift in the cyber crime eco-system, so maybe we're due. 

What am I referring to? Back in 2019, we saw a shift in ransomware attacks, where threat actors began not only stealing data, but leveraging it as "double extortion". Up to that point, the "plan" had been to encrypt files, maybe post something publicly to let the world know that this organization had been impacted by your efforts, and hope to collect a ransom. The shift to "double extortion" moved things to a whole new level, and while there's some discussion as to whether this started in November 2019 with Maze, or if it actually started sooner...some have anecdotal information but cannot point to any public statement to the effect...the fact remains that the game shifted. In the ensuing four years, we've seen quite a bit of damaging information released, and maybe none was more disturbing than what was discussed in the ransomware attack against Minnesota Public Schools, in Feb, 2023. The school system refused to pay the ransom, and the stolen data was released publicly...a brief reading of what was in the dump gives you a brief look into the devastation caused by the release of this data.

Something else to consider is the impact of the insurance industry on the cyber security market, a topic that was covered extensively by Woods, et al, at Usenix. The insurance industry itself has, in recent years, started pulling back from the initial surge of issuing policies to developing more stringent requirements and attestations that impact the premium and policy coverage.

So, what?
Okay, so, what? Who cares? Well, here's the change, from @HostileSpectrum:

Threat actors monetizing nonpayment negotiations by issuing their own authored breach reporting...

Yes, and that's exactly what it sounds like. Not convinced? Check out this LinkedIn post from Dr. Siegfried Rasthofer, regarding the Snatch ransomware actors; "...contact us...you will get a full access gaining report...".

I know what you're thinking...so, what? Who cares? The org files a claim with their insurance provider, the provider recommends a DFIR firm, that DFIR firm issues their report and it'll just say that same thing, right?

Will it?

What happens if counsel tells the DFIR firm, "...no notes, no report..."? RootkitRanger gets it, sees the writing on the wall, as it were. No notes, no report, then how is the DFIR analyst held accountable for their work?

Why is this important? 

For one, there are insurance provider war exclusions, and they can have a significant impact on organizations. Merck filed their $1.4B (yes, "billion") claim following the 2017 NotPetya attack, and the judgement wasn't decided until May, 2023, almost 6 yrs later. What happens when attribution based on the DFIR firm's work and the decision made by counsel goes on way, and the threat actor's report goes another?

We also need to consider what happens when attestations submitted as part of the process of obtaining a policy turn out to be incorrect. After all, Travelers was able to rescind a policy after a successful attack against one of their policy holders. So, in addition to having to clean up and recover, ICS did not have their policy/safety net to fall back on. Let's say the threat actor says, "...we purchased access from a broker, and accessed an RDP server with no MFA...", and the org, like ICS, had attestations stating that MFA was in place?

Integrating Yara with RegRipper

A lot of writing and training within DFIR about the Registry refers to it as a database where configuration settings and information is maintained. There's really a great deal of value in that, and there is also so much more in the Registry than just "configuration information". Another aspect of the Registry, one we see when discussing "fileless" malware, is its use as a storage facility. As Prevailion stated in their DarkWatchman write-up:

Various parts of DarkWatchman, including configuration strings and the keylogger itself, are stored in the registry to avoid writing to disk.

The important part of that statement is that the Registry is and can be used for storage. Yes, you can store configuration settings, as well as information that can be used to track user activity, connected devices, connected networks, etc., but the Registry can just as easily be used to store other information, as well. As we can see from the Fileless Storage page (part of the MITRE ATT&CK framework) there are quite a few examples of malware that use the Registry for storage. In some cases, the keys and values are specific to the malware, whereas in other instances, the storage location within the hive file itself may change depending upon the variant, or even selections made through a builder. Or, as with Qakbot, the data used by the malware is stored in values beneath a randomly-named key.

As such, it makes sense leverage Yara, which is great for detecting a wide range of malware, via RegRipper. One way to find indications of malware that writes to the Registry, specifically storing its configuration information, is by creating a timeline and looking for keys being added or updated during the time of the presumed compromise. Another is to comb through the Registry, looking for indications of malware, shell code, encoded commands, etc., embedded within values, and this is where leveraging Yara can really prove to be powerful.

One example would be to look for either the string "MZ" or the bytes "4D 5A" at offset 0. If malware is stored in the Registry with those bytes stripped, then searching for other strings (PDB strings) or sequences of bytes would be an effective approach, and this is something at which Yara excels. As such, leveraging Yara to extend RegRipper makes a great deal of sense.

Maybe we can call this "YARR", in honor of International Talk Like A Pirate Day.

The Next Step: Expanding RegRipper

I thought I'd continue The Next Step series of blog posts with something a little different. This "The Next Step" blog post is about taking a tool such as RegRipper to "the next step", which is something I started doing in August, 2020. At first, I added MITRE ATT&CK mapping and Analysis Tips, to provide information as to why the plugin was written, and what an analyst should look for in the plugin output. The Analysis Tips also served as a good way of displaying reference URLs, on which the plugin may have been based. While the reference URLs are very often included in the header of the plugin itself, it's often simply much easier to have them available in the output of the plugin, so that they follow along and are available with the data and the case itself. 

So, in the spirit of the blog series, here are a couple of "the next steps" for RegRipper...

JSON
Something I've looked at doing is creating plugins that provide JSON-formatted output. This was something a friend asked for, and more importantly, was willing to discuss. When he asked about the format, my concern was that I would not be able to develop a consistent output format across all plugins, but during the discussion, he made it clear that that wasn't necessary. I was concerned about a consistent, normalized format, and he said that as long as it was JSON format, he could run his searches across the data. I figured, "okay, then", and gave it a shot. I started with the appcompatcache.pl plugin, as it meant just a little bit of code that repeated the process over and over again...an easy win. From there, I modifying the run.pl plugin, as well.

An excerpt of sample output from the appcompatcache_json.pl plugin, run against the System hive from the BSides Amman image appears as follows:

    {
       "value": "C:\Users\Joker\DCode.exe"
       "data": "2019-02-15 04:59:23"

    },

    {
       "value": "C:\Windows\SysWOW64\OneDriveSetup.exe"
       "data": "2018-04-11 23:34:02"

    },
   ]
}

So, pretty straightforward. Now, it's a process of expanding to other plugins, and having the ability with the tool itself to select those plugin output types the analyst is most interested in.

Yara
Something else I've looked at recently is adding the ability to incorporate Yara into RegRipper. While I was at Nuix, I worked with David Berry's developers to get some pretty cool extensions added to the product; one for RegRipper, and one for Yara. I then thought to myself, why not incorporate Yara into RegRipper in some manner? After all, doing things like detecting malware embedded in value data might be something folks wanted to do; I'm sure that there are a number of use cases.

Rather than integrating Yara into RegRipper, I thought, why re-invent the wheel when I can just access Yara as an external application? I could take a similar approach as to the one used by the Nuix extensions, and run Yara rules against value data. And, it wouldn't have to be all value, as some types won't hold base64-encoded data. In other instances, I may only want to look at binary data, such as searching for payloads, executables, etc. Given that there are already plugins that recursively run through a hive file looking at values and separating the actions taken based on data type, it should be pretty easy to gin up a proof of concept.

And, as it turns out, it was. I used the run.pl plugin as a basis, and instead of just displaying the data for each value, I ran some simple Yara rules against the contents. One of the rules in the rule file appears as follows:

rule Test3
{
    strings:
        $str1 = "onedrive" nocase
        $str2 = "vmware" nocase

    condition:
        $str1 or $str2
}

Again, very simple, very straightforward, and simply designed to produce some output, nothing more.

The output from the plugin appears as follows:

Run_yara.pl output

Now, I'll admit up front...this is just a proof of concept. However, it illustrates the viability of this technique. Now, using something like the sizes.pl plugin, I can remove the code that determines the number of values beneath a key, and focus on just scanning the value data...all of it. Or, I can have other plugins, such as clsid.pl, comb through a specific key path, looking for payloads, base64-encoded data, etc. Why re-write the code when there are Yara rules available that do such a great job, and the rules themselves may already be part of the analyst's kit.

Techniques like this are pretty powerful, particularly when faced with threat actor TTPs, such as those described by Prevalion in their DarkWatchman write-up: 

Various parts of DarkWatchman, including configuration strings and the keylogger itself, are stored in the registry to avoid writing to disk.

So, with things like configuration strings and an entire keylogger written to the Registry, there are surely various ways to go about detecting the presence of these items, including key LastWrite times, the size of value data, and now, the use of Yara to examine data contents.

As with the JSON output plugins, now it's simply a matter of building out the capability, in a reasonable fashion. 

Ransomware Attack Timeline

The morning of 1 Aug, I found an article in my feed about a ransomware attack against a municipality; specifically, Montclair Township in New Jersey. Ransomware attacks against municipalities are not new, and they can be pretty devastating to staff and citizenry, as well, and this is even before a ransom is paid. Services are impacted or halted, and I've even seen reports where folks lost considerable amounts of money because they weren't able to get the necessary documentation to process the purchase of a home.

I decided to dig a bit and see what other information I could find regarding the issue, and the earliest mention I could find was this page from 6 June 2023 that includes a link to a video message from the mayor, informing everyone of a "cyber incident". I also found this article from North Jersey dot com, reporting on the mayor's message. Two days later, this article from The Record goes into a bit more detail, including a mention that the issue was not related to the MOVEit vulnerability.

At this point, it looks as if the incident occurred on 5 June 2023. As anyone who's investigated a ransomware attack likely knows, the fact that files were encrypted on 5 June likely means that the threat actor was inside the environment well prior to that...2 days, 2 weeks, 2 months. Who knows. If access was purchased from an IAB, it could be completely variable, and as time passes and artifacts oxidize and decay, as the system just goes about operating, it can become harder and harder to determine that initial access point in time. 

What caught my attention on 28 July was this article from Montclair Local News stating that had a bit of a twist on the terminology used in such incidents; rather, should I say, another twist. Yes, these are referred to many times as a "cyber incident" or "cyber attack" without specifically identifying it as ransomware, and in this instance, there's this quote from the article (emphasis added):

To end a cyber attack on the Montclair Township’s IT Department, the township’s insurer negotiated a settlement of $450,000 with the attackers.

It's not often that a ransom paid is referred to as a settlement, at least not in articles I've read. I can't claim to have seen all articles associated with such "cyber attacks", but at the same time, I haven't seen this turn of phrase to refer to the ransom payment.

Shortly after the above statement, the article goes on to say:

Some data belonging to individual users remains to be recovered...

Ah, yes...a lot of times you'll see folks say, "...don't trust the bad guy...", because there's no guarantee that even paying for the decryptor that you'll get all of your data back. This statement would lead us to believe that this is one of those instances.

Another quote from the article:

To guard against future incidents, the township has installed the most sophisticated dual authentication system available to its own system and it is currently up and running.

Does this say something about the attack? Does this indicate that the overall issue, the initial infection vector, was thought to be some means of remote access that was not protected via MFA?

Something else this says about the issue - 5 June to 28 July is almost 8 full weeks. Let's be conservative here and assume that the reporting on 28 July is not up-to-the-minute, and say that the overall time between encrypted files and ransom (or "settlement") paid is 7 weeks; that's still a long time to be down, not being able to operate a business or a government, and this doesn't even address the impacted services, and the effect upon the community.

I know that one article mentions a "settlement" or what's more commonly known as a ransom payment, but where does that money really come from?

Municipalities (local governments, police departments, etc.) getting ransomed is nothing new. Newark was hit with ransomware in April 2017; yes, that was 6 yrs ago, multiple lifetimes in Internet years, but shouldn't that have served as a warning?

Events Ripper Updates

I uploaded several new updates to Events Ripper plugins in the repo recently...

defender.pl - added a check for event ID 2050 records, indicating that Defender uploaded a sample (as opposed to event ID 2051 records, indicating that a file could not be sent). The plugin now displays the file path and name, as well as the hash.

filter.pl - added a check for event ID 5152 records, indicating that WFP blocked a packet. The plugin displays the source IP address of the packet, but not the direction (usually inbound), ports, or destination IP address (will likely be the endpoint itself, or broadcast). When looking at this output, keep the endpoint IP address in mind...you may see connection attempts from other subnets, or from public IP addresses.

scm.pl - added a check for Service Control Manager/7031 service crash events. I did not add event ID 7039 events; well, actually, I did, but found that there was a lot of noise, and if you're creating a timeline and using Events Ripper as it was intended, you'll get a pivot point from the new capability.

Thoughts on Tool Features, pt II

My previous post on this topic addressed an apparent dichotomy (admittedly, based on a limited aperture) of thought between vendors and users when it comes to features being added to commercial forensic suites. This was the result of a road I'd started down a while back, trying to see if there was any value proposition to RegRipper at all (turns out, no, there isn't), and was simply the most recent pit stop along that road.

From my previous post, there seem to be two thoughts on the matter, or maybe it's more correct to say that only two basic positions or perspectives were shared. One is from vendors, some who rely on users to express the need for features; as such, vendors are relying on users to drive their own investigations, requesting or expressing the need for features as they arise. I'm sure vendors have ways of prioritizing those requests/needs, based on limited/available resources.

The other perspective is from users of those forensic tools; the views expressed are that if a vendor finds or 'sees' a cool feature, it should simply be added to the tool or framework, regardless of whether anyone actually wants it or not. To me, this seems to be users relying on vendors to drive investigations.

While I tend to agree more with the vendor perspective, as a user of forensic tools (albeit not commercial products), it seems that I have a different perspective from most users. There have been a few times in my career where I've had to deal with the issue of tool features; some examples follow:

CCN Searches
Circa 2009-ish (give or take), Chris Pogue and I were working a PCI forensic investigation, and found that while Discover and JCB cards had reportedly been processed by the merchant, none were appearing in our searches. As our team had recently grown, we had settled on EnCase (then owned by Guidance Software) as the tool used for all of the PCI-specific searches (CCNs, hashes, file names, etc.); this tool was commonly understood, and we wanted accuracy and consistency above all else.

We began digging into the issue, even going to the brands and getting test data. We kept reducing the scope of our testing, even to the point of, "here's a file with 3 Discover CCNs in it and nothing else...find all Discover CCNs", and each time, got no hits on either Discover or JCB card numbers. We determined that the IsValidCreditCard() built-in function, which was a closed-source "black box" for us, did not consider either brand of card number valid. We needed this capability now, and we were getting nowhere with the vendor, so we reached out to someone who was known for their EnScripting ability and asked for help. We ultimately ended up with a new function, one that included 7 Regexs, that we used to overload the built-in function. Borrowing a trick I learned from one my professors during my undergrad studies, Chris and I wrote up a quick email to everyone, stating, "copy this file to this location within the EnCase installation, etc.", and got everyone up and running at a consistent level pretty quickly. Yes, the process for searching for CCNs was a tad slower, but it was more accurate now, it was consistent across the team, and Chris and I could easily help troubleshoot any issues folks had in running the new function. After all, the only thing that could really go wrong at that point was that the file we sent was copied to the wrong location.

This all boiled down to the fact that we recognized that the tool we were using did not have the functionality we needed, even though, across the industry, everyone assumed that it did. We knew what we needed, we knew we needed it immediately, and we knew that we needed to ensure accuracy and consistency across the team. To do so, we sought help where we felt we needed it, and were more than willing to accept, "yeah, okay, we missed that..." along the way, in order to get to our goal. 

Carving Records
In 2012, I attended the DC3 conference in Atlanta, and after spending several days there and returning home, I ran into a fellow attendee at the baggage claim for our flight. We knew of each other within the community, and I had no idea we'd been on the same flight. As we were waiting, we got to chatting, and they mentioned that they'd been "looking at" a system for about 3 months, and were stuck. I wanted to know more, and they said they were stuck trying to figure out how to recover cleared Event Logs. As soon as they said that, I said that I'd send them a tool I'd written as soon as I got home...which I did. It was late when I got home, so I kissed my wife, turned my computer on, and sent them the tool along with instructions, as promised.

In this case, someone working for the government had a situation, an investigation, where they were stalled "looking at" the image...for 3 months. Now, I have no doubt that that didn't amount to 8 hrs a day, 5 days a week, etc., but that it was more on-and-off over the span of 3 months. However, during that entire time, I had a tool that I'd developed that would have been perfect for the situation, one that I'd not only developed but used to great effect. In fact, the tool was originally written because an Event Log on an XP system had 2 more records within the logical .evt file than were reported by the API, which I'd been able to recover by basically writing a carver. As such, what would work on a logical .evt file would work equally well on unallocated space extracted from an image via blkls.

RegRipper
Something I really like about RegRipper that wasn't something I specifically thought of during the original design is how easily it can be updated (the same applies to Events Ripper). For example, not long ago, I was looking into nssm, the "non-sucking service manager", and ran across the usage page. This page describes a number of Registry values and keys that are used by nssm, as well as by tools like it, such as MS's svrany.exe (which nssm replaces). Both provide persistence and privilege escalation (Admin to LOCALSYSTEM) capabilities, and I knew that I'd never remember to specifically look for some of these keys and values...so I wrote a RegRipperPro plugin to do it for me; the output of a test is illustrated in the figure below.

Fig: Appenvironment.pl Plugin Output

So, as you're reading this, you're probably thinking to yourself, "...but I can't write my own plugin." I get it. Some folks don't bother thinking, "I can't...", and just do it, but I get it..Perl isn't in common usage any longer, and programming simply intimidates some folks. That's cool...it's fine. 

Because all you need to do is ask for help, and maybe provide some sample data to test against. I've consistently turned working plugins around in about an hour, when folks have asked (which hasn't been very often).

The plugin I wrote (output in the figure above) took me just a couple of hours in the evening...I had to stop working to make dinner, take the dog out, etc., but it was pretty straightforward to complete. Now, I don't have to specifically remember these values (and the included key) when conducting an investigation; it's trivial to run all available plugins against various hives, so even a year from now, if I never revisit the issue that led to the plugin again, I'll still have the "corporate knowledge" and the query will still be part of my process.

So, I have something of a different perspective regarding tool features and who drives an investigation. My perspective has always been that as the analyst/investigator, it was my job to drive the investigation. Now, that doesn't prevent me from asking for assistance, or seeking someone else's perspective, but ultimately, the tools I use and the functionality I need are up to me, as an investigator, and I'm not going to structure my investigation around the functionality provided by a tool (or not, as the case may be).

Thoughts on Tool Features

Not long ago, some exchanges and conversations led me to do something I'd never done before...post a poll on LinkedIn. These conversations had to do with whether or not analysts and practitioners within the industry felt there was adequate value proposition to incorporate RegRipper in to a commercial forensic suite. No conditions, no specific goals or outcomes, just "is this something that makes sense?" As you can see from the poll, the responses (the few that there are) are pretty much 4:1 in favor of the idea.

I posted the poll because when I asked a vendor for their thoughts, the response was, "...none of our users have asked for it." Another vendor responded with:

...we need to focus on two things - what customers tell us they want (preferably things that are both powerful and unique), and what helps us in significant ways in our own casework.

There have been times we go pretty far out on a limb in terms of functionality we think people will want, and no one gives a shit. 

From a user perspective, some of the feedback from the poll, as well as from other conversations and exchanges, indicates that some users feel that vendors should take charge of providing "needed" functionality without being asked. 

This really seems like two diametrically opposed views on the subject, with the vendor side saying, "we rely on our users to tell us their needs", and the users saying, "we rely on our vendors to guide our investigations."

In 2020, I presented at OSDFCon on effectively using RegRipper. On pg 3 of the linked PDF, in the second slide, there are several thoughts I had regarding possible useful updates to RegRipper, including adding MITRE ATT&CK mapping, Analysis Tips, and reference URLs to the plugin output. I did not receive any feedback to this presentation, either during or following the presentation itself. No, "hey, this is a great idea!", and no, "OMG, this is the dumbest thing I've ever heard." However, I felt that these were things that I would find useful in the tool, and since other analysts didn't seem to be interested, I set about creating my own internal repo of RegRipper v4.0, or "Pro". This has become the tool I use, update, and continue to develop. In fact, earlier this year, I started in the first steps of creating plugins with JSON output, starting with the appcompatcache.pl plugin.

Back around 2007, I started developing what became RegRipper because none of the tools I had access to at the time, either commercial or free, provided the capability I needed for the work I was doing and the process I was developing. I opted to create a tool in the model of Nessus (i.e., plugins) so that I could easily update the tool without completely rewriting it. I developed the tool so that I could run individual plugins, or "profiles", which are designated groups of plugins that can be run in support of a playbook. I later added the ability to run all available plugins as it seemed to be how most folks were wanting to use the tool anyway.

The idea of "profiles", while I thought it would be an incredible capability, never caught on. You could run "profiles", or analysis playbooks based on file access, USB device usage, etc. I know that there are commercial tools out there that have these capabilities, but what RegRipper provided me was the ability not only to pick and choose, but to also update the tool with new plugins, new capabilities and functionality, with minimal turn-around time. I've had a few instances over the years where folks have reached out and asked for assistance, provided test data, and I've been able to turn around a working plugin in under an hour.

This is what I wanted for the community...for folks using the tool to find something they hadn't seen before, something new, and add to the tool. Unfortunately, that really never caught on, and to some extent, now I know why.

The question becomes, where do you stand? Do you think that vendors providing commercial forensic suites should drive investigations based on the features they provide, or should analysts and investigators be the ones who drive their investigations, and look for the right tool, or correct too usage?

The Next Step: VHD Files and Metadata

Keeping with the theme from my previous blog post of building on what others have done and written about, and of assembling the pieces that are already available to build on a foundation built by others, I found something interesting that seems like a great "next step".

Anyone who's followed this blog for any length of time knows that I'm a huge fan of metadata, and that anytime a threat actor sends you metadata from their endpoint or environment, it's basically free money. For example, my posts on LNK metadata extraction and what can be derived from analysis of this data go back quite a ways. Another great example of the use of LNK metadata to further investigations comes from Mandiant, in this Cozy Bear blog post from Nov, 2018 (see fig. 5 and 6).

Tony Lambert recently shared a blog post where he dug deep into getting intel from VHD file metadata, and then digging in even further to get intel from metadata within the files found within the VHD file, in this case, an LNK file. In his blog post, Troy used EXIFTOOL to extract metadata from both the VHD file and the LNK file.

I used my own toolset and as with EXIFTOOL, found that the LNK file had no available "machine ID" or NetBIOS system name for the host on which it was built; this is one of the elements of an LNK file, based on the documented structure format. However, this may not be unusual or unexpected, because the time stamps embedded in the shell item ID list elements were zeroed out, as illustrated in figure 1.

Fig. 1: Shell Item ID List Time Stamps

If you took a close look at the Mandiant blog post mentioned above, you'd see that the time stamps from the shell item ID list elements were what the analysts used to develop intrustion/threat intel, based on how the time stamps changed between the 2016 and 2018 campaigns. Zero'ing these values out is not difficult (I've done it before), and may actually be scripted, or simply added to the LNK builder.

While the lack of time stamps doesn't give us anything to pivot on or track, there is something else embedded within the available PropertyStoreDataBlock within the LNK file; specifically, a SID, as illustrated in figure 2.

Fig. 2: SID embedded in LNK 

Using this SID, a Yara rule can be used to perform a VirusTotal retro-hunt for similar LNK files, or to scan across local malware repositories. For example, from this LNK file, we can see that it was built on a system using a built-in Administrator account (RID: 500). 

From an intrusion intel perspective, it's pretty clear that if a threat actor sends files to a target, they're very likely sharing a wealth of information about their development environment. When it comes to LNK files, even those embedded in disk image (ISO, VHD) files, a great deal of information about the development environment may be shared (as described by the folks at JPCERT in 2016).

Issues With VHD Files

Two of the issues with image files (ISO, IMG, VHD[X]) is that users can automatically mount them via a double-click, and that ISO files in particular did not not propagate mark-of-the-web (MotW), a security "setting" available on files downloaded from the Internet. The MotW issue with ISO files in particular was addressed in a Nov 2022 security update. If users have no legitimate business reason to automatically mount disk image files via double-clicking them, Huntress has a blog post that addresses disabling this capability, while still permitting programmatic access to the files, such as mounting a VHD or VHDX file via the Disk Manager. Disabling the ability for users to double-click and automatically mount these files as accessible file systems has been available for some time but the Huntress blog makes it a simple matter of copying and pasting the PowerShell code to change the setting.

Shoutz to Tony, not only for his work, but for sharing it with us all! We're all the better for it when we take the time to write about our research or experiences, sharing them with others.

Additional Resources
VHDX metadata table entry 

The Next Step

A lot of times, we'll run across something or read something really very profound and valuable, something that opens our eyes and makes us go, "oh, wow", and impacts us enough that it changes the way we do things. I can say that of a number of blogs posts and articles, by various authors, going back quite a few years. And then later, being able to add additional information to the original findings, information that may not have been recognized or available at the time, can really aid in our investigations.

A while back, Krz shared this blog post, detailing how default settings for Scheduled Tasks include the "stop if the computer switches to battery power" setting by default, and the impact that setting can have on a forensic investigation. For example, PCI forensic investigations require the analyst to specifically address the "window of compromise", and malware that persists via a Scheduled Task will be impacted by whether or not the system in question was running on battery power or not. Krz's previous blog post addressed using the SRUM database to determine the battery charge level, and in that post, Krz linked to a tool he'd written to extract and display that data.

I ran across something recently that I wanted to use to build on Krz's excellent work; from the Microsoft-Windows-UniversalTelemetryClient%4Operational.evtx Event Log, we see a UniversalTelemetryClient/60 event record that lets us know if the system was on battery power or not, as illustrated in figure 1:

Fig 1: UniversalTelemetryClient/60 event, on batter power 

In this particular case, I took my laptop from my office to another room, so I could attach it to the TV via an HDMI cable and watch our church service remotely. When service was complete, and I reconnected the laptop to the power cord in my office, I saw the UniversalTelemetryClient/60 record illustrated in figure 2.

Fig. 2: UniversalTelemetryClient/60 event, off batter power

From the same Windows Event Log file, UniversalTelemetryClient/55 records will let us know if the system had access to the Internet or not, further aiding us in our investigation. This information (system is on or off battery, on or off the Internet) can be extremely valuable during an investigation, particularly when incorporated into a timeline. If a system has malware that persists via a Scheduled Task using default settings, and the system if on battery power when the task was scheduled to run, then it will not run. It may also be helpful to understand when the system did and did not have an Internet connection.

Events Ripper Update

Something I really, really like about tools like RegRipper and Events Ripper is that when I see something in the data during an investigation, I can explore whether it makes sense to pull that out and make it visible to the investigator, and if so, figure out how it makes sense to do so. Because of how these tools are set up, the turn around for something new is pretty quick, and the retention (and sharing) of corporate knowledge is pretty freakin' cool!

This time, I updated the logins.pl plugin, so that it collects and displays some additional data points beyond the 'current' version; specifically, usernames and SIDs for type 3 and type 10 logins, as well as source system names (if not "-" in the event record), correlated to source IP address, for type 3 and type 10 logins.

During a recent incident we were digging into a bit further, we were seeing some odd source system names, ones we'd seen previously, on other incidents for other customers. Now, this isn't stating definitively that it's the same source system, of course, but it is an interesting data point worth tracking...so why not extract that information and make it easy for an analyst to see. We were also seeing repeated type 3 logins for a source system named "nmap", and I wanted to see the logins and source IP addresses that may have had the same source system name. Interestingly, we also saw some additional anomalies, but the point is that this information is easy to see now.

With the usernames, in one instance, we were seeing repeated type 3 logins for the "Guest" account; including the SID alongside the username for the type 3 (and type 10) logins provides insight into possibly compromised credentials. In the case we were looking at, the RID for the account was 501, which tells us that someone had enabled the Guest account, something that serves as an interesting data point for the incident.

I'd love to provide some sample output but most of the CTF data I have access to doesn't include a great deal of terribly interesting data points.