The findexes.pl plugin for RegRipper is a plugin that I wrote as a result of another analyst sharing his experiences on an engagement with me. The analyst told me that he'd found some unusual references to Registry keys in malware code, which led him to determine that executable code was being stored in binary value data within the Registry.
This plugin can be run against any hive file. What it does is traverse through all of the keys (so for larger hives, it can take a little bit of time to complete), looking for values with binary data. When it finds binary data, it checks to see if that data includes "MZ". Note that it does not look in a specific location, nor at offset 0...it uses a grep() statement to see if the data includes "MZ" at all.
When the plugin completes, you get a couple of pieces of information. One is the count of values with binary data, along with the count of binary data with "MZ". If there were any values found to contain "MZ", the key path, key LastWrite time, and value name are listed.
One System hive I ran the code against found 22660 binary values but none that contained "MZ". A Software hive I ran the code against found 23190 binary values, one of which contained "MZ", and I got the key path and other data for that value.
Key: Microsoft\SystemCertificates\Disallowed\Certificates\471C949A8143DB5AD5CDF1C972864A2504FA23C9 LastWrite time: Mon Mar 28 21:26:31 2011
Value: Blob Length: 1751 bytes
Number of values w/ binary data types: 23190
Number of values w/ MZ in binary data: 1
It's pretty trivial to validate the information, in general, found by this plugin. One way to do is to simply navigate to the key(s) in a viewer, and then look at the data. Another is to add code to the plugin to dump the data out in a hex editor style view.
Now this plugin doesn't indicate that what it finds is a persistence mechanism; rather, it's used for data storage, so you might consider running it across any and all hives, including USRCLASS.DAT. The process in which I tend to use this plugin is that I'll start by creating a timeline and if I see some unusual activity in the Registry during the time window during which the system seemed to be infected (i.e., Registry and file system data, *.idx metadata, etc.). Given that the LastWrite time is only indicative of a change occurring to a Registry key, I might opt to run the plugin against hives from VSCs, rather than those within the system32\config folder, instead.
Overall, this plugin can be very useful. The plugin can be added to profiles for every hive, or can be used for pivot point analysis when examining a timeline.
You mentioned:
ReplyDelete"Given that the LastWrite time is only indicative of a change occurring to a Registry key, I might opt to run the plugin against hives from VSCs, rather than those within the system32\config folder, instead."
Question:
How often do you normally use the technique of gathering the hives from the VSCs? What, specifically, would trigger you to take a look at those in addition to the system32\config hives?
Thanks!!
How often do you normally use the technique of gathering the hives from the VSCs?
ReplyDeleteWell, to be clear, I'm not gathering the hives from the VSCs...I'm access the hives directly within the VSCs.
To answer your question, I do check for available VSCs, but about half of my exams over the past year have had VSCs disabled for one reason or another.
What, specifically, would trigger you to take a look at those in addition to the system32\config hives?
A number of things. One example is, if an infection occurred at a time between when two VSCs were created.
Also, don't forget the hives in the RegBack folder.