Plugin Updates
Mari has done some fascinating research into MS Office Trust Records and posted her findings here. Based on her sharing her findings and sample data, I was able to update the trustrecords.pl plugin.  Further, Mari's description of what she had done was so clear and concise that I was able to replicate what she did and generate some of my own sample data.

The last update to the trustrecords.pl plugin was from 16 July 2012; since then, no one's used it or apparently had any issues with it or questions about what it does.  For this update, I added a check for the VBAWarnings value, and added parsing of the last 4 bytes of the TrustRecords value data, printing "Enable Content button clicked" if the data is is in accordance with Mari's findings.  I also changed how the plugin determines which version of Office is installed. I also made sure to update the trustrecords_tln.pl plugin accordingly, as well.

So, from the sample data that Mari provided, the output of the trustrecords.pl plugin looks like this:

**Word**
----------
Security key LastWrite: Wed Feb 24 15:58:02 2016 Z
VBAWarnings = Enable all macros

Wed Feb 24 15:08:55 2016 Z : %USERPROFILE%/Downloads/test-document-domingo.doc
**Enable Content button clicked.

...and the output of the trustrecords_tln.pl plugin looks like this:

1456326535|REG|||TrustRecords - %USERPROFILE%/Downloads/test-document-domingo.doc [Enable Content button clicked]

Addendum, 25 Feb

Default Macro Settings (MSWord 2010)

After publishing this blog post yesterday, there was something that I ran across in my own testing that I felt was important to point out.  Specifically, when I first opened MSWord 2010 and went to the Trust Center, I saw the default Macro Settings, illustrated in the image to the right; this is with no VBAWarnings value in the Registry.  Once I started selecting other options, the VBAWarnings value was created.

What this seems to indicate is that if the VBAWarnings value exists in the Registry, even if the Macro Settings appear as seen in the image above (the data for the value would be "2"), that someone specifically changed the value.  So, if the VBAWarnings value doesn't exist in the Registry, it appears (based on limited testing) that the default behavior is to disable macros with a notification.  If the setting is changed, the VBAWarnings value is created.  If the VBAWarnings value is set to "2", then it may be that the Macro Settings were set to something else, and then changed back.

For example, take a look at the plugin output I shared earlier in this post.  You'll notice that the LastWrite time of the Security key is 50 min later than the TrustRecords time stamp for the document.   In this case, this is due to the fact that Mari produced the sample data (hive) for the document, and then later modified the Macro Settings because I'd reached back to her and said that the hive didn't contain a VBAWarnings value.

Something else to think about...has anyone actually used the reading_locations.pl plugin?  If you read Jason's blog post on the topic, it seems like it could be pretty interesting in the right instance or case.  For example, if an employee was thought to have modified a document and claimed that they hadn't, this data might show otherwise.
**end addendum**

Also, I ran across a report of malware using a persistence mechanism I hadn't seen before, so I updated termserv.pl to address the "new" key.

Process Creation Monitoring
My recent look into and description of PECapture got me thinking about process creation monitoring again.

Speaking of process creation monitoring, Dell SecureWorks recently made information publicly available regarding the AdWind RAT.  If you read through the post, you'll see that the RAT infection process spawns a number of external commands, rather than using APIs to do the work.  As such, if you're recording process creation events on your endpoints, filters can be created to watch for these commands in order to detect this (and other) activity.

Malicious LNK
Wait, what?  Since when did those two words go together?  Well, as of the morning of 24 Feb, the ISC handlers have made it "a thing" with this blog post.  Pretty fascinating, and thanks to the handlers for walking through how they pulled things out of the LNK file; it looks as if their primary tool was a hex editor.

A couple of things...

First, process creation monitoring of what this "looks like" when executing would be very interesting to see.  If there's one thing that I've found interesting of late is how DFIR folks can nod their heads knowingly at something like that, but when it comes to actual detection, that's another matter entirely.  Yes, the blog post lists the command line used  but the question is, how would you detect this if you had process creation monitoring in place?

Second, in this case, the handlers report that "the ACE file contains a .lnk file"; so, the ACE file doesn't contain code that creates the .lnk file, but instead contains the actual .lnk file itself.  Great...so, let's grab Eric Zimmerman's LECmd tool, or my own code, and see what the NetBIOS name is of the system on which the LNK file was created.  Or, just go here to get that (I see the machine name listed, but not the volume serial number...).  But I'd like to parse it myself, just to see what the shell items "look like" in the LNK file.

As a side note, it's always kind of fascinating to me how some within the "community" will have data in front of them, and for whatever reason, just keep it.  Just as an example (and I'm not disparaging the work the handlers did, but commenting on an observation...), the handlers have the LNK file, but they're not sharing the vol SN, NetBIOS name, or shell items included in the LNK file, just the command line and the embedded payload.  I'm sure that this is a case of "this is what we feel is important, and the other stuff isn't...", but what happens when others find something similar?  How do we start correlating, mapping and linking similar incidents if some data that might reveal something useful about the author is deemed unnecessary by some?

Like I said, not disparaging the work that the handlers did, just thinking out loud a bit.

8Kb One-Liner
There was a fascinating post over at Decalage recently regarding a single command line that was 8Kb long.  They did a really good walk-through for determining what a macro was up to, even after the author took some pretty significant steps to make getting to a human-readable format tough.

I think it would be fascinating to get a copy of this sample and run it on a system with SysMon running, to see what the process tree looks like for something like this.  That way, anyone using process creation monitoring could write a filter rule or watchlist to monitor for this in their environment.

From the Trenches
The "From the Trenches" stuff I've been posting doesn't seem to have generated much interest, so I'm going to discontinue those posts and move on to other things.

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.

A bit ago, I posted about doing analysis, and that post didn't really seem to get much traction at all.  What was I trying for?  To start a conversation about how we _do_ analysis.  When we make statements to a client or to another analyst, on what are we basing those findings?  Somewhere between the raw data and our findings is where we _do_ analysis; I know what that looks like for me, and I've shared it (in this blog, in my books, etc.), and what I've wanted to do for some time is go beyond the passivity of sitting in a classroom, and start a conversation where analysts engage and discuss analysis.

I have to wonder...is this even possible?  Will analysts talk about what they do?  For me, I'm more than happy to.  But will this spark a conversation?

I thought I'd try a different tact this time around.  In a recent blog post, I mentioned that two Prefetch parsers had recently been released.  While it is interesting to see these tools being made available, I have to ask...how are analysts using these tools?  How are analysts using these tools to conduct analysis, and achieve the results that they're sharing with their clients?

Don't get me wrong...I think having tools is a wonderful idea.  We all have our favorite tools that we tend to gravitate toward or reach for under different circumstances.  Whether it's commercial or free/open source tools, it doesn't really matter.  Whether you're using a dongle or a Linux distro...it doesn't matter.  What does matter is, how are you using it, and how are you interpreting the data?

Someone told me recently, "...I know you have an issue with EnCase...", and to be honest, that's simply not the case.  I don't have an issue with EnCase at all, nor with FTK.  I do have an issue with how those tools are used by analysts, and the issue extends to any other tool that is run auto-magically and expected to spit out true results with little to no analysis.

What do the tools really do for us?  Well, basically, most tools parse data of some sort, and display it.  It's then up to us, as analysts, to analyze that data...interpret it, either within the context of that and other data, or by providing additional context, by incorporating either additional data from the same source, or data from external sources.

RegRipper is a great example.  The idea behind RegRipper (as well as the other tools I've written) is to parse and display data for analysis...that's it.  RegRipper started as a bunch of scripts I had sitting around...every time I'd work on a system and have to dig through the Registry to find something, I'd write a script to do the actual work for me.  In some cases, a script was simply to follow a key path (or several key paths) that I didn't want to have to memorize. In other cases, I'd write a script to handle ROT-13 decoding or binary parsing; I figured, rather than having to do all of that again, I'd write  a script to automate it.

For a while, that's all RegRipper did...parse and display data.  If you had key words you wanted to "pivot" on, you could do so with just about any text editor, but that's still a lot of data.  So then I started adding "alerts"; I'd have the script (or tool) do some basic searching to look for things that were known to be "bad", in particular, file paths in specific locations.  For example, an .exe file in the root of the user profile, or in the root of the Recycle Bin, is a very bad thing, so I wanted those to pop out and be put right in front of the analyst.  I found...and still find...this to be an incredibly useful functionality, but to date,

Here's an example of what I'm talking about with respect to analysis...I ran across this forensics challenge walk-through recently, and just for sh*ts and grins, I downloaded the Registry hive (NTUSER.DAT, Software, System) files.  I ran the appcompatcache.pl RegRipper plugin against the system hive, and found the following "interesting" entries within the AppCompatCache value:

C:\dllhot.exe  Tue Apr  3 18:08:50 2012 Z  Executed
C:\Windows\TEMP\a.exe  Tue Apr  3 23:54:46 2012 Z  Executed
c:\windows\system32\dllhost\svchost.exe  Tue Apr  3 22:40:25 2012 Z  Executed
C:\windows\system32\hydrakatz.exe  Wed Apr  4 01:00:45 2012 Z  Executed
C:\Windows\system32\icacls.exe  Tue Jul 14 01:14:21 2009 Z  Executed

Now, the question is, for each of those entries, what do they mean?  Do they mean that the .exe file was "executed" on the date and time listed?

No, that's not what the entries mean at all.  Check out Mandiant's white paper on the subject.  You can verify what they're saying in the whitepaper by creating a timeline from the shim cache data and file system metadata (just the $MFT will suffice); if the files that had been executed were not deleted from the system, you'll see that the time stamp included in the shim cache data is, in fact, the last modification time from the file system (specifically, the $STANDARD_INFORMATION attribute) metadata.

I use this as an example, simply because it's something that I see a great deal of; in fact, I recently experienced a "tale of two analysts", where I reviewed work that had previously been conducted, by two separate analysts.  The first analyst did not parse the Shim Cache data, and the second parsed it, but assumed that what the data meant was that the .exe files of interested had been executed at the time displayed alongside the entry.

Again, this is just an example, and not meant to focus the spotlight on anyone.  I've talked with a number of analysts, and in just about every conversation, they've either known someone who's made the same mistake misinterpreting the Shim Cache data, or they've admitted to misinterpreting it themselves.  I get it; no one's perfect, and we all make mistakes.  I chose this one as an example, because it's perhaps one of the most misinterpreted data sources.  A lot of analysts who have attended (or conducted) expensive training courses have made this mistake.

Pointing out mistakes isn't the point I'm trying to make...it's that we, as a community, need to engage in a community-wide conversation about analysis.  What resources do we have available now, and what do we need?  We can't all attend training courses, and when we do, what happens most often is that we learn something cool, and then don't see it again for 6 months or a year, and we forget the nuances of that particular analysis.  Dedicated resources are great, but they (forums, emails, documents) need to be searched.  What about just-in-time resources, like asking a question?  Would that help?

Once, on a blog far, far away, there was this post that discussed the use of the Unicode RLO control character to "hide" malware in the Registry, particularly from GUI viewers that processed Unicode.

Recently, Jamie shared this Symantec article with me; figure 1 in the article illustrates an interesting aspect of the malware when it comes to persistence...it apparently prepends a null character to the beginning of the value name.  Interesting, some seem to think that this makes tools like RegEdit "brokken".

So, I wrote a RegRipper plugin called "null.pl" that runs through a hive file looking for key and value names that being with a null character.  Jamie also shared a couple of sample hives, so I got to test the plugin out.   The following image illustrates the plugin output when run against one of the hives:

Figure 1

All in all, the turn-around time was pretty quick.  I started this morning, and had the plugin written, tested, and uploaded to Github before lunch.

Later in the day, Eric Zimmerman followed up by testing the hive that Jamie graciously shared with me against the Registry Explorer.  I should also note that MiTeC WRR has no issues with the value names; it displays them as follows:

Figure 2

Addendum, 20 Jan: On a whim, I ran the fileless.pl plugin against the hive, and it detected the two values with the "fileless" data seen in figure 2.

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.

RegRipper has been consolidated at a single, static site.

Going forward, everything related to RegRipper will be available via (either at, or linked from) this one site.  Updates to the tools will be available here, documentation will be available in the Wiki, and the latest plugin archives will be available from this site, as well.

The reason for doing this is that there just seems to be too much confusion associated with the tool.  I've received emails saying that there are just too many sites that offer RegRipper, and that it's too confusing to figure out which one is the right one.  So, let's just make it simple...this is the right one.

You'll notice that there's material in the Wiki, as well.  We'll be using this to document and provide information in one single, static location.  There is some information there now, but if there's something of interest that you can't find, let me know. I'll be happy to add or update information on the Wiki so that it's more useful.

I greatly appreciate all of the work that folks like Francesco, Brett, and Corey have put into the tool over the years.  I also greatly appreciate the work of folks who have written plugins, as well as folks like Adam and "Cheeky4n6Monkey" who've written tools in an effort to make RegRipper easier to use.  This consolidation does not take away from the great work that they've all done...it's simply a desire to bring everything together in one place.

So, what's different with this iteration of RegRipper?  Not a lot, really.  Again, it's more of a consolidation than anything else.  Corey and I have put a lot of effort into "cleaning" up the plugin archive.  We have updated a number of the plugins, consolidating some functionality, and adding other functionality (support for Wow6432Node where appropriate, etc.); in fact, there are so many of those little changes that we're going to forego the History page, but we'll pick it back up as we start documenting changes again going forward.  So really...the biggest change is just the consolidation of everything in a single location.

Again, going forward, I'd like to have everything related to RegRipper at one site.  Also, if you have any plugin requests, or just want to provide sample data for testing, please feel free to send it to me.

Finally, one more great big thanks to all of those who have supported RegRipper, by blogging about it, requesting or providing plugins, including it in an archive or distro, etc. 

I blogged previously on the topic of Shellbag Analysis, but I've found that in presenting on the topic and talking to others, there may be some misunderstanding of how these Registry artifacts may be helpful to an analyst.  With Jamie's recent post on the Shellbags plugin for Volatility, I thought it would be a good idea to revisit this information, as sometimes repeated exposure is the best way to start developing an understanding of something.  In addition, I wanted to do some testing in order to determine the nature of some of the metadata associated with shellbags.

In her post, Jamie states that the term "Shellbags" is commonly used within the community to indicate artifacts of user window preferences specific to Windows Explorer.  MS KB 813711 indicates that the artifacts are created when a user repositions or resizes an Explorer windows.

ShellItem Metadata
As Jamie illustrates in her blog post, many of the structures that make up the SHELLITEMS (within the Shellbags) contain embedded time stamps, in DOSDate format.  However, there's still some question as to what those values mean (even though the available documentation refers to them as MAC times for the resource in question) and how an analyst may make use of them during an examination.

Having some time available recently due to inclement weather, I thought I would conduct a couple of very simple tests in to begin to address these questions.

Testing Methodology
On a Windows 7 system, I performed a number of consecutive, atomic actions and recorded the system time (visible via the system clock) for when each action was performed.  The following table lists the actions I took, and the time (in local time format) at which each action occurred.

Action	Time
Create a dir: mkdir d:\shellbag	12:54pm
Create a file in the dir: echo "..."  > d:\shellbag\test.txt	1:03pm
Create another dir: mkdir d:\shellbag\test	1:08pm
Create a file in the new dir: echo "..." > d:\shellbag\test\test.txt	1:16pm
Delete a file: del d:\shellbag\test.txt	1:24pm
Open D:\shellbag\test via Explorer, reposition/resize the window	1:29pm
Close the Explorer window opened in the previous step	1:38pm

The purpose of having some time pass between actions is so that they can be clearly differentiated in a timeline.

Once these steps were completed, I restarted the system, and once it came back up, I extracted the USRCLASS.DAT hive from the relevant user account into the D:\shellbag directory for analysis (at 1:42pm).  I purposely chose this directory in order to determine how actions external to the shellbags artifacts affect the overall data seen.

 Results
The following table lists the output from the shellbags.pl RegRipper plugin for the directories in question (all times are in UTC format):

Directory	MRU Time	Modified	Accessed	Created
Desktop\My Computer\D:\shellbag	2012-10-29 17:29:25	2012-10-29 17:24:26	2012-10-29 17:24:26	2012-10-29 16:55:00
Desktop\My Computer\D:\shellbag\test	2012-10-29 17:29:29	2012-10-29 17:16:20	2012-10-29 17:16:20	2012-10-29 17:08:18

Let's walk through these results.  First, I should remind you that that MRU Time is populated from Registry key LastWrite times (FILETIME format, granularity of 100 ns) while the MAC times are embedded within the various shell items (used to reconstruct the paths) in DOSDate time format (granularity of 2 seconds).

First, we can see that the Created dates for both folders correspond approximately to when the folders were actually created.  We can also see that the same thing is true for the Modified dates.  Going back to the live system and typing "dir /tw d:\shell*" shows me that the last modification time for the directory is 1:42pm (local time), which corresponds to changes made to that directory after the USRCLASS.DAT hive file was extracted.

Next, we see that MRU Time values correspond approximately to when the D:\shellbag\test folder was opened and then resized/repositioned via the Explorer shell, and not to when the Explorer window was actually closed.

Based on this limited test, it would appear that the DOSDate time stamps embedded in the shell items for the folders correspond to the MAC times of that folder, within the file system, at the time that the shell items were created.  In order to test this, I deleted the d:\shellbag\test\test.txt file at 2:14pm, local time, and then extracted a copy of the USRCLASS.DAT and parsed it the same way I had before...and saw no changes in the Modified times listed in the previous table.

In order to test this just a bit further, I opened Windows Explorer, navigated to the D:\shellbag folder, and repositioned/resized the window at 2:21pm (local time), waited 2 minutes, and closed the window.  I extracted and parsed the USRCLASS.DAT hive again, and this time, the MRU Time for the D:\shellbag folder had changed to 18:21:48 (UTC format).  Interestingly, that was the only time that had changed...the Modified time for the D:\shellbag\test folder remained the same, even though I had deleted the test.txt file from that directory at 2:14pm local time ("dir /tw d:\shellbag\te*" shows me that the last written time for that folder is, indeed, 2:14pm).

Summary
Further testing is clearly required; however, it would appear that based on this initial test, we can draw the following conclusions with respect to the shellbag artifacts on Windows 7:

1.  The embedded DOSDate time stamps appear to correspond to the MAC times of the resource/folder at the time that the shell item was created.  If the particular resource/folder was no longer present within the active file system, an analyst could use the Created date for that resource in a timeline.

2.  Further testing needs to be performed in order to determine the relative value of the Modified date, particularly given that events external to the Windows Explorer shell (i.e., creating/deleting files and subfolders after the shell items have been created) may have limited effect on the embedded dates.

3.  The MRU Time appears to correspond to when the folder was resized or repositioned.  Analysts should keep in mind that (a) there are a number of ways to access a folder that do not require the user to reposition or resize the window, and (b) the MRU Time is a Registry key LastWrite time that only applies to one folder within the key...the Most Recently Used folder, or the one listed first in the MRUListEx value.

I hope that folks find this information useful.  I also hope that others out there will look at this information, validate it through their own testing, and even use it as a starting point for their own research.

I recently listened to Ovie and Corey on the latest CyberSpeak podcast, and wanted to combine what I'd heard them discuss with respect to the latest release of RegRipper, and provide a technique for analysis that incorporates VSCs.

Now, one of the things we may run across during our analysis, if we create a timeline, is that we may have a Registry key that was modified in some way during a particular time window of interest.  There are a number of Registry keys for which all we have available is a LastWrite time (which is analogous to a files last modification time) but we do not know what that modification entailed.

For example, some keys maintain a "most recently used" (MRU) list, and we know that whatever the most recent activity was (user accessed/viewed a file, etc.), we can be pretty sure that, in most cases, the activity we see is associated with the key's LastWrite time.  However, we may see other keys that simply contain values and subkeys, with LastWrite times that occur during our window of interest.  Examples of these keys include the Run key (in both the Software and NTUSER.DAT hives), the MUICache key, etc.  We don't know, simply by looking at the contents of the key, what change may have occurred; was a value or subkey added  or deleted? 

So, given that we have an image of a Windows 7 (or Vista) system, which may have a number of VSCs available, how can we attempt to determine what that change may have been? 

Well, the first thing you want to do is mount the image as a volume on your Windows 7 analysis system in a manner that allows you to access the VSCs within the image; perhaps the easiest way to do so is via the VHD method.  Once you have the image mounted (let's call it V:\), you'll want to determine which VSCs are available using the vssadmin command:


You'll see a bunch of stuff go by, and you'll want to look for lines that look like this:

Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8

A really easy way to cut through all of that stuff is to use the following command line:


Okay, so now you should have a list of VSCs from the image; for the sake of this example, let's say that you have VSCs numbered 23 through 30.  How can we use this information to compare the values in, say, the Run key from the Software hive?  We know that the 'soft_run.pl' plugin lets us output the contents of this key, but how can we easily retrieve information from the previous versions of the Software hive within the VSCs?

Let's create a batch file to automate this for us.  A simple 'for' loop in a batch file looks like this:


If you put the above command in a batch file ('test.bat') and then run the batch file, you'll see the numbers 23 through 30 echo'd to the console.  We can use variables in our batch file by substituting the first and last numbers with '%1' and '%2', respectively:


Okay, that's easy enough.  Now, all we need to do is get RegRipper to parse this information for us.  We can do that using the latest version (2.5) of RegRipper, and specifically rip.exe.


We would save this command into a batch file (name it "vsc_run.bat") in the same directory where we have rip.exe, and then run it using the following command line:


That's it.  That's all it takes.  And the cool thing is that we can save this batch file and use it again and again, or modify it in some way for future use.  One way to modify it would be to output everything to a file, rather than just allowing everything to fly by at the console.  To do that, simply add " >> output.txt" to the end of the command within the batch file.  You can also add comments to the batch file, via normal batch file scripting techniques.

This is just another example of how we can use already-available tools and techniques to build better and more efficient analysis methodologies.  Why sit around staring at your monitor when there are easy and efficient ways to extract the data that you need for analysis?

Here's another use for this technique; at the request of a member of LE, I recently modified the currently available 'ares.pl' plugin (for parsing Registry keys for the Ares P2P application) to parse out just specific information, which includes decoding the search terms typed in by the user.  If a Windows 7 (or Vista) system was being examined, you could use this technique to see the change of of several of the values, including the user typing in search terms, over time.  The key that maintains the search terms does not include an MRU value, so you can use this technique to easily parse out exactly what you're looking for, and rather than seeing "between these two dates, the user typed in 30 search terms", you could see the progression of the terms typed in over time, across the available VSCs.

Following that same technique, I've seen instances where administrators have "taken remediation actions" and "cleaned up" prior to systems being reported as compromised and acquired.  Using the contents of the MUICache key (located in the USRCLASS.DAT hive on a Win7 system), I found that this little bundle of joy had been run on the system, but "cleaned up".  Using this technique, I could narrow down when the application had been run, and then go into my timeline to see what else was going on around that time.

Note that this technique can be used to approximate the time of program execution on systems where application Prefetch files are not available, either because they were deleted, or because the system is a server (Win2003, Win2008) and doesn't have application prefetching enabled by default.

With that kind of pin-point, surgical accuracy, this kind of sounds like Sniper Forensics to me!

I recently provided a minor update to the RegRipper tools, moving to v2.5.  As there was no modification to how the tools would interact with the plugins, I only provided the tools themselves, including both the Perl scripts (source code) and Windows executables, compiled via Perl2Exe.  I did not include the contents of the plugins directory along with the distribution, as I figured folks who were using the tool would just copy the files over their current installation.

Since the release of the updates, I've received a couple of comments about the RegRipper GUI not working properly.  Some folks are finding that "Plugins File" drop-down box will not be populated, and the assumption appears to be that the tool isn't reading the plugins directory, even though the "plugins" directory exists and contains plugins.  When you launch the GUI, one of the things that happens is that the GUI will look in the "plugins" directory for any files that do NOT contain an extension, and assume that these are profiles.  What appears to be happening is that while the directory contains plugins, it does not contain profiles...these are the files that tell RegRipper which plugins to run.  By default, those profiles are "ntuser", "sam", "security", "software" and "system", all without any extension (by that, I mean that the file does not end with '.txt' or anything else).

What I think may be happening is that folks are creating fresh installations of the tool; they're downloading the new version and putting it into it's own directory, and then getting the plugins archive file from here; this archive does not contain the profiles. 

What you can do in that case is copy the profiles over from your RR v2.02 install, or simply create your own profile.  A really easy way to do that is to go to your RR v2.5 install directory, open a command prompt, and type:


Open the resulting file in Excel and sort the rows, based on the hive column.  Another way to do this for individual hive files is to use a command such as the following:


This will list just the plugins that are intended to be run against the Software hive, their versions, etc. 

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

Using RegRipper
Russ McRee let me know recently that the folks at Passmark recently posted a tutorial on how to use their OSForensics tool with RegRipper.

Speaking of RegRipper, I was contacted not long ago about setting up a German mirror for RegRipper...while it doesn't appear to active yet, the domain has been set aside, and I'm told that the guys organizing it are going to use it not only as a mirror, but also as a site for some of the plugins they'll be getting in that are specific to what they've been doing.

If you're into GenToo Linux, there's also this site from Stefan Reimer which contains a RegRipper ebuild for that platform.

Updated tool:  Stefan over on the Win4n6 Yahoo group tried out the Jump List parser code and found out that, once again, I'd reversed two of the time stamps embedded in the LNK file parsing code.  I updated the code and reposted the archive.  Thanks!

Meetups
With respect to the NoVA Forensics Meetups, I posted here asking what folks thought about moving them to the DFIROnline meetups, and I tweeted something similar.  Thus far, I have yet to receive a response from the blog post, and of the responses I've seen on Twitter, the vast majority (2 or 3..I've only seen like 4 responses...) indicate that moving to the online format is just fine.  I did receive one response from someone who seems to like the IRL format...although that person also admitted that they haven't actually been to a meetup yet.

So...it looks like for 2012, we'll be moving to the online format.  Looking at the lineup thus far, we already seem to be getting some good presentations coming along in the near future.

Speaking of which, offering to either give a presentation or asking for some specific content to be presented on is a great way to contribute to the community.  Just something to keep in mind...if you're going to say, "...I'd like to hear about this topic", be prepared to engage in a discussion.  This isn't to say that someone's going to come after you and try to belittle your idea...not at all.  Instead, someone willing to present on the topic may need more information about your respective, what you've tried (if anything), any research that you've already done, etc.  So...please be willing to share ideas of what you'd like to see presented, but keep in mind that, "...what do you mean by that?" is NOT a slam.

New Tools
File this one under "oh, cr*p..."...

Seems setmace.exe has been released...if you haven't seen this yet, it apparently overcomes some of the issues with timestomp.exe; in particular, it is reportedly capable of modifying the time stamps in both the $STANDARD_INFORMATION and the $FILE_NAME attributes within the MFT.  However, it does so by creating a randomly-named subdirectory within the same volume, copying the file into the new directory, and then copying it back (Note: the description on the web page uses "copy" and "move" interchangeably).

Okay, so what does this mean to a forensic analyst, if something like this is used maliciously?  I'm going to leave that one to the community...

The folks at SimpleCarver have released a new tool to extract contents from the CurrentDatabase_327.wmdb file, a database associated with the Windows 7 Windows Media Player.   If you're working an exam that involves the use of WMP (i.e., you've seen the use of the application via the Registry and/or Jump Lists...), then you may want to consider taking a look at this tool.

You might also want to check out some of their other free tools.

Melissa posted to her blog regarding a couple of interesting tools for pulling information from memory dumps; specifically, pdgmail and Skypeex.  Both tools apparently require that you run strings first, but that shouldn't be a problem...the cost-benefit analysis seems to indicate that it's well worth running another command line tool.  An alternative to running these tools against a memory dump would be using Volatility or the MoonSols Windows Memory Toolkit to convert a hibernation file to a  raw dump format, and then run these tools.

Speaking of tools, Mike posted a list of non-forensics tools that he uses on Windows systems to his WriteBlocked blog.  This is a very good list, with a lot of useful tools (as well as tools I've used) on that list.  I recently used Wireshark to validate some network traffic...another tool that you might consider using alongside Wireshark is NetworkMiner...it's described as an NFAT tool, so I can see why it's not on Mike's list.  I use VirtualBox...I have a copy of the developer's build of Windows 8 running in it.

Wiping Utilities
Claus is back, and this time has a nice list of wiping utilities.  As forensic analysts, many times we have to sanitize the media that we're using, so having access to these tools is a very good thing.  I've always enjoyed Claus's posts, as well, and hope to see him posting more and more often in 2012.

Can anyone provide a technical reason why wiping with 7 passes (or more) is "better" than wiping with just 1 pass?

File Formats
I was reading over Yogesh Khatri's posts over at SwiftForensics.com, and found this post on IE RecoveryStore files.  Most analysts who have done any work with browser forensics are aware of the value of files that allow the browser to recover previous sessions...these resources can hold a good deal of potentially valuable data.

About halfway down the post, Yogesh states:

There are times when you don't want (or need) a super timeline, but instead just want to focus on one piece of available data, such as Event Log entries or Registry key LastWrite times.  I've had occasion to focus on just specific entries in the Security Event Logs; specifically, event ID 528, type 10, indicating RDP logins to a system.  I used one of the timeline tools I wrote, evtparse.pl, to parse the appropriate records from the Security Event Log and then create a timeline from just those records.

So, let's say that you have something specific that you want to look for, such as all Registry keys that were created or modified between two specific dates.  You'd want to start by either extracting the appropriate hives from the acquired image via FTK Imager, or using FTK Imager to mount the acquired image as a volume on your analysis system. 

For the next steps, go here and download the tln_tools.zip archive...do NOT download regtime.zip for this exercise.  From the tln_tools.zip archive, we will be working specifically with the regtime.pl and parse.pl tools (note that regtime also ships with a standalone EXE...you must have the p2x588.dll file in the same directory along with the EXE).

The first thing you'll need to do is create your events file of the Registry key LastWrite times.  One thing you'll need is the name of the system you're analyzing.  This can be something that's already in your case documentation; however, if you don't have that information, you can either enter a designator, or leave it blank...for what we're doing, it isn't critical.  If you have RegRipper installed, this is very easy to get, using the following command:


We can then use the returned information in your mini-timeline instead of the "SERVER" value in the below commands.

Next, we'll parse the Software and System hives (assume that the image is mounted as H:\):



Now that we have the events file, we can use parse.pl to generate our timeline.  If you type just "parse.pl" at the command prompt (or "parse.pl -h"), you'll see that the script has a couple of options, one of which is to specify a date range.  Let's say that you want all events from your events file, between 3 March and 4 April 2011, inclusive.  You would use the following command:


This command provides an ASCII output format that I've always found very easy to view and understand. If you would like .csv output, which Excel is much happier with, type the following command (note the "-c" switch):


There you go...that's it.  You can also add other hives to your events file, even NTUSER.DAT hives (adding the username after the "-u" switch can help you tell different user's apart).

This blog post has been brought to you by the open source tool, "regtime.pl", and the redirection operator ">".

Speaking Engagements
I received notification last week that my submission for the 2012 DoD CyberCrime Conference was accepted.  I'll be giving a presentation on timeline analysis at this conference, and I hope to have some new material ready and available to share well before the presentation.

I will also be speaking at PFIC 2011 this year; I actually have two presentations, with a total (according to the schedule) three sessions on the podium.  I'll be presenting on "Scanning for Low-Hanging Fruit in an Investigation", as well as "Intro to Windows Forensics".  Once I've completed WFA 3/e and everything's been submitted, I plan to focus on some of the material for the first presentation, in particular the scanning framework.  This presentation will be a follow-on to my OSDFC presentation from this past June.

The closest alligator to the boat, however, would be presentations I'll be giving at ETCSS in Oct. I'll be giving two presentations on 12 Oct..."What's new in Windows 7: An Analyst's Perspective", and "Incident Preparedness".

eEvidence
The eEvidence What's New page has been updated...I always find a lot of great reading material there.  This time around, there are a number of excellent presentations linked from the page...all of which are well worth taking a look at.

NoVA Forensics Meetup
Our next meetup is this Wednesday, 7 Sept.  Mitch Harris will be presenting on botnets.

Please take a look at the "NoVA Forensics Meetup" page linked on the right-hand panel of this blog, under "Pages", if you have any questions regarding location, times, fees, attendance requirements, etc.  Thanks.

If you still feel the need to ask about attendance requirements and fees, you will have to pay eleventy-three dollars at the door as a cover charge, and you have to come dressed as a clown. 

RegRipper Plugins
An archive of new RegRipper plugins was recently released and is available for download at this Google Code site.  I didn't write these plugins, but I will say that it is really cool to see folks taking the time to take full advantage of an open source tool such as RegRipper, and create what they need to get the job done.

I did modify some code for one of the plugins. -- contact the author --

Now, I've seen a couple of comments and received an email or two recently regarding adding these new plugins to RegRipper.  First, download the archive and copy the plugins into the plugins directory...however, from there, there seems to be some confusion regarding how to get RegRipper to use these new plugins.

The RegRipper plugins folder generally contains types of files; the ones that end with the ".pl" extension should be plugins (Perl scripts), and those that have no extensions should be profiles, or lists of plugins that you'd like to run against a particular hive.  The profiles don't have to have a specific name...the ones that were originally shipped with RegRipper (software, system, sam, ntuser, etc.) are just examples, nothing more.  You can name one of these files "steve" if you like, it doesn't matter.  As long as the file does not have an extension, it will appear in the dropdown list in the RegRipper GUI.

So, when you get a new plugin and add it to the plugin folder, yes, you do sort of have to figure out what you want to do with it.  I designed it this way to give analysts the flexibility to run their exams the way they want, to give them choices (hopefully based on knowledge, education, and experience).  In order to facilitate determining which hive a plugin is intended for, I added some functionality to rip.pl (or rip.exe, whichever version you're using); for example, if you run rip.pl with the "-l" switch, you will see a listing of plugins with information about each one output to STDOUT.  If you add the "-c" switch, the output will in .csv format, which is great for redirecting to a file, which you can then open in Excel.  From there, it's pretty easy to create or modify a profile via Notepad.

I also created the Plugin Browser, which was released along with the code/programs for Windows Registry Forensics (RR.zip).  This tool provides a graphical method for an analyst to browse through the plugins (hence the name) and even create a profile.

When I sat down and came up with this tool, I wanted the user/analyst to have the ability to decide which plugins to run.  After all, there isn't always a need to run all of the available plugins against a hive file; this may simply be too much information to dig through.  Some plugins may be redundant, parsing the same information, but just displaying it a different manner (yes, I was once contacted by someone who had run all three plugins that parse UserAssist subkey data and present it in different formats...they asked me what the difference was between them...).  There may also be instances in which a plugin may be used in different profiles; for example, I would include the plugin that parses the XP firewall settings in a profile that gets general information about the system, as well as one specifically used to determine if there are any indications of malware on the system.

What this ultimately means is that the analyst is going to have to do something.  I'm really sorry about that...but as an analyst using RegRipper, you're going to have make some decisions and take some actions.

Note:  Something I wanted to mention again...tools such as RegRipper (and rip) are only as powerful as the analyst using them.  If you sit down and expect RegRipper to extract some particular information from the Registry for you, without understanding what the tool is doing, or if there is even a plugin that gets that information, you may be disappointed.

What do I do if it don't work?
If something doesn't appear to be right about the tool you're using, it's usually most helpful if you go directly to the author, and provide information beyond, "it don't work".  The response may be simply an update, particularly if it's a known issue. Or you may be using the tool incorrectly...those pesky readme files are such a PITA, aren't they?  Or it could be an unanticipated condition...such as when I was working on the Jump List parser and found out what a Jump List "looks like" when it hasn't yet been closed by the operating system (the Jump List was extracted from an image file produced during a live acquisition).

What if a plugin I need isn't in RegRipper?
If there's a particular plugin that you need and can't seem to find, contacting me with a clear description of what you're looking for, as well as providing a sample hive, will usually result in a new or updated plugin in fairly short order.  And no, I don't make a habit of sharing the fact that you asked, or sharing the contents of the hive, or the sharing the plugin.  I tend to securely delete the hive file once I'm done, and I leave it up to you to share the plugin...unless it's really cool, but then, I'll ask you first.  So if you have any trepidation about asking for help, I hope what I've said here will quell those concerns or fears.

Resources
I've posted on using RegRipper to the blog before; there's a link here, and one here.  There is also a great deal of information about using RegRipper available in chapter 2 of Windows Registry Forensics.

Books (Again)
I had a section in my last post regarding the use of books I've written or co-authored being used in courses to teach computer forensics.  I received an email from Joshua Bartolomie, Adjunct Lecturer at Utica College, and have provided the entirety of his statement, quoted below, with his permission:


CyberCrime
I'm sure that by now, many of us have heard of this guy, who got 6 yrs for "hacking" user's systems and taking over their webcams and mics, and using information (pictures, video, stuff he listened in to) to extort his victims.

Something else to be aware of, folks, is how this sort of information is presented in the media...notice that the first sentence of the third paragraph mentions "undetectable malware", but later the article actually names some of the malware used (i.e., Poison Ivy).

Tools
If you're into digital forensics analysis of Windows systems, particularly those formatted NTFS, then you should consider taking a look at a couple of tools.

First off, Willi Ballenthin released a Python script for parsing INDX files; Willi's also done an excellent job of providing background information about the tool, as well as why you'd want to use it, so take a look.

Then there's the Windows NTFS journal change log parser from TZWorks, LLC.  Tim Mugherini provides a great example of how "jp" was used during a case.

I haven't used either of these tools yet, but I can see where they would be very useful during an examination.  I've found indications of files in directories via the INDX files (appear as "$I30" in FTK Imager) when malware or an intruder's tool kit was deleted after use.

I'll be presenting on "Extending RegRipper" at Brian Carrier's Open Source Digital Forensics Conference on 14 June, along with Cory Altheide, and I wanted to provide a bit of background with regards to what my presentation will cover...

In '98-'99, I was working for Trident Data Systems, Inc., (TDS) conducting vulnerability assessments for organizations.  One of the things we did as part of this work was run ISS’s Internet Scanner (now owned by IBM) against the infrastructure; either a full, broad-brush scan or just very specific segments, depending upon the needs and wants of the organization.  I became very interested in how the scanner worked, and began to note differences in how the scanner would report its findings based on the level of access we had to the systems within the infrastructure.  Something else I noticed was that many of the checks that were scanned were a result of the ISS X-Force vulnerability discovery team.  In short, a couple of very smart folks would discover a vulnerability, add a means of scanning for that vulnerability via the Internet Scanner framework, and roll it out to thousands of customers.  Within fairly short order, this check can be rolled out to hundreds or thousands of analysts, none of whom have any prior knowledge of the vulnerability, nor have had to invest the time to investigate it.  This became even more clear as I started to create an open-source (albeit proprietary) scanner to replace the use of Internet Scanner, due in large part to significant issues with inaccurate checks, and the need to adapt the output.  I could create a check to be run, and give it to an analyst going on-site, and they wouldn't need to have any prior knowledge of the issue, nor would they have to invest time in discovery and analysis, but they could run the check and easily review and understand the results.

Other aspects of information security also benefit from the use of scanners.  Penetration testing and web application assessments benefit from scanners that include frameworks for providing new and updated checks to be run, and many of the analysts running the scanners have no prior knowledge of the checks that are being run.  Nessus (from Tenable) is a very good example of this sort of scanner; the plugins run by the scanner are text-based, providing instructions for the scanner.  These plugins are easy to open and read, and provide a great deal of information regarding how the checks are constructed and run.


Given all of the benefits derived from scanners in other disciplines within information security, it just stands to reason that digital forensic analysis would also benefit from a similar framework.

The forensic scanner is not intended to replace the analyst; rather, it is intended as a framework for documenting and retaining the institutional knowledge of all analysts on the team, and remove the tedium of looking for that "low-hanging fruit" that likely exists in most, if not all, exams.

A number of commercially available forensic analysis applications (EnCase, ProDiscover) have scripting languages and scanner-like functionality; however, in most cases, this functionality is based on proprietary APIs, and in some cases, scripting languages (ProDiscover uses Perl as it's scripting language, but the API for accessing the data is unique to the application). 

A scanner framework is not meant to replace the use of commercial forensic analysis applications; rather, the scanner framework would augment and enhance the use of those applications, by providing an easy and efficient means for educating new analysts, as well as "sweeping up" the "low-hanging fruit", leaving the deeper analysis for the more experienced analysts.

This scanner framework would be based on easily available tools and techniques.  For example, the scanner would be designed to access acquired images mounted read-only via the operating system (Linux mount command) or via freely available applications (Windows - FTK Imager v3.0, ImDisk, vhd/vmdk, etc.); that way, the scanner can make use of currently available APIs (via Perl, Python, etc.) in order to access data within the acquired image, and do so in a "forensically sound manner" (i.e., not making any changes to the original data).

The scanner is not intended to run in isolation; rather, it is intended to be used with other tools (here, here) as part of an overall process.  The purpose of the scanner is to provide a means for retention, efficient deployment, and proliferation of institutional digital forensic knowledge.

Benefits
Some benefits of a forensic scanner framework such as this include, but are not limited to, the following:

1.  Knowledge Retention - None of us knows everything, and we all see new things during examinations.  When an analyst sees or discovers something new, a plugin can be written or updated.  Once this is done, that knowledge exists, regardless of the state of the analyst (she goes on vacation, leaves for another position, etc.).  Enforcing best practice documentation of the plugin ensures that as much knowledge as possible is retained along with the application, providing an excellent educational tool, as well as a ready means for adapting or improving the plugin.

2.  Establish a career progression - When new folks are brought aboard a team, they have to start somewhere.  In most cases, particularly with consulting organizations, skilled/experienced analysts are hired, but as the industry develops, this won't always be the case.  The forensic scanner provides an ancillary framework for developing "home grown" expertise where inexperienced analysts are hired.  Starting the new analysts off in a lab environment and having them begin learning the necessary procedures by acquiring and verifying media puts them in an excellent position to run the scanner.  For example, the analyst either goes on-site and conducts acquisition, or acquires media sent to the lab, and prepares the necessary documentation.  Then, they mount the acquired image and run the scanner, providing the more experienced analyst with the path to the acquired image and the report.

This framework also provides an objective means for personnel assessment; managers can easily track the plugins that are improved or developed by various analysts.

3.  Teamwork - In many environments, development of plugins likely will not occur in a vacuum or in isolation.  Plugins need to be reviewed, and can be improved based on the experience of other analysts.  For example, let's say an analyst runs across a Zeus infection and decides to write a plugin for the artifacts.  When the plugin is reviewed, another analyst mentions that Zeus will load differently based on the permissions of the user upon infection.  The plugin can them be documented and modified to include additional conditions.

New plugins can be introduced and discussed during team meetings or through virtual conferences and collaboration, but regardless of the method, it introduces a very important aspect of forensic analysis...peer review.

4.  Ease of modification - One size does not fit all.  There are times when analysts will not be working with full images, but instead will only have access to selected files from systems.  A properly constructed framework will provide the means necessary for accessing and scanning these limited data sets, as well.  Also, reporting of the scanner can be modified according to the needs of the analyst, or organization.

5.  Flexibility - A scanner framework is not limited to just acquired images.  For example, F-Response provides a means of access to live, remote systems in a manner that is similar to an acquired image (i.e., much of the same API can be used, as with RegRipper), so the framework used to access images can also be used against systems accessed via F-Response.  As the images themselves would be mounted read-only in order to be scanned, Volume Shadow Copies could also be mounted and scanned using the same scanner and same plugins.

Another means of flexibility comes about through the use of "idle" resources.  What I mean by that is that many times, analysts working on-site or actively engaged in analysis may be extremely busy, so running the scanner and providing the output to another, off-site analyst who is not actively engaged frees up the on-site team and provides answers/solutions in a timely and efficient manner.  Or, data can be provided and the off-site analyst can write a plugin based on that data, and that plugin can be run against all other systems/images.  In these instances, entire images do not have to be sent to the off-site analyst, as this takes considerable time and can expose sensitive data.  Instead, only very specific data is sent, making for a much smaller data set (KB as opposed to GB).