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.