RegRipper Updates

I've made some updates to RegRipper that I wanted to let everyone know about, in case you want to take advantage of them.

Version 2.8 is a minor update, and includes an additional function/subroutine that is available to the plugins: alertMsg().  In short, the tools (RegRipper, rip) provide the functionality, which is then used by the plugins themselves.  The updates to the tools simply provide the functionality; several of the plugins have been updated to make use of that functionality.  If you'd like to use this functionality, then you want to download the files rrv2.8.zip and plugins20130429.zip.

How is this alertMsg() function useful?  Well, consider Corey's recent post regarding the soft_run.pl and user_run.pl plugins; in the post, he illustrates several values of interest, that point (in his case) to malware.

As such, I added two checks to both of the plugins; one checks for "Temp" or "temp" in the path found in the value data (this would catch "Local Settings\Temp", "Temporary Internet Files", and "Templates"), and the other checks to see if the path in the value data ends in ".com" or ".bat". 

Other updated plugins include (but are not limited to):

• appinitdlls - generate an alert if the value is not blank
• appcompatcache - generate an alert for any path that includes "[Tt]emp"
• attachmgr - generates alerts per Corey's blog post (ref: KB883260)
• imagefile - generate an alert if a Debugger value is found
• user_run, soft_run - alert on paths that contain "[Tt]emp"
• winlogon, winlogon_u - added several alerts

What this means is that for RegRipper (the GUI), any alerts generated by the plugins will be added to the end of the report file, and for rip.exe, any alerts will appear last in the output.  The purpose of this is to allow analysts to focus on what might be most important to them.  Many of the plugins are meant to provide information for the analyst to review and use, and therefore will not generate alerts (nor need to).  However, other plugins (such as those described in this post) include specific items that can be checked, and if found, an alert can be generated.  This does not mean that the output of the plugin will not be generated; in fact, quite the opposite occurs.  The alerts are generated in addition to the output of the plugins.

So a big question is going to be, where do the alerts come from? The answer is pretty simple...they come from stuff I, and others (specifically, Corey Harrell), have seen.  For example, one of the checks that occurs in the soft_run.pl and user_run.pl plugins is that every value data (i.e., path) is checked to see if it contains "[Tt]emp"; an alert will be generated if it contains "Templates", "Local Settings\Temp", or "Temporary Internet Files", for example.  This is important because (a) I've seen applications set to run from those paths, and (b) you generally don't want that sort of thing to happen, particularly from "Temporary Internet Files".

Now, there are two things to keep in mind...the first is that not all plugins will necessarily generate alerts.  Some plugins, such as networklist.pl, do not necessarily provide information that should be alerted on.  The output of this plugin is mostly for informational purposes, and you should check it if you're looking for something specific.  Other plugins do provide information that can be alerted on; for example, in winlogon.pl, one alert will be generated if the TaskMan value is found, and another will be generated if the Userinit value is found to have more than simply what is expected.  Someplace that this might be useful...look for alerts from the winlogon.pl plugin, which would detect Ramnit.

The second is that of the plugins that do generate alerts, they will only generate those alerts that are included in (i.e., coded into) the plugins.  You can see what is generating an alert by locating any instance of ::alertMsg() in the plugin, and taking a look at the code around it.  If a plugin isn't alerting on something that you want, it may be because that alert hasn't shared that with someone...so just send me an email and I'll see what I can do (note: I may need sample data in order to test it).

Several of the plugins that were updated to include this ::alertMsg() functionality have also been converted to TLN output so that the alerts can be included in a timeline.  My hope is that this will bring a considerable modicum of intelligence to timeline analysis, by including things that would be of interest directly in the timeline.  In many cases, the location of the alert in the timeline may be imprecise...the time stamp value is based on the LastWrite time of the key; however, my hope is that seeing an event source of "ALERT" in the timeline (which you search on using Notepad++, etc.) will raise awareness of areas that should be checked by bringing them to the attention of the analyst.

A caveat...if you're using ripXP (is anyone using that??), then you want to use the plugins in the archive for 18 April 2013.  I'll leave that archive up and available, but I will not be updating ripXP with the alertMsg() functionality, so you'll need to use the appropriate plugins.  This is easy to do, simply create a separate folder for ripXP.