I received an email from randomaccess last night, and got a look at it this morning.  In the email, he pointed out there there had been some changes to the SAM Registry hive as of Windows 8/8.1, apparently due to the ability to log into the system using an MSDN Live account.  Several new values seem to be added to the user RID key, specifically, GivenName, SurName, and InternetUserName.  He provided a sample SAM hive and an explanation of what he was looking for, and I was able to update the samparse.pl plugin, send him a copy, and update the GitHub repository, all in pretty short order.

This is a great example of what I've said time and again since I released RegRipper; if you need a plugin and don't feel that you can create or update one yourself, all you need to do is provide a concise description of what you're looking for, and some sample data.  It's that easy, and I've always been able to turn a new or updated plugin around pretty quickly.

Now, I know some folks are hesitant to share data/hive files with me, for fear of exposure.  I know people are afraid to share information for fear it will end up in my blog, and I have actually had someone tell me recently that they were hesitant to share something with me because they thought I would take the information and write a new book around it.  Folks, if you take a close look at the blog and books, I don't expose data in either one.  I've received hive files from two members of law enforcement, one of whom shared hive files from a Windows phone.  That's right...law enforcement.  And I haven't exposed, nor have I shared any of that data.  Just sayin'...

Interestingly enough, randomaccess also asked in his email if I'd "updated the samparse plugin for the latest book", which was kind of an interesting question.  The short answer is "no", I don't generally update plugins only when I'm releasing a new book.  If you've followed this blog, you're aware that plugins get created or updated all the time, without a new book being released.  The more extensive response is that I simply haven't seen a SAM hive myself that contains the information in question, nor has anyone provided a hive that I could used to update and test the plugin, until now.

And yes, the second edition of Windows Registry Forensics is due to hit the shelves in April, 2016.

The Winlogon plugin is a pretty comprehensive plugin, in that since the RegRipper consolidation release, several plugins have been retired and their functionality incorporated into this one plugin.

The Winlogon plugin is a valuable resource when it comes to determining autostart information for the system.  For example, the UserInit and Shell values point to the shell that is launched when a user logs in.  From here:

The Winlogon key controls actions that occur when you log on to a computer running Windows 7. Most of these actions are under the control of the operating system, but you can also add custom actions here. The “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit” and “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell” subkeys can automatically launch programs. 

 MS KB 555648 addresses an issue where either the Shell or Userinit values have been modified.

The Winlogon plugin extracts values and data from beneath the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon key, as well as it's accompanying Wow6432Node cousin on 64-bit Windows systems, and it also collects information from several subkeys, as well.

This Microsoft page provides additional information about some of the values that appear beneath this key.  Another way that a value beneath this key can be used to subvert the system is to add the TaskMan value, and point to malicious software.

Notify
This subkey maintains a running list of functionality made available to Windows systems via notification packages.  In short, a "package" (DLL) can receive notifications from Windows when certain events occur.  When these events occur, Windows will look for the package and launch the handler for that specific event.  For example, you can have specific functions run automatically when a user logs on, locks the console, when a smartcard is plugged into the system, etc.

As with other functionality on Windows system, this also provides a great mechanism for malware (see this Cutwail example) persistence.

Special Accounts
One of the subkeys that can exist beneath the Winlogon key is the "SpecialAccounts\UserList" subkey.  The values beneath this key, and each value's accompanying data, determines whether or not the specific account appears on the Welcome screen.  Very often, this information is used to for legitimate purposes, so that the screen isn't cluttered with accounts that are not used for logging into the system at the console.  However, this functionality can be, and has been, used for malicious purposes.  I've seen this in the wild, most often when an intruder has accessed an infrastructure via RDP, and creates accounts on systems that they can use to log in; hiding the user account from the Welcome screen prevents legitimate users from seeing anything suspicious when the system is rebooted.  In one instance, I saw this being used, but the "SpecialAccounts" key had been misspelled, so the functionality was not enabled.

The Winlogon plugin encapsulates data from several plugins, which led me to retire those other plugins.  For example, I added the checks from the taskman.pl, notify.pl, and specaccts.pl plugins to the winlogon.pl plugin, and retired those other plugins.  All of this will appear in the history file associated with the next roll-out of the plugin archive.  The output of the winlogon.pl plugin also includes analysis notes, so that the analyst has information right there in the report with respect to what they should look for, and what might be suspicious.

Resources
Winlogon\Nofity entries
MS KB 102972: Explains many of the Winlogon values

As is the case with many of the RegRipper plugins, the specaccts.pl plugin initially came about because of something I read about, and after running it, it actually found what I was looking for in the wild.

Beneath the Winlogon key (specifically, HKLM\Software\Microsoft\Windows\CurrentVersion\Winlogon), there may be a subkey path of "SpecialAccounts\UserList".  The values listed beneath the UserList key would be user account names, and if the data associated with a value is "0", then that account will not appear on the Welcome screen (any value greater than 0 allows the account to appear on the Welcome logon screen).

I've seen this used twice in the wild...once, it worked, and the second time, the bad guy had misspelled "SpecialAccounts", and as such, the functionality that they were trying to achieve wasn't realized.  Sometimes, a little attention to detail can go a long way.

There is malware that uses these Registry keys to keep new user accounts hidden from view on a live system, such as TrojanSpy:Win32/Ursnif , Trojan:Win32/Starter, and EyeStye.  As such, this plugin can provide indicators of a malware infection, an intrusion, or of malicious user intent on the system.  However, keep in mind, that this functionality can also be used for legitimate purposes, such as hiding an Administrator or HelpDesk account from view on the Welcome screen.

As of this writing, Corey Harrell and I are finishing updates to a number of plugins, and looking at merging plugins where appropriate.  As the information that we're looking for with the specaccts.pl plugin is beneath the Winlogon key, I've rolled the functionality into the winlogon.pl plugin, and retired the specaccts.pl plugin.

So, the functionality isn't going away...rather, it's going to be incorporated into an existing plugin.

If you've downloaded the new RegRipper plugins archive, you may have noticed several plugins whose names end in "_tln.pl".  These plugins specifically output their collected information in the five-field timeline (TLN) events file format that I use for creating timelines.

Many folks using the RegRipper tools may not be aware that you can use rip.exe to determine information about the plugins that you have currently have available.  For example, the following command will allow you to see all the plugins that you have, listed in a tabular format:

rip -l

This next command will allow you to see all of the plugins you have, listed in CSV format:

rip -l -c

This command will let you see all of the plugins that end in "*_tln", in CSV format:

rip -l -c | find "_tln"

Now that we have a list of the plugins that provide TLN output, we can easily include the output of the plugin in our timeline events file by using the following command:

rip -r path -p plugin  -u user -s server >> events.txt

An example of how this can be useful is in adding the UserAssist data for a specific user to the timeline events file...you can do that using the following command:

rip -r path -p userassist_tln -u user -s server >> events.txt

Very easy, very straightforward, and the use of these plugins can provide us with a good deal of granularity in our timeline.

Something that's very important to understand about the TLN plugins is that, in most cases, they will not display the same information as their accompanying plugin without "_tln" in the name.  In many cases, the information maintained in the keys and values extracted via the plugins is stored in a "most recently used" or "MRU" format, and as such, the LastWrite time of the key is associated with the most recent entry.  An example of this is the shellbags_tln.pl plugin...running this one side-by-side with the shellbags.pl plugin won't provide you with the same information, nor the same number of lines in the output.  However, this is by design...shellbag data is one of those "MRU" sources within the Registry.  One exception to this is the output of the userassist_tln.pl plugin; the time stamp data extracted by this plugin is stored in the binary content of the value data.

Typing the command to list the *_tln plugins will illustrate that most of the plugins appear to be oriented toward the NTUSER.DAT and Software hives.  The shellbags_tln.pl plugin was written to run against the USRCLASS.DAT hive, and lists its output based on the key LastWrite time or "MRU Time"; it does not list information in TLN format based on the created, last accessed or last modified times extracted from the shell items.  The samparse_tln.pl plugin will list information in TLN format based on various time stamps associated with each user account.  Also, with this plugin, you don't need to add the "-u" switch, as the user information is embedded within the hive file itself.

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.

Shortly after announcing the RegRipper consolidation, Corey hit me with a great idea...why not create a series of posts to spotlight a particular plugin, explain what it does, how it can be used, etc.  I thought that this was a great idea, and told him that I would join in, so you can expect to see posts from both of us every now and again, in which we discuss a specific plugin.  Once these posts start to appear, I will add them as links to a page on the RegRipper Wiki.  If anyone else decides to write a similar post, please send me the link and I'll add it to the page.

The first plugin that I thought I'd take a look at is emdmgmt.pl. "EMD" apparently stands for "external memory device", which was the working name of ReadyBoost while it was being developed.  When you connect a device to a Vista+ system, the ReadyBoost service checks the device to determine its characteristics and stores this information beneath the following key:

SOFTWARE\Microsoft\Windows NT\CurrentVersion\Emdmgmt

This key gets populated with subkeys that refer not just to thumb drives connected to the system, but also external drives, sometimes referred to as "drive enclosures" (which, of course, has to have a drive in it).  It appears that ReadyBoost performs some sort of "check" of the device in order to determine it's capabilities and see if it's suitable for use.

This plugin is useful for two primary reasons.  First, it's a great way to verify that certain types of devices (thumb drives, external drives) had been connected to the system at one point.  This can be validated against other sources of information (System hive, etc.).

The other useful aspect of information stored in this key applies specifically to thumb drives.  In particular, the subkey that applies to a thumb drive contains the device class identifier, the device serial number, the volume serial number, and possibly the volume name (if the mounted volume has a name).  For example,

Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15
  LastWrite: Sun Jul 17 12:13:25 2011 Z
  SN: 0C90195032E36889&0
  Vol Name: TEST
  VSN: 6403-CD1C

This is clearly a Best Buy Geek Squad U3 thumb drive that I connected to my system.  That I really like about this is the volume serial number that's listed in the output.  This is translated from the information maintained at the very end of the key name.  I've used this information to correlate to VSNs stored in Windows shortcut/LNK streams (shortcuts in the user's Recent folder, Jump Lists), allowing me to tie the various artifacts together in order to demonstrate not only that a particular user accessed the thumb drive, but to also demonstrate what the file system on that device looked like at the time that the user accessed it.  I can then further augment this information with the output of the comdlg32.pl and shellbags.pl plugins.

Power of Open Source
I've mentioned this before, and it bears repeating...open source is a very powerful thing.

I recently posted about the AppCompatCache finding that the Mandiant folks shared, and in looking at it, I found that some tools are able to handle 'big data', and some aren't.  Specifically, Yaru from TZWorks had no trouble at all letting me view the data, but the Parse::Win32Registry Perl module (the basis for RegRipper) didn't.  I did some troubleshooting of the module (thanks goes to the author, James Macfarlane, for providing some useful debugging features) and found that it doesn't address 'big data' at all.  I contacted the author, and he said that when developing the module, he hadn't had any issues, nor instances of 'big data'.  If you look around on the Internet, you'll see that the first versions of the module were uploaded to CPAN something in 2007, so that wouldn't be too unexpected.

Knowing a little Perl, I was able to locate where within the module the value data is populated from a binary hive file, and I wrote an update to the specific file.  I've been doing a bit of testing, and below is some of the sample output:


The code also works equally well with 32-bit Windows XP hives, as well.  So, it appears that the update is working well, and I've provided the fix to the module author for inclusion in any updates.

Again...this isn't about a plugin, or RegRipper.   It's about how powerful open source can be.  Due to the information that Mandiant released regarding this Registry value, it was a simple matter to determine which tools worked in addressing this, and which didn't.  For those that didn't, and were open source, a fix or update was pretty easy to develop.  Another example of this would include updates to some of the current RegRipper plugins that allow for parsing of MAC addresses.  Open source is a great way to fill the gap in capability, going from none to something fully functional in a relatively short amount of time.

I've uploaded a copy of the patch to the module, along with a readme file with instructions for how to install it, here.  You can also find it at the RegRipper site that Brett set up, and the module author has also addressed the issue in the code, and will be providing it in the next update, so that the module can be updated much easier...if you're using ActiveState Perl, it would simply be a matter of typing the following command:


Alternatively, you could download the module (as a gzipped tarball) from CPAN (when it's available).

Andreas has posted a couple of new Volatility plugins recently that look really interesting, in that he provided the capability to link file objects to processes, as well as scanning a memory dump for driver objects.

Jason Koppe, whom I met at DFRWS (Jason, Cory and I "helped" close out the tab at the reception at the Wharf Rat on Monday evening...you're welcome, Brian! ;-) ) has written a RegRipper plugin generator! Check it out!

Basically, what Jason has done is come up with a good overall plan to encapsulate my vision for the plugins themselves. I've found it difficult to really come up with a discernible pattern, due to the variations in the plugins...all start at a root key, and then some look for subkeys, some for specific values, some for all values, etc. Look at the UserAssist key plugin (no, seriously...open it up in an editor)...not only are the values extracted, but they need to be ROT-13 "decrypted". The USBStor2 plugin parses and correlates information from multiple keys.

Regardless of the eccentricities of my brain and perspective, Jason's done a great job of putting together a basic RegRipper plugin generator. While there are a number of dependencies to the GTk+ UI code that James used for regview.pl, it looks like Jason has made yet another excellent argument for installing them!

Great job, Jason!

Question: Besides PlainSight, where else is RegRipper being used?