Monday, April 09, 2018

Mommy, where do plugins come from?

This is one of those questions kids have been asking their parents throughout history, and in more recent times, those parents may have resorted to a book.  Just sayin'.

Well, they come from three general sources, really, none of which involves a stork or a cabbage leaf.

Recently, there were a couple of requests for functionality to be added to RegRipper.  One was for the ability to automatically update the default profiles in RegRipper.  I was speaking with someone recently, and demonstrating the RegRipper extension that had been added to Nuix's Workbench product.  As part of the discussion, I explained that I do not update the default profiles when I create new plugins (something I've mentioned a number of times in this blog), as I don't want to overwrite any customized profiles folks have made to their installations.  This person then asked, "...can you add the ability to update the default profiles automatically?"  I thought for a minute and realized that rip already has about 2/3 of the code I would need to do exactly that.  So, I opened an editor, used that code to populate a hash of arrays, and then wrote the lists of plugin names, each to their own file.  Boom.  Done.

The other "feature" was for a new plugin to be created.  Someone I know reached out to me to say that they'd found value in a particular Registry key/value during an investigation, and that it might make a good plugin to retrieve the value in question.  This person didn't initially provide any test data, and when they did, it was an exported .reg file; I know it sounds easy enough to handle, but this adds several additional steps (i.e., open a VM, transfer the .reg file to it, import the .reg file into a hive, then shut down the VM, open the .vmdk file in FTK Imager, and extract the hive...), as well as a level of uncertainty (are there variations based on the version of Windows, etc.), to the testing process.

Not having data to test on makes it difficult to write a plugin, as well as test the plugin before releasing it. 

Intel from IR engagements
So, where do other plugins come from?  Similar to the request for the new plugin, sometimes I'll find something during an examination that might make a good plugin.  For example, during an examination, we found a Registry value of interest, and as such, I added the key LastWrite times from the user's NTUSER.DAT hive to a timeline, using regtime.exe.  For context, I did the same for the Software hive from that system, and as an aside, found some interesting Registry keys/values associated with the installed AV product.  In this instance, the keys and values were related to the responder's activities, but writing a plugin (or two) to extract data from the Registry keys/values would facilitate research activities, and as such, make it easier to determine their nature and context.

Interestingly enough, this is how RegRipper started, and was the source of most of the plugins I've written in the past decade.

Online research
Another source of plugins is OSINT, and online research.

For example, FireEye recently released their 2018 M-Trends report, and page 23 includes a Registry key that an attacker modified to hide their activity, by adding a folder to the AV exclusion list.  If I had data on which to test a plugin, I'd write one; online research indicates that there's a key within the path that may vary, and as such, I'd need a bit better understanding of the path in order to write a useful plugin. 

Oddly enough, I don't think I have ever received a request for a plugin based on something published online, via a blog post, or an annual report.  I don't see (or know) everything, and it's likely that I may simply have not seen that post or report. 

Another analysis aspect that RegRipper can be used for is the check or verify system configuration.  For example, see this Microsoft documentation regarding making remote calls to the local SAM database; including a plugin to extract these values may help an analyst narrow down the original attack vector, or at least identify possibilities.

Friday, April 06, 2018


Based on some feedback I received recently, I updated RegRipper's (and the corresponding .exe, of course) to include the "-uP" switch.

What this switch does is run through all of the plugins, determine to which hives they apply, and the automatically update the default profiles with those plugins.  As I've stated in the past, when I create a new plugin, I do not update that appropriate profile...I just add the plugin to the repository.  If you want to run all of the plugins available for the NTUSER.DAT hive against all NTUSER.DAT hives you get, run rip.exe with the "-uP" switch, and the profile named "ntuser" will include all of those plugins, EXCEPT those with "_tln" in their name.

This switch will create or overwrite (if they already exist) profiles named for the hives (lower case, without ".dat" at the end).  This does NOT affect any custom profiles you've created, unless they use the same names.

I recently received a request from someone to create a new plugin to retrieve the IE Search Scopes.  The '' plugin was added to the repository today, along with the updated mentioned above.

Something I wanted to point out about both of these updates...they started with someone asking.  That's it.  I don't use RegRipper's profiles for the analysis work I do, but I know that others do.  If you use the GUI, then that's pretty much what you use profiles, rather than individual plugins.  The profiles are also valuable when using the RegRipper extension added to the Nuix Workbench product (fact sheet); the extension relies on a mapping of the hive type to the RegRipper profile.  You can edit/update the profiles themselves, or you can create your own custom profiles and edit the mapping file (JSON, just open it in Notepad...).  I showed the extension to someone, and they asked, "hey, can you create a tool that automatically updates the default profiles?"

The same is true with the plugin...someone said, hey, there's this thing that I found useful during an investigation, it might make a good plugin.  Boom.  Done. 

If you've been thinking about something along these lines, or trying to find a way to do it manually, maybe there's a way to do it in an automated fashion.  Sometimes, the smallest interaction can lead to a big result.  Don't isolate yourself on your own island.