Monday, August 28, 2023
Sunday, August 27, 2023
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".
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.
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.
Tuesday, August 22, 2023
Okay, so, what? Who cares? Well, here's the change, from @HostileSpectrum:
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?
Sunday, August 13, 2023
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.
Saturday, August 12, 2023
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...
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:
"data": "2019-02-15 04:59:23"
"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.
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:
$str1 = "onedrive" nocase
$str2 = "vmware" nocase
$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:
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.
Monday, August 07, 2023
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.
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?