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.

Asking
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.