In DFIR and "threat intel" analysis, very often individual data points are dismissed out of hand, as they are thought to be easily mutable.  We see it all the time, don't we? We find a data point, and instead of just adding it to our picture of the incident, instead, we ask, "Hey, what about this...?".  Very often, we hear in response, "...hackers change that all the time...", so we drop it.

Why do we do this?  Why do we not include "easily mutable" artifacts in our analysis?

A common example of this is the PE compile time, a time stamp value added to an executable file during the compilation process.  I'm not an expert in compilers or linkers, but this time stamp value is understood throughout the DFIR community to be easily mutable; that is, it doesn't "cost" an adversary much to change this value.  Many of us have seen where the PE compile time value, when converted, indicates that file was compiled in 1980, or possibly even a date in the future.  This value is thought to be easily mutable precisely because many of us have either seen it changed, or have actually changed it ourselves.  A consequence of this is that when someone brings up, "...hey, this time stamp value says...", we may be immediately met with the value itself being dismissed out of hand.

However, there may be considerable value in including these values in our corpus of viable, relevant data points. What I mean is, just because a value is understood to be easily mutable, what if it wasn't changed?  Why are we not including these values in our analysis because they could be changed, without checking to see if they had been changed?

Consider the FireEye blog post from Nov 2018 regarding the APT29/Cozy Bear phishing campaign; table 1 of the article illustrates an "operational timeline", which is a great idea.  The fourth row in the table illustrates the time at which the LNK file is thought to have been weaponized; this is a time stamp stored in a shell item, as an MS-DOS date/time value.  The specific value is the last modification time of the "system32" folder, and if you know enough about the format of LNK files, it's not hard at all to modify this time value, so it could be considered "easily mutable".  For example, open the file in binary mode, go to the location/offset with in the file, and overwrite the 16-bit value with 0's.  Boom.  You don't even have to mess with issues of endianness, just write 0's and be done with it.

However, in this case, the FireEye folks included the value in their corpus, and found that it had significant value.

Something else you'll hear very often is, "...yeah, we see that all the time...".  Okay, great...so why dismiss it?  Sure, you see it all the time, but in what context?  When you say that you "see it all the time", does that mean you're seeing the same data points across disparate campaigns?

Let's consider Windows shortcut/LNK files again.  Let's say we retrieve the machine ID from the LNK file metadata, and we see "user-pc" again, and again, and again.  We also see the same node ID (or "MAC address") and the same volume serial number across different campaigns.  Are these campaigns all related to the same threat actor group, or different adversaries?  Either way, this would tell us something, wouldn't it?

The same can be said for other file and document metadata, including that found in phishing campaign lure documents, particularly the OLE format documents.  You see the same metadata across different campaigns?  Great.  Are the campaigns attributed to the same actors?

What about the embedded macros?  Are they obfuscated?  I've seen macros with no obfuscation at all, and I've seen macros with four or five levels of obfuscation, each level being completely different (i.e., base64 encoding, character encoding, differences in string concatenation, etc.).

All of these can be useful pieces of information to build out the threat intel picture.  Threat intel analysts need to know what's available, so that they can ask for it if it's not present, and then utilize it and track it.  DFIR analysts need to understand that there's more to answering the IR questions, and a small amount of additional work can yield significant dividends down the road, particularly when shared with analysts from other disciplines.

I recently tweeted that, as far as I'm aware, Nuix's Workstation/Investigator product is the only commercial product that incorporates RegRipper, or RegRipper-like functionality.

Brian responded to the tweet that both OSForensics and OpenText include the capability as well. The OSForensics page states that the guide was written using RegRipper version 2.02, from May, 2011, making it really quite old. For OpenText, the page states that the EnScript for launching RegRipper had been downloaded 4955 times, but is no longer supported.  Also, the reference to RegRipper, at the old Wordpress site, tells us that it's pretty dated.

As such, that leaves us right were we started...Nuix Workstation is the only commercial product that incorporates the use of RegRipper, or some similar functionality.  Here's the fact sheet that talks about the extension, and here's where you can get the extension itself, for free.  Finally, here's a Nuix blog post that describes not only the RegRipper extension, but the Yara extension (also free), as well.

Okay, full disclosure time...while I was employed at Nuix, I helped direct the creation of the RegRipper extension, as well as updating the Yara extension.  I didn't do the programming...that was something provided by Daniel Berry's team.  The "two Jasons" did a fantastic job of taking my guidance and turning it into reality.  Shoutz and mad props to the Juicy Dragon and his partner in crime, and their boss (Dan).

The RegRipper extension looks at each Windows evidence item, and "knows" where to go to get the Registry hives.  This includes knowing, based on the version of Windows, where the NTUSER.DAT and USRCLASS.DAT files are located. It will also get the AmCache.hve file (if it's in that version of Windows), the NTUSER.DAT hives in the Service Profiles subfolders, as well as the Default hive file within the system32\config folder.  Automatically.

And it will run the appropriate RegRipper profiles against the hives. Automatically.

And it will incorporate the output from RegRipper, based on the evidence item and file parsed, right back into the Nuix case as a separate evidence item.  Automatically.

Let's say you have multiple images of Windows systems, all different versions.  Run the RegRipper extension against the case, and then run your keyword searches.  This can be extremely critical, as there is data within the Registry that is ROT-13 encoded, as well as ASCII strings that are encoded as hexadecimal character streams that various RegRipper plugins will decode, making the data available to be included in your searches.

The Yara extension is equally as powerful.  You select the path you want scanned, whether you want descendants (yes, please!) and the rule file(s) you want included, and let it go.  All of the findings are included as tagged items directly back into your case.

Want to give it a shot?  Go here, and download the image from challenge #1, the web server case.  Add the image file as an evidence item to a Nuix case, and then run the RegRipper extension.  Then, use the Yara extension to run Yara rule files that look for web shells across the web server folder and all descendants.  In this case, the web server folder is not C:\inetpub.

RegRipper was released almost 11 yrs ago. I've been told time and time again that a lot of people "use" it.  I have no stats, nor any real insight into this, but what it means to me is that a lot of people download it, and run it "as is" without getting the full benefit from the tool.

I guess I'm really amazed that in all this time, there hasn't been a concerted effort to incorporate RegRipper, or a RegRipper-like capability, directly into a commercial tool.

OS/2Warp running in VirtualBoxWhen I started graduate school in June 1994, I showed up having used Win3.1 and AOL for dial-up.  While in grad school, I began using Sparc systems running SunOS (web browser was Netscape), which is what was available in the curriculum I was in.  I also got to interact and engage with a lot of other now-historical stuff, and over time, I've had passing feelings of sentimentality and nostalgia.

After I arrived in CA, I was shown PPP/SLIP dial-up for Windows systems, and was fascinated with the configuration and use, mostly because now, I was one of the cool kids.  For a while, I dabbled with the idea of a dual degree (EE/CS, never committed to it) and came in pretty close contact with folks from the CS department.  As it turned out, there were more than a few folks in the CS department who were interested in OS/2, including one of the professors who had a program that would sort and optimize the boot-up sequence for OS/2 so that it would load and run faster.

Also, it didn't hurt that I attended grad school was not far from Silicon Valley, the center of the universe for tech coolness at the time.  In fact, the EE curriculum had a class each summer called "hot chips" where we studied the latest in microprocessor technology, and corresponded with the "Hot Chips" conference in San Jose.  The class was taught by Prof. F. Terman, the son of the other Fred Terman.

While I was in grad school, I was eventually introduced to OS/2.  I purchased a copy of OS/2 2.1 at Frye's Electronics (in SunnyVale, next to Weird Stuff), specifically because the box came with a sticker/coupon for $15 off of OS/2 Warp 3.0.  I enjoyed working with OS/2 at the time; I could dial into my local ISP (Garlique.com at the time), connect to the school systems, and run multiple instances of MatLab programs I'd written as part of a course.  I could then either connect later and collect the output, or simply have it available when I arrived at the school. 

I had no idea at the time, but for the first four months or so that I was at NPS, I walked by Gary Kildall's office almost every day.  I never did get to see CP/M in action, but anyone who's ever used MS-DOS has interacted with a shadow of what CP/M once was and was intended to be.

While I was in grad school, I had two courses in assembly language programming, both based on the Motorola 68000, the microprocessor used in Amiga systems.  I never owned an Amiga as a kid, but while I was in grad school, there was someone in a nearby town who ran a BBS based on Amiga, and after grad school, I did see an Amiga system at a church yard sale. 

While I was in the Monterey/Carmel area of California, I also became peripherally aware of such oddities of the tech world as BeOS and NeXT.

Looking back on all this, I was active duty military at the time, and could not have afforded to pull together the various bits and pieces to lay the foundation for a future museum.  Also, for anyone familiar with the system the military uses to move service members between duty stations, this likely would not have survived (ah, the stories...).  However, thanks to virtualization systems such as VirtualBox, you can now pull together a museum-on-a-hard-drive, by either downloading the virtual images, or collecting the necessary materials and installing them yourself.  As you can see from the image in this post, I found an OS/2Warp VB image available online.  I don't do much with it, but I do remember that the web browser was the first one I encountered that would let you select an image in a web page and drag it to your desktop.  At the time, that was some pretty cool stuff!

Resources (links to instructions, not all include images or ISO files)
VirtualBox BeOS R5
VirtualBox Haiku (inspired by BeOS) images (there's also a Plan 9 image...just sayin'...)
NeXT in VirtualBox: NeXTSTEP, stuffjasondoes
Virtually Fun - CPM/86
VirtualBox Amiga