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.