Analysis Process

Now and again, someone will ask me, "...how do you do analysis?" or perhaps more specifically, "...how do you use RegRipper?" 

This is a tough question to answer, but not because I don't have an answer. I've already published a book on that very topic, and it seems that my process for doing analysis is apparently very different from the way most people do analysis. 

Now, I can't speak to how everyone else goes about analyzing an endpoint, but when I share my process, it seems that that's the end of the conversation. 

My analysis process, laid out in books like "Investigating Windows Systems", is, essentially:

1. Document investigative goals. These become the basis for everything you do in the investigation, including the report.

Always start with the goals, and always start documentation by having those goals right there at the top of your case notes file. When I was active in DFIR consulting, I'd copy the investigative goals into the Executive Summary of the report, and provide 1-for-1 answers. So, three goals, three answers. After all, the Executive Summary is a summary for executives, meant to stand on it's own.

2. Collect data sources.

This one is pretty self-explanatory, and very often based on your response process (i.e., full images vs "triage" data collections). Very often, collection processes will include the least amount of data extracted from a system for the biggest impact, based upon the predominance of business needs, leaving other specific sources for later/follow-on collection, if needed.

3. Parse, normalize, decorate, enrich those data sources.

Basically, create a timeline, from as many data sources as I can or makes sense, based on my investigative goals. Easy-peasy.

Timelines are not something left to the end of the investigation, to be assembled manually into a spreadsheet. Rather, creating a timeline as a means of initiating an investigation provides for much needed context.

4. Identify relevant pivot points.

RegRipper and Events Ripper are great tools for this step. Why is that? Well, within the Registry, often items of interest are encoded in some manner, such as binary, hex, ROT-13, or some folder or other resource represented by a GUID; many of the RegRipper plugins extract and display that info in human-readable/-searchable format. So, running RegRipper TLN plugins to incorporate the data into a timeline, and then run "regular output" plugins to develop pivot points. Events Ripper is great for extracting items of interest from events files with (hundreds of) thousands of lines.

5. Identify gaps, if any, and loop back to #2.

Based on the investigative goals, what's missing? What else do you need to look for, or at? You may already have the data source, such as if you need to look for deleted content in Registry hives,

6. Complete when goals are met, which includes being validated.

An issue we face within the industry, and not just in DFIR, is validation. If a SOC analyst sees a "net user /add" command in EDR telemetry, do they report that a "user account was created" without (a) checking the audit configuration of Security Event Log, and (b) looking for Security-Auditing event records that demonstrate that a user account was created? If it was a local account, is the SAM checked?

Or, if msiexec.exe is seen (via EDR telemetry) running against an HTTP/HTTPS resource, is the Application Event Log checked for MsiInstaller events?

My point is, are we just saying that something happened, or are we validating via the available data sources that it actually happened?

7. Anything "new" gets baked back in

The great thing about timelines and other tools is that very often, you'll find something new, something you hadn't seen before, and was relevant (or could be) to your investigation. This is where most of the Events Ripper plugins have originated; I'll see something "new", often based on an update to Windows, or some installed application, and I'll "bake it back into" the process by creating a plugin.

Yes, documenting it is a good first step, but adding it back into your automation is taking action. Also, this way, I don't have to remember to look for it...it's already there.

For example, several years ago, another analyst mentioned seeing something "new" during a response; looking into it, this new thing was a Microsoft-Windows-TaskScheduler/706 event record, so once I got a little more info about it, and dug into the investigation myself just a bit, I added it to eventmap.txt. After that, I never had to remember to look for it, and I had the necessary references to support the finding already documented.

Rundown

I ran across a fascinating post from Cyber Sundae DFIR recently that talked about the Capability Access Manager, and how with Windows 11 it includes database of applications that have accessed devices such as the mic or camera, going beyond just the Registry keys and values we know about. 

It should surprise no one that this is an artifact found on Windows 11; after all, there've been more than a few changes to Windows 10, even just between various individual builds. As such, depending upon the nature of your case, and your investigative goals, this may be a value resource to explore. 

As a reminder, RegRipper has two plugins that query various values beneath the CapabilityAccessManager\ContentStore subkey, contentstore.pl and location.pl. The contentstore.pl plugin also comes in a TLN variant, as well, so that the information can be included in an investigative timeline.

I also ran across an interesting article regarding artifacts of data exfiltration on various platforms, including Windows. While the list of these artifacts, the one specific to Windows, is a good one, IMHO, it misses some very useful artifacts. Some of the artifacts listed in the article, such as Prefetch files, are not definitive, and need to be used in conjunction with other artifacts to even provide a hint of data exfiltration. After all, you can call something whatever you want on Windows systems and not impact the functionality; you can rename net.exe to winrar.exe, and the Prefetch file will be for winrar.exe, and unfortunately, command line arguments are not stored in the Prefecth files.

Also, the article states that the Shimcache, "...stores information about executables that have been run on the system, even if the file has been deleted. Investigators can use this to trace the usage of data exfiltration tools." The Shimcache does not only/solely store information about executables that have been run on the system, something that has been documented again and again. Executables can be included in the ShimCache if the user has browsed to the folder where the EXE resides. So, yes, the ShimCache does include executables that have been run on the system, but those with little experience often interpret this statement to mean that this is all that the ShimCache includes, and is therefore "evidence of execution". 

There are other, perhaps more definitive data sources that point to data exfiltration. For example, querying the BITS Client Event Log for upload jobs would reveal a good deal of information regarding data exfiltration. One data source I've used in the past is the IIS web server logs; a threat actor moved archive files to the web server, and then issued GET requests for the files. Looking back through the logs we had available, there had been no prior instances of .zip files being requested.

Yes, the SRUM db is a great place to look for evidence of data exfiltration, very much so. However, as with other data sources, we have to keep the context of the data source in mind when conducting an investigation.

Even with this list, there are number of ways to exfil data off of a Windows system, including the use of finger.exe (one of my favorites!).

Exploiting LNK Metadata

Anyone who's followed me for a bit knows that I'm a huge proponent of metadata, and in particular, exploiting metadata in LNK files that threat actors create, use as lures, and send to their targets.

I read an article not long ago from Splunk titled, LNK or Swim: Analysis & Simulation of Recent LNK Phishing. The article covered a good bit of information regarding LNK files sent by some threat actors, and even included a list of metadata items that could be used for "threat intel purposes", as illustrated in figure 1.

Fig. 1: Splunk article excerpt

However, what's illustrated in figure 1 was as far as they went. In fact, reading through the article and looking at the images of LNK parser tool output, each of those images is cut off before embedded metadata and "extra data blocks" can be seen. Even then, including this information in the images would require analysts to manually transpose this information, which is a very inefficient and error-prone process, particularly given how small some of these images are within the article.

I will say that the article does go on to talk about the use of LNK files in phishing campaigns, and provides a link to an LNK generator tool. There are some definite opportunities here for a research project, where LNK metadata is compared across different creation methods (righ-click on the Desktop, PowerShell, the generator tool, etc.).

In December, 2016, JPCERT published an article describing how threat actors reveal clues about their development environment when they sent LNK files to their targets. The LNK files would contain metadata associated with the system on which they were created, which from a CTI perspective is "free money".

Figure 1 from the JPCERT article, extracted and illustrated in figure 2, demonstrates one way that the LNK file metadata can be used. In this figure, various elements of metadata are used in a graph to illustrate relationships amongst data that would not be obvious via a spreadsheet.

Fig. 2: Figure 1, excerpted from JPCERT article

At this point, you're probably asking, "how would this metadata be used in the real world?" Almost 2 years after the JPCERT article was published, the folks at Mandiant published an article regarding the comparison of data across two Cozy Bear campaigns, one in 2016 and the other in 2018. Within that article, at figures 5 and 6, the Mandiant analysts compared LNK file from the two campaigns, illustrating not just the differences, but also the similarities, such as the volume serial number (fig. 5) and the machine IDs (fig. 6). While there were differences in time stamps and other metadata, there were also consistencies between the two campaigns, 2 yrs apart.

If you're saying, "...but I don't do CTI..." at this point, that's okay. There may be steps we can take to use what we know about LNK files to protect ourselves.

If you have Sysmon installed on endpoints, Sysmon event ID 11 events identify file creation or modifications; you can monitor the Sysmon Event Log for such events, and extract the full file name and path. If the file extension is ".lnk", you can verify that that file is an LNK file based the "magic number" within the file header and the GUID that follows it. From there, you can then either flag the file based on the path, or take an extra step to compare the machine ID to the current endpoint name; if they're not the same, definitely flag or even quarantine the file. 

Is implementing this yourself kind of scary? No problem. If you're using an EDR vendor (directly, or through an MDR) and the EDR generates similar telemetry (keep in mind, not all do), contact the vendor about adding the capability. Detecting behaviors based on LNK files is notoriously difficult, so why not detect them when they're written to disk, and take action before a user double-clicks it?

Shell Items

I ran across a Cyber5W article recently titled, Windows Shell Item Analysis. I'm always very interested in not only understanding parsing of various data sources from Windows systems, but also learning a little something about how others view the topic. 

Unfortunately, there was very little actual "analysis" in the article, an excerpt of which is shown in figure 1.

Figure 1: Text from article

I'm not sure I can agree with that statement; tools, be they open source or commercial, tend to be very good at extracting, parsing, and presenting/displaying data, but analyzing that data really depends on the investigative goals, something to which tools are generally not privy. 

But we do see that quite often in the industry, don't we? We'll see something written up, and it will say, "...<tool name> does analysis of...", and this is entirely incorrect. Tools are generally very good at what they do; that is, parsing and displaying information, that an analyst then analyzes, in the context of their investigative goals, as well as other data sources and artifacts.

The rest of the article doesn't really dig into either the metadata embedded within shell items, nor the analysis of the various artifacts themselves. In fact, there's no apparent mention of the fact that there are different types of shell items, all of which contain different information/metadata. 

I've written quite a bit regarding Windows shell items embedded within various data sources. In fact, looking at the results of a search across this blog, there are more than a few posts. Yes, several of them are from 2013, but that's just the thing...the information still applies, when it comes to shell item metadata. Just because it was written a decade or more ago doesn't mean that it's "out of date" or that it's no longer applicable. 

While it is important to understand the nature and value of various data sources and artifacts, we must also keep in mind that tools do not do analysis, it's analysts and examiners who collect, correlate and analyze data based on their investigative goals.

RegRipper Educational Materials

A recent LinkedIn thread led to a question regarding RegRipper educational materials, as seen in figure 1; specifically, are there any.

Figure 1: LinkedIn request

There are two books that address the use of RegRipper; Windows Registry Forensics, and Investigating Windows Systems (see figure 2). Together, these books provide information about the Windows Registry, RegRipper, and the use of RegRipper as part of an investigation. 

Figure 2: IWS

Demonstrating the use of RegRipper in an investigation is challenging, as RegRipper is only one tool I typically use during an investigation. Investigations do not rest on a single data source, nor on a single artifact. The challenge, then, is in demonstrating the use of RegRipper in an analysis process, such as any of the case studies in Investigating Windows Systems, that most folks are simply unfamiliar with; the value of the demo isn't diminished, it's completely lost if the overall process isn't understood.

The analysis process demonstrated multiple times in IWS is the same process I've used for years, well prior to the publication of the book. It's also the same process I use today, sometimes multiple times a day, as part of my role at Huntress. Any demonstration of RegRipper, or even Events Ripper, as part of the process would fall short, as most analysts do not already follow that same process. 

If you are interested in educational materials associated with RegRipper, I would be very much willing to learn a bit more about what you're looking for, and have a conversation pursuant to those needs. Feel free to reach to me on LinkedIn, or via email.

What is "Events Ripper"?

I posted to LinkedIn recently (see figure 1), sharing the value I'd continued to derive from Events Ripper, a tool I'd written largely for my own use some time ago.

Fig. 1: LinkedIn post

From the comments to this and other LinkedIn posts regarding Events Ripper, I can see that there's still some confusion about the tool...what it is, what it does, what it's for.

Now, I've posted about Events Ripper a number of times on this blog since I released it about 2 years ago, and those posts are trivial to find, including the post illustrated in figure 2.

Fig. 2: 30 Sept 2022 Blog Post

The point is that these blog posts are trivial to find. For example, while I've posted a number of "Events Ripper Update" blog posts over the past 2 years, here's a really good example of a post from October, 2022 that includes a great deal of content regarding the use of Events Ripper. So, in addition to the repo readme file, there's a good bit of info available, and I'm more than happy to answer any questions folks may have. 

To allay any lingering confusion, let's talk a little bit about what Events Ripper is not, then a bit about what it is, and how it works.

What It Is Not
Let's start with what it's not...Events Ripper is not an analysis tool, nor does it do analysis. We often see this turn of phrase used to describe various tools, stating that they do analysis, and this is simply not the case. This is especially the case for Events Ripper. 

Let me say this again...Events Ripper does not do analysis. Nor does any other tool. Analysis is something an analyst, a human, does, by applying their knowledge and experience to the data before them. Tools can parse, normalize, even decorate, and present data, but it's up to an analyst to make sense of the data and present it in an understandable manner.

If you're not familiar with creating timelines as an investigative resource, and incorporating Windows Event Log records alongside other data sources (file system, Registry, etc.) into an overall timeline, you're not going to see much use for Events Ripper. When I say, "creating timelines", I don't mean what many analysts do with Excel, begrudgingly, at the end of an "investigation". What I mean by "creating timelines" is producing an investigative timeline from multiple data sources as a way to begin, and to facilitate analysis.

If, as an analyst, you believe that there are only three Windows Event Logs of interest...Security, System, and Application...then Events Ripper is not for you. It's not something you want to be using, as it will provide no value to you. 

If you believe that event IDs are unique, and that event ID 4624 only refers to successful login events, then Events Ripper is not for you, it's not something that you'll derive value from using.

If you're not familiar or comfortable with working at the command line, Events Ripper is not a tool you'll find a great deal of value in using.

What Is Events Ripper
Events Ripper is a tool intended to facilitate analysis, to identify investigative timeline pivot points and to allow analysts to get to conducting analysis much sooner. The idea is to exploit what analysts have already seen, learned and documented through plugins, to get all analysts on the team (and beyond) to the point where they're actually conducting analysis much faster. 

I look into endpoints on a daily basis, as part of deeper investigations into malicious activity. Collecting a dozen or fewer Windows Event Log files (the number is usually 9 or 10, under most circumstances) to create a timeline often results in 300K or more lines in the events file, which is the intermediate step to creating an investigative timeline. Again, this number of events is just from Windows Event Log files, so finding anything specific would be akin to finding a needle a huge stack of needles. This is why having a computer look through hundreds of thousands of events, extracting items of interest, is so much more efficient and doing to manually, either by opening individual .evtx files in Event Viewer, or by searching and tabbing through the results.

Even when I'm looking for just one thing, such as a list of all VHD, IMG, and/or ISO files mounted on the endpoint, it's still a lot of work to parse through one Windows Event Log file and extract that list. While many analysts will download the .evtx file to their analysis workstation, open it locally in Event Viewer, and tab through the events, I'd much rather use available tools to parse and normalize the events in the file, and then use Events Ripper to give me either a simple list, or something a bit more interesting, such a sorted (based on time of 'surfacing') list of mounted files. 

How Does It Work
Straight from the readme file in the Github repo for the tool, you start by parsing your data sources into the 5-field, "TLN" format events file, which is an intermediate file format prior to creating an investigative timeline. You then create your timeline (I do), and then run Events Ripper against the events file. This is just a text-based file that contains the events that will be parsed into the investigative timeline, with one event per line. 

If you're looking for something specific, such as mounted ISO files, you can choose to simply run a single plugin (in this case, mount.pl). If you're working on something a bit more expansive, run all off the plugins, redirecting the results to a single text file for reference. Just follow the examples in the readme file. 

Event Ripper is incredibly versatile. For example, if I'm working on an incident that involves processes run as child processes of sqlservr.exe, I'll get a copy of the Application Event Log, parse it, and run the mssql.pl plugin against it. If the output of that plugin tells me that there are multiple instances where the xp_cmdshell stored procedure was enabled, I can then go back to the events file, and create an "overlay" or micro-timeline of just those events, using the following command line:

C:\data>type events.txt | find "xp_cmdshell" > x_events.txt

I can then create the timeline using the following command:

C:\tools>parse -f c:\data\x_events.txt > c:\data\x_tln.txt

I know have an "overlay" timeline of just those events that contain references to the stored procedure, and very often these events will correspond to malicious use of the stored procedure to run commands on the endpoint with the privileges of the MSSQL instance (usually SYSTEM). 

Using simple DOS-based tools and commands, such as "find", "findstr", and redirection operators (all stuff I learned from using MS DOS 3.3 and beyond), I can create investigative timelines and case notes to thoroughly document my findings, facilitating analysis and getting me to results in a quick, efficient manner. This leads to incident scoping, as well as threat actor profiling, and developing detections, protection mechanisms, and documenting control efficacy. 

Tools like Events Ripper also provide a phenomenal means for documenting, retaining, and building on "corporate knowledge"; this applies equally well to both internal and consulting teams. If one analyst sees something, there's no reason why they can't develop and document it in a plugin, and share it with others so that now, other analysts can benefit from the knowledge without having to have had the experience. 

Conclusion
Again, Events Ripper does not do analysis...no tool does, regardless of what folks say about it. What Events Ripper does is facilitates analysis by allowing analysts to document their findings in a reproduceable manner, in a way that other analysts can exploit the knowledge without having to have the same analysis experience. 

The Myth of "Fileless" Malware

Is "fileless" malware really fileless?

Now, don't get me wrong...I get what those who use this term are trying to say; that is, the actual malware itself, the malicious code, does not exist as a file on the local hard drive. However, for the uninitiated, the use of the term "fileless" is misleading, because in order for the things to happen and for the malware to persist, there has to be something in a file somewhere on the drive. Otherwise, what's the point?

Yes, threat actors can release code that had a devastating, even catastrophic effect without persisting on an endpoint. This is not in question. 

However, the term "fileless" can imply to the uninitiated reader that files are not used at all, and this simply is not the case. This is important to understand, as this allows us to develop appropriate protections, detections, and responses for this kind of malware. Understanding this also means allows us to leverage DFIR skill sets to learn more about the threat actor leveraging various techniques to "remain fileless".

Sometimes, we just get the descriptions of the malware wrong. In Prevailion's DarkWatchman write-up, at the bottom of pg, 3, the authors state, "Various parts of DarkWatchman, including configuration strings and the keylogger itself, are stored in the registry to avoid writing to disk" (emphasis added), as illustrated in figure 1.

Fig. 1: Excerpt from DarkWatchman Write-up

The Registry is on disk, and is, at it's most basic, a file. Even though the Registry has a binary (rather than ASCII) format, and may be considered a "file system within a file", that does not mean that something that stores its configuration and/or persistence in the Registry is not using a file.

On pg 10, the same write-up states that persistence is achieved via a Scheduled Task, which is contained both in the Registry (a file), as well as within an XML file. Even using various techniques to hide the Scheduled Task XML file from view still means that the configuration and reference to the malware is stored within a file.

Reliaquest's recent article on LotL and "fileless" malware describes "fileless" malware as "running from memory or scripts...instead of executables". Even this definition can be confusing, as a script is a file on disk. 

Yes, I understand that intent is to say that the script isn't the actual malware itself, but instead reaches out off-system to download the actual malware, and then run it in memory so that ideally, the malicious code never touches the disk. Yes, I get it...but it's still misleading and without the appropriate review, the impression is that this malware is incredibly difficult, if not impossible to detect and respond to without a very specific set of tools. 

The article starts off by saying that fileless malware is "harder to detect than traditional malware because it relies solely in memory." I'm not sure that's the case; at work, we detect a lot of SocGholish (referenced in the statement as an example) and other fileless malware, without requiring something that scans memory. 

The article also states that fileless malware "manipulates the command lines of trusted applications...allowing malicious activities to blend in with normal, authorized operations..."; I'm unclear as to what this means, and confused as to how it makes fileless malware harder to detect. In fact, in my experience, it's quite the opposite...if you're monitoring an organization with the appropriate visibility, modified command lines for known-good applications should stand out pretty clearly.

Something else to consider is that not all organizations actually use LOLBins (or LotL) on a regular basis. I've seen organizations that don't use curl.exe or certutil.exe at all. I've worked with customers who, by policy, do not use "net user" to create and manage user accounts. As such, use of these LotL techniques will not remain hidden, particularly if you're looking. How they will remain hidden is if you haven't employed some modicum of visibility, by enabling "Process Tracking" along with full command lines, or Sysmon, or EDR, or some form of AV such as Windows Defender.

The Reliaquest article also discusses threat actor use of LotL techniques, also referred to as LOLBins or LOLBAS to remain stealthy and minimize their impact within a compromised infrastructure. However, this can be a bit misleading. The article indicates that threat actors prefer LotL techniques given the "lack of IoCs" associated with the use of these techniques, and this simply isn't the case, when, in fact, the use of native utilities such as msiexec.exe actually produces quite a few IoCs that can be very valuable to the responders and investigators. And this is simply how the operating system works, without any additional EDR or EDR-like capabilities.

From the Technical Breakdown of the first case study in the Reliaquest article, the SocGholish malware performs the actions illustrated in figure 2.

Fig. 2: First Case Study

How often do users or even admins run "cmdkey /list" within your organization? How about the "net" commands, or "gwmi"? If you have the necessary visibility, and know this, then you can also assess control efficacy, and possibly even use 

So, What?
Who cares, right? Someone calls something "fileless", and whether it really is or not, doesn't matter, does it?

The insistence on the use of the term "fileless" tends to imply that only so much can be done about the malware. After all, just look at the Reliaquest article. The implication is that the malware exists only in memory, so the options for detecting, responding to and analyzing the malware are extremely limited. 

However, this simply is not the case. For the malware to truly be effective, it has to persist in some manner, and whatever that is can be used to hunt for, detect and respond to, and possibly even prevent the malware from impacting the endpoint. Understanding the details of how the malware arrives on the endpoint, and how it persists, allows organizations to assess their own control efficacy and determine how best to address the issue. So while the actual malicious code itself may not be directly detected without some sort of memory-based detection, the precursors, effects/impacts, and follow-on activities tied directly to and associated with the malware can all be detected, because they will "appear" in a detectable manner. This will depend upon your aperture and visibility, of course, but the fact remains that they will be detectable. They could be processes, code retrieved from Registry values, Scheduled Tasks, or even other endpoint impacts recorded in the Windows Event Log, but they will be detectable.

Given the amount of "fileless" malware organizations see with the initial download capability embedded within the Windows Registry, I added the capability of running Yara rules to RegRipper 4.0, in hopes that folks would use that capability to help detect such things.

Addendum, 5 June:
Not long after I published this blog post, John Hammond shared a post on LinkedIn, as shown in figure 3.

Fig. 3 - John's LinkedIn post

Again, the underlined phrase refers to the fact that rather than writing a malware EXE to a value (or values) in the Registry, a "fileless payload" is written instead. This can be confusing because, depending upon the path, "HKEY_CURRENT_USER" can refer to either the NTUSER.DAT or the USRCLASS.DAT file in the user's profile. 

A Look At Threat Intel Through The Lens Of Kimsuky

Rapid7 recently shared a fascinating post regarding the Kimsuky threat actor group making changes in their playbooks, specifically in their apparent shift to the use of .chm/"compiled HTML Help" files. In the post, the team does a great job of sharing not only likely reasons why there might be a shift to this file format, but also what organizations have been previously targeted by the threat actor group, and why they believe that this is shift in TTPs, rather than a separate group all together.

Specifically with respect to this threat actor group, if you fall into one of the previously targeted organizations, you'd definitely want to be concerned about the group itself, as well as it's change in tactics. 

Even if you're not in one of the targeted organizations, there's still value in a blog post such as this; for example, are you able to detect .chm files being sent via email, even if they're embedded in archives? Is this something you even want to do?

How can you protect yourself? Well, the first thing to look at is your attack surface...is there any legitimate business reason for you or your employees to access .chm files? If not, change the default file association from hh.exe to something else, like Notepad. If you want to take it step further, create a text document with a message along the lines of "...you're tried to open a .chm file, please contact an administrator...", and change the default file association to have Notepad open that file. Heck, you can even create a PowerShell script that grabs the name of .chm file, as well as other information (file path, system name, user name, time stamp), and emails it to an administrator, and have that script run instead of actually opening the .chm file. Something like this not only prevents the attack all together, but also provides insight into the prevalence of this type of attack. This may be important to other organizations not targeted by this specific group, as this group is not the only one to rely on .chm files (see here, also). In fact, the folks from TrustWave shared their findings regarding .chm files from over 6 yrs ago.

This is not terribly different from similar measures laid out by Huntress not long ago, in that you can use native Windows functionality (which is free) to enable protective measures that make sense for your organization.

One thing to be aware of, though, is from the section of the blog post that addresses persistence, illustrated in the below image:

The Run key in the HKCU path does not ensure that the program runs at startup, but instead, as stated in the following sentence, when the user logs in. 

What I would do in an investigation is correlate the Run key LastWrite time with the contents of the Microsoft-Windows-Shell-Core%4Operational Event Log, allowing me to validate when the value was actually written to the key. I would then use this information to then pivot back into the investigative timeline in order to determine how the value ended up being created in the first place.

Reading through the Rapid7 post, as well as other posts regarding a similar use of .chm files indications that we could have other information available to serve as pivot points and to validate attack timing, through Windows services or scheduled tasks.

File Metadata
Something else the Rapid7 post does a good job of presenting/discussing is the .chm file format, and tools you can use to access it without launching any code and infecting yourself. There's information in the blog post regarding not just tools, but also the binary structure of the file format itself. This can all be used to enhance DFIR information regarding an attack, which should then feed threat intel, and provide additional insight to detect and respond to such attacks.

Also, given what can be embedded in a .chm file, there are other possibilities for metadata and time stamps, as well. 

On the topic of file metadata, the Rapid7 blog post makes reference to the threat actor group's prior use of LNK files as a delivery mechanism, describing several scenarios during which the use of LNK files was observed. I think it would be fascinating to view the LNK metadata across their use; after all, others have done so to great effect. 

Conclusion
There's a lot of great information in the Rapid7 blog post, and I applaud and greatly appreciate the efforts by the authors, not only performing the research, but also in publishing their findings. However, in the end, this a good deal of threat information, and it's up to the individual reader to determine how to apply it to their environment. 

For me, this is what I like about things like this, and why I appreciate them. Put all the cards...or almost all...on the table, and let me determine who best to utilize or exploit that information within my own infrastructure or processes. A lot of times this is what's best, and we shouldn't consider it to be "threat intelligence". 

Additional Info
For those interested, here's some additional information about the .chm file format that may be useful in writing tools to parse the binary structure of the file format.

Threat Actors Dropping Multiple Ransomware Variants

I ran across an interesting LinkedIn post recently, "interesting" in the sense that it addressed something I hadn't seen a great deal of reporting on; that is, ransomware threat actors dropping multiple RaaS variants within a single compromised organization.

Now, I have heard of impacted orgs being hit multiple times, over the course of weeks, months. or even years. But what I hadn't heard/seen a great deal of was a single organization being compromised by a single threat actor, and that threat actor/affiliate dropping multiple RaaS variants.

Here's the original post from Anastasia that caught my attention. Anastasia's post shares some speculation as to motivations for this approach, which kind of illustrates how this particular topic (motivations) is poorly understood. In item #1 on her list, I think what I'd be most in starting with is a better understanding as to how the findings were arrived at; that is, what were the data points that led to finding that a single affiliate was working with two different RaaS providers simultaneously. As someone who is very interested in the specifics of how threat actors go about their activities (the specifics as to how, not just the what), I have seen systems that were apparently compromised by two different threat actors simultaneously. I've also been involved in providing analysis for incidents where we were able to identify members of a threat group changing shifts, kind of like Fred Flinstone sliding down the back of a brontosaurus. 

From there you can see in the comments, Valery begins responding with some very helpful insight and direction, referring to the topic as "cross-claims". One of the links he provides is a LinkedIn post from Alex that provides some interesting references to how he (Alex) was able to determine that the same threat actor was deploying both Trigona and BlackCat within the same impacted organization. Within the comments to Alex's post, Valery shared an interesting X/Twitter thread, as well.

I should note that the Huntress team has seen both Trigona and BlackCat affiliates in action, albeit not within the same infrastructure, at the same time.

Like I said, I hadn't seen a great deal of open reporting on this particular topic, and it does sound like an interesting tactic, although I'm not entirely sure that I understand the point. I'm sure that it adds some complexity to the claims process, for those who have cyber insurance policies.

Uptycs Cybersecurity Standup

I was listening to a couple of fascinating interviews on the Uptycs Cybersecurity Standup podcast recently, and I have to tell you, there were some pretty insightful comments from the speakers.

The first one I listened to was Becky Gaylord talking about her career transition from an investigative journalist into cybersecurity.

Check out Becky's interview, and be sure to check out the show notes, as well.

I also listened to Quinn Varcoe's interview, talking about Quinn journey from zero experience in cybersecurity to owning and running her own consulting firm, Blueberry Security.

Check out Quinn's interview, and the show notes.

More recently, I listened to Olivia Rose's interview. Olivia and I crossed paths years ago at ISS, and has now hung out her own shingle as a virtual CISO (vCISO). I joined ISS in Feb 2006, about 6 months before their purchase by IBM, which was announced in August 2006. Olivia and I met at the IBM ISS sales kick-off in Atlanta early in 2007.

All of these interviews are extremely insightful; each speaker brings something unique with them from their background and experiences, and every single one of them has a very different "up-bringing" in the industry.

There's no one interview that stands out as more valuable than the others. Instead, my recommendation is to listen to them all, in fact, do so several times. Take notes. Take note of what they say.

Investigative Scenario, 2024-03-12

Investigative Scenario

Chris Sanders posted another investigative scenario on Tues, 12 Mar, and this one, I thought, was interesting (see the image to the right).

First off, you can find the scenario posted on X/Twitter, and here on LinkedIn.

Now, let's go ahead and kick this off. In this scenario, a threat actor remotely wiped a laptop, and the sole source of evidence we have available is a backup of "the Windows Registry", made just prior to the system being wiped.

Goals
I try to make sure I have the investigative goals written out where I can see them and quickly refer back to them. 

Per the scenario, our goals are to determine:
1. How the threat actor accessed the system?
2. What were their actions on objectives, prior to wiping the system?

Investigation
The first thing I'd do is create a timeline from the Software and System hive files, in order to establish a pivot point. Per the scenario, the Registry was backed up "just before the attacker wiped the system". Therefore, by creating a timeline, we can assume that the last entry in the timeline was from just prior to the system being wiped. This would give us a starting point to work backward from, and provide an "aiming stake" for our investigation.

The next thing I'd do is examine the NTUSER.DAT files for any indication of "proof of life" up to that point. What I'm looking for here is to determine the how of the access; specifically, was the laptop accessed via a means that provided shell- or GUI-based access? 

If I did find "proof of life", I'd definitely check the SAM hive to see if the account is local (not a domain account), and if so, try to see if I could get last login time info, as well as any indication that the account password was changed, etc. However, keep in mind that the SAM hive is limited to local accounts only, and does not provide information about domain accounts.

Depending upon the version/build of Windows (that info was not available in the scenario), I might check the contents of the BAM subkeys, for some indication of process execution or "proof of life" during the time frame of interest.

If there are indications of "proof of life" from a user profile, and it's corroborated with the contents of the BAM subkeys, I'd definitely take a look at profile, and create a timeline of activity.

What we're looking for at this point is:
1. Shell-, GUI-based access, via RDP, or an RMM?
2. Network-, CLI-based access, such as via ssh, Meterpreter, user creds/PSExec/some variant, or a RAT

Shell-based access tends to provide us with a slew of artifacts to examine, such as RecentApps, RecentDocs, UserAssist, shellbags, WordWheelQuery, etc., all of which we can use to develop insight into a threat actor actor, via not just their activity, but the timing thereof, as well. 

If there are indications of shell-based access, we check the Registry to determine if RDP was enabled, or if there were RMM tools installed, but without Windows Event Logs and other other logs, we won't know definitively which means was used to access the laptop. Contrary to what some analysts seem to believe, the TSClients subkeys within the NTUSER.DAT hive do not show systems that have connected to the endpoint, but rather which systems were connected to from the endpoint.

Something else to consider is if the threat actor had shell-based access, and chose to perform their actions via a command prompt, or via Powershell, rather than navigating the system via the Explorer shell and double-clicking files and applications. As we have only the backed up Registry, we wouldn't be able to examine user's console history, nor the Powershell Event Logs.

However, if there are no indications of shell-based access, and since we only have the Registry and no access to any other log files from the endpoint, it's going to likely be impossible to determine the exact means of access. Further, if all of the threat actor's activity was via network-based/type 3 logins to the laptop, such as via Meterpreter, or PSExec, 

It doesn't do any good to parse the Security hive for the Security Event Log audit policy, because we don't have access to the Windows Event Logs. We could attempt to recover them via record parsing of the image, if we had a copy of the image. 

I would not put a priority on persistence; after all, if a threat actor is going to wipe a system, any persistence they create is not going to survive, unless the persistence they added was included in a system-wide or incremental backup, from which the system is restored. While this is possible, it's not something I'd prioritize at this point. I would definitely check autostart locations within the Registry for any indication of something that might look suspicious; for example, something that may be a RAT, etc. However, without more information, we wouldn't be able to definitively determine if (a) if the entry was malicious, and (b) if it was used by the threat actor to access the endpoint. For example, without logs, we have no way of knowing if an item in an autostart location started successfully, or generated an error and crashed each time it was launched. Even with logs, we would have no way of knowing if the threat actor accessed the laptop via an installed RAT.

Something else I would look for would be indications of third-party applications added to the laptop. For example, LANDesk used to have a Software Monitoring module, and it would record information about programs executed on the system, along with how many times it was launched, the last time it was launched, and the user name associated with the last launch. 

Findings
So, where do we stand with our goals? I'd say that at the moment, we're at "inclusive" because we simply do not have enough information to go on. There is no memory dump, no other files collected, no logs, etc., just the backed up Registry. While we won't know definitively how the threat actor was able to access the endpoint, we do know that if access was achieved via some means that allowed for shell-based access, we might have a chance at determining what actions the threat actor took while they were on the system. Of course, the extent to which we'd be able to do that also depends upon other factors, including the version of Windows, the software "load" (i.e., installed applications), actions taken by the threat actor (navigating/running apps via the Explorer shell vs. command prompt/Powershell). It's entirely possible that the threat actor accessed the endpoint via the network, through a means such as Meterpreter, or there was a RAT installed that they used to access the system.

PCAParse

I was doing some research recently regarding what's new to Windows 11, and ran across an interesting artifact, which seems to be referred to as "PCA". I found a couple of interesting references regarding this artifact, such as this one from Sygnia, and this one from AboutDFIR. Taking a look at the samples of files available from the DFIRArtifactMuseum, I wrote a parser for two of the files from the C:\Windows\appcompat\pca folder, converting the time stamps to Unix epoch format and sending the output to STDOUT, in TLN format so that it can be redirected to an events file.

An excerpt from the output from the PcaAppLaunchDic.txt file:

1654524437|PCA|||C:\ProgramData\ProtonVPN\Updates\ProtonVPN_win_v2.0.0.exe
1661428304|PCA|||C:\Windows\SysWOW64\msiexec.exe
1671064714|PCA|||C:\Program Files (x86)\Proton Technologies\ProtonVPN\ProtonVPN.exe
1654780550|PCA|||C:\Program Files\Microsoft OneDrive\22.116.0529.0002\Microsoft.SharePoint.exe

An excerpt from the output from the PcaGeneralDb0.txt file:

1652387261|PCA|||%programfiles%\freefilesync\bin\freefilesync_x64.exe - Abnormal process exit with code 0x2
1652387261|PCA|||%programfiles%\freefilesync\freefilesync.exe - Abnormal process exit with code 0x2
1652391162|PCA|||%USERPROFILE%\appdata\local\githubdesktop\app-2.9.9\resources\app\git\cmd\git.exe - Abnormal process exit with code 0x80
1652391162|PCA|||%USERPROFILE%\appdata\local\githubdesktop\app-2.9.9\resources\app\git\mingw64\bin\git.exe - Abnormal process exit with code 0x80

This output can be redirected to an events file, and included in a timeline, so that we can validate that the artifact does, in fact, illustrate evidence of execution. Incorporating file system information, Prefect and Windows Event Log data (and any other on-disk resources), as well as EDR telemetry (if available) will provide the necessary data to validate program execution.

Addendum, 2024-02-27: Okay, so I've been actively seeking out opportunities to use this parser in my role at my day job, and while I've been doing so, some things have occurred to me. First, there's nothing in either file that points to a specific user, so incorporating this data into an overall timeline that includes WEVTX data and EDR telemetry is going to help not only validate the information from the file themselves, but provide the necessary insight around process execution, depending of course on the availability of information. Fossilization on Windows systems is a wonderful thing, but not everyone takes advantage of it, nor really understands where it's simply not going to be available.

Not only is there no user information, there's also no information regarding process lineage. Still, I firmly believe that once we begin using this information in a consolidated timeline, and begin validating the information, we'll see that it adds yet another clarifying overlay to our timeline, as well as possible pivot points.

A Look At Threat Intel, Through The Lens Of The r77 Rootkit

It's been almost a year, but this Elastic Security write-up on the r77 rootkit popped up on my radar recently, so I thought it would be useful to do a walk-through of how someone with my background would mine open reporting such as this for actionable intel. 

In this case, the r77 rootkit is described as an "open source userland rootkit used to deploy the XMRig crypto miner". I've seen XMRig before (several times), but not deployed alongside a rootkit.

The purpose of a rootkit is to hide stuff. Anyone who was around in the late '90s and early 2000s is familiar with the term "rootkit" and what it means. From the article, "r77’s primary purpose is to hide the presence of other software on a system by hooking important Windows APIs, making it an ideal tool for cybercriminals looking to carry out stealthy attacks. By leveraging the r77 rootkit, the authors of the malicious crypto miner were able to evade detection and continue their campaign undetected."

My point in sharing this definition/explanation is because many of us will see this, or generally accept that a rootkit is involved, and then not think critically about what we're seeing, but more importantly, what we're not seeing. For example, in this case, the Elastic Security write-up

The installer module is described as being written to the Registry, which is a commonly observed technique, especially when it comes to "fileless malware". The article states that the installer "creates a new registry key called $77stager in the HKEY_LOCAL_MACHINE\SOFTWARE hive and writes the stager module to the key." However, the code in the image immediately following that statement (images are not numbered in the article) shows the RegSetValueExW function being called. As such, it's not a Registry key that's created, but a value. 

This may seem pedantic to many, but the distinction is important. Clearly, a different API function is used to create a value than a key; this is because keys and values are completely different structures all together. You cannot write data to a key (i.e., "writes the stager module to the key"), that data has to be associated with a value. Many EDR frameworks, when monitoring or querying Registry keys vs values, use different API or function calls themselves. As such, monitoring for the creation of or simply searching for the $77stager key will miss this rootkit. 

Every. 

Single. 

Time. 

What's interesting is that the article later states:
It then stores the current process ID running the service module as a value in a registry key named either “svc32” or “svc64” under the key HKEY_LOCAL_MACHINE** SOFTWARE$77config\pid**. The svc32/64 key name is based on the system architecture.

Here, it looks as if the correct nomenclature is used.

And then there's threat hunting; that is, if you're going to write PowerShell code to sweep across your infrastructure and look for malware similar to this, the code to look for a key is different than that to look for a value. The same is true for triage or 'dead box' analysis via tools such as RegRipper. Threat hunting with PowerShell across live systems for direct artifacts of this rootkit likely won't get you very far, because...well...it's a rootkit, and the key is hidden through the use of userland API hooking. Elastic's article even points out that data is filtered when using tools such as RegEdit that rely on the hooked API functions. As such, verifying that the rootkit is actually there may require the use of reg.exe of something like FTK Imager to copy the Software hive off of the endpoint, and then parsing that hive file.

Searching for indirect artifacts related to this rootkit, however, is an entirely different matter, and is the reason why indirect artifacts are so valuable. The PowerShell code that is launched is captured in the Windows PowerShell Event Log, in PowerShell/600 event records, as well as in the Microsoft-Windows-PowerShell/Operational Event Log, in Microsoft-Windows-PowerShell/4104 records. This activity/these artifacts allow us to validate that the activity actually occurred, while providing for additional detection opportunities.

Some aspects of the malware not covered in the article include initial access, or how the whole kit is deployed. The technical depth of the article is impressive but not entirely actionable. For example, what aspects (direct artifacts) of the infection are hidden by the rootkit, and what indirect artifacts are 'visible'?

Lists of Images

There're a lot of discussions out there on social media regarding how to get started or improve yourself or set yourself apart in cybersecurity, and lot of the advice centers around doing things yourself; setting up a home lab, using various tools, etc. A lot of this advice is also centered around pen testing and red teaming; while it's not discussed as much, there is a lot you can do if you're interested in digital forensics, and the cool thing is that you don't have to "set up a home lab" to fully engage in most of it. All you need is a way to download the images and any tools you want, to a system to do the work on.

Fortunately, there are a number of sites where you can find these images, to practice doing analysis, or to engage in tool testing. Also, many of these sites are on lists...I've developed a list of my own, for example. Amongst the various available lists, there's most assuredly going to be duplication, so just be aware of that going in. That being said, let's take a look at some of the lists...

The folks at ArsenalRecon posted a list of publicly available images, and Brett Shavers followed up by sharing a DFIR Training link of "test" images.

Dr. Ali Hadi has a list of challenge images (he graciously allowed me to use one of them in Investigating Windows Systems), as well as a blog with some very valuable posts.

While "test" and CTF images are a great way to practice using various tools, and even developing new techniques, they lack the fossilization of user and system activity seen in real-world images. There's not a great deal that can be done about that; suffice to say that this is just something that folks need to be aware of when working with the images. It's also possible within the limited scope of the "incident" to develop not just threat intel, but also discern insights into the threat actor; that is, to observe human behavior rendered from digital forensics.

Many of the CTF images will be accompanied by a list of questions that need to be answered (i.e., the flags), few of which are ever actually asked for by customers, IRL. I've seen CTFs with 37 or even 51 questions, and across 25 yrs of DFIR experience, I've never had customers ask more than 5 questions, with one or two of them being duplicates. 

The point is that CTF images are a great place to start, particularly if you take more "real world" approach to the situation and define your own goals. "Is this system infected with malware? If so, how did this happen, what did the malware do, and was any data stolen as a result?"

It's also a great idea to do more than just answer the questions, but to also go beyond. For example, in the write up of your findings, did you consider control efficacy? What controls were in place, did they work or not, and what controls would you recommend?

I once worked a case where the endpoint was infected due to a phishing email and the customer responded that this couldn't be the case, because they had a package specifically designed to address such things on their email gateway. However, the phishing email had gotten on the system because the user accessed their personal email via a browser, bypassing the email gateway all together.

Can you recommend controls or system configuration changes that may have inhibited or even obviated the attack/infection? What controls either on the network, or on the endpoint itself may have had an impact on the attack?

What about detections? How would you detect this malware or activity on future cases? Can you write a Yara or Sigma rule that would address the attack at any point? Is there one data source that proved to be more valuable than others, something you can clearly delineate as, "...if you see this, then the attack succeeded..."?

What can you tell about the "attacker", as a person? Was this a human operated attack, and if so, what insights can you develop about the attacker from your DF analysis? Hours of operations, capabilities, situational awareness are all aspects you can look at. Were there failed attempts to log in, run commands, or install applications, or did the attacker seem to be prepared and good to go when they got on the box? What insights can be rendered from your analysis, and are there any gaps that would shed more light on what was happening?

Finally, set up a Github site or blog, and share your experience and findings. Write up a blog post, a series of blog posts, or upload a document to a Github repo, and invite others to review, and ask questions, make comments, etc.