Quick Post

RegRipper
At the end of this past summer and into the fall, I was working on the print matter for Windows Forensic Analysis 4/e, and I'm in the process now of getting extra, downloadable materials (I decided a while back to forego the included DVD...) compiled and ready to post.  During the entire process, and while conducting my own exams, I have updated a number of aspects of RegRipper...some of the code to RegRipper itself has been updated, and I've written or updated a number of plugins.  Some recent blogs that have been posted have really provided some information that have led to updates, or at least to a better understanding of the artifacts themselves (how they're created or modified, etc.).

I figured that it'll be time soon for an update to RegRipper.  To that end, Brett has graciously provided me access to the Wordpress dashboard for the RegRipper blog, so this will be THE OFFICIAL SITE for all things RegRipper.

Now, I know that not everyone who uses RegRipper is entirely familiar with the tool, how to use it, and what really constitutes "Registry analysis".  My intention is to have this site become the clearing house for all information related to RegRipper, from information about how to best use the tool to new or updated plugins.

I think that one of the biggest misconceptions about RegRipper is that it does everything right out of the box.  What people believe RegRipper does NOT do has been a topic of discussion, to my knowledge, since a presentation at the SANS Forensic Summit in the summer of 2012.  Unfortunately, in most cases, folks have used presentations and social media to state what they think RegRipper does not do, rather than ask how to get it do those things.  Corey has done a fantastic job of getting RegRipper to do things that he's needed done.  From the beginning, RegRipper was intended to be community-based, meaning that if someone needed a plugin created or modified, they could go to one resource with the request and some sample data for testing, and that's it.  That model has worked pretty well, when it's been used.  For example, Corey posted a great article discussing PCA, Yogesh posted about another aspect of that topic (specifically, the AmCache.hve file), and Mari shared some data with me so that I could get a better, more thorough view of how the data is maintained in the file.  Now, there's a RegRipper plugin that parses this file.  The same thing is true with shellbags...thanks to the data Dan provided along with his blog post, there have been updates to the shellbags.pl plugin.

So, expect to see posts to the RegRipper site in 2014, particularly as I begin working on the updates to Windows Registry Forensics.

USB Devices
Speaking of the Registry...

Thanks to David, I saw that Nicole recently posted some more testing results, this time with respect to USB device first insertion.  She also has a post up regarding directory transversal artifacts for those devices; that's right, another shellbag artifact post!  Add this one to Dan's recent comprehensive post regarding the same artifacts, and you've got quite a bit of fascinating information between those two posts!

Reading through the posts, Nicole's blog is definitely one that you want to add to your blogroll.

Yogesh posted to his blog recently on USB Registry artifacts on Windows 8, specifically with respect to some Registry values that are new specifically to Windows 8.   

Shellbags

Dan recently posted what has to be one of the most thorough/comprehensive blog articles regarding the
Windows shellbags artifacts.  His post specifically focuses on shellbag artifacts from Windows 7, but the value of what he wrote goes far beyond just those artifacts.

Dan states at the very beginning of his post that his intention is to not focus on the structures themselves, but instead address the practical interpretation of the data itself.  He does so, in part through thorough testing, as well as illustrating the output of two tools (one of which is commonly used and endorsed in various training courses) side-by-side.

Okay, so Dan has this blog post...so why I am I blogging about his blog post?  First, I think that Dan's post...in both the general and specific sense...is extremely important.  I'm writing this blog post because I honestly believe that Dan's post needs attention.

Second, I think that Dan's post is just the start.  I opened a print preview of his post, and with the comments, it's 67 pages long.  Yes, there's a lot of information in the post, and admittedly, the post is as long as it is in part due to the graphic images Dan includes in his post.  But this post needs much more attention than "+1", "Like", and "Good job!" comments.  Yes, a number of folks, including myself, have retweeted his announcement of the post, but like many others, we do this in order to get the word out.  What has to happen now is that this needs to be reviewed, understood, and most importantly, discussed.  Why?  Because Dan's absolutely correct...there are some pretty significant misconceptions about these (and admittedly, other) artifacts.  Writing about these artifacts online and in books, and discussing them in courses will only get an analyst so far.  What happens very often after this is that the analyst goes back to their office and doesn't pursue the artifacts again for several weeks or months, and by the time that they do pursue them, there are still misconceptions about these artifacts.

Shell Items
This discussion goes far beyond simply shellbags, in part because the constituent data structures, the shell items, are much more pervasive on Windows systems that I think most analysts realize, and they're becoming more so with each new version.  We've known for some time that Windows shortcut/LNK files can contain shell item ID lists, and with Windows 7, Jump Lists were found to include LNK structures.  Shell items can also be found in a number of Registry values, as well, and the number of locations has increased between Vista to Windows 7, and again with Windows 8/8.1

Consider a recent innovation to the Bebloh malware...according to the linked article, the malware deletes itself when it's loaded in memory, and then waits for a shutdown signal, at which point it writes a Windows shortcut/LNK file for persistence.  There's nothing in the article that discusses the content of the LNK file, but if it contains only a shell item ID list and no LinkInfo block (or if the two are not homogeneous), then analysts will need to understand shell items in order to retrieve data from the file.

These artifacts specifically need to be discussed and understood to the point where an analyst sees them and stops in their tracks, knowing in the back of their mind that there's something very important about them, and that the modification date and time don't necessarily mean what they think.  It would behoove analysts greatly to take the materials that they have available on these (and other) artifacts, put them into a format that is most easily referenced, keep it next to their workstation and share it with others.

Publishing Your Work
A very important aspect of Dan's post is that he did not simply sit back and assume that others, specifically tool authors and those who have provided background on data structures, have already done all the work.  He started clean, by clearing out his own artifacts, and walking through a series of tests without assuming...well...anything.  For example, he clearly pointed out in his post that the RegRipper shellbags.pl plugin does not parse type 0x52 shell items; the reason for this is that I have never seen one of these shell items, and if anyone else has, they haven't said anything.  Dan then made his testing data available so that tools and analysis processes can be improved.  The most important aspect of Dan's post is not the volume of testing he did...it's the fact that he pushed aside his own preconceptions, started clean, and provided not just the data he used, but a thorough (repeatable) write-up of what he did.  This follows right in the footsteps of what others, such as David Cowen, Corey Harrell and Mari DeGrazia, have done to benefit the community at large.

Post such as Dan's are very important, because very often artifacts don't mean what we may think they mean, and our (incorrect) interpretation of those artifacts can lead our examination in the wrong direction, resulting is the wrong answers being provided as a result of the analysis.

Updates

Things tend to move fast in the DFIR world sometimes, and since my last post, there have been some updates to some of the things that were mentioned/discussed, and those updates were important enough that I thought that they needed to be visible.

Page_brute
Robert has updated his blog post on restoring Windows CMD sessions from the pagefile; the update includes an updated Yara rule.

AmCache
Thanks to some data shared by a friend, I was able to see that not all of the File subkeys in the AmCache.hve file will have a SHA-1 hash listed.  This does nothing to obviate Yogesh's work in this area; in fact, I would suggest that it opens the question of what data is recorded and under which circumstances, making this an even more important resource.  I'd sent Mari a copy of the RegRipper amcache.pl plugin to try out, and she found that it crashed...it turns out this was due to the fact that not all of the subkeys had a value named "101" (see Yogesh's blog post with the values listed); I got that fixed right away.

Yogesh has since posted part 2 of his series of blog posts discussing the AmCache.hve file.  Yogesh addresses other subkeys within the AmCache.hve file, as well as some other files within the same folder.  If you're at all interesting in seeing some of what's new in Windows 8/8.1, specifically for DFIR analysts, take a look.

Shellbags
Thanks to Dan's research regarding shellbags artifacts, as well as his willingness to share his test data, I've been updating the RegRipper shellbags.pl plugin.  As of now, it's capable of parsing the type 0x52 shell items that Dan found, and it provides the key path for the resources.  So, instead of just:

Control Panel\User Accounts\Create Your Password 
Control Panel\User Accounts\Change Your Picture 

...now you'll see:

Control Panel\User Accounts\Create Your Password [Desktop\0\3\0\0\]
Control Panel\User Accounts\Change Your Picture [Desktop\0\3\0\1\]

The purpose of this is to allow analysts to validate what they're seeing much more easily.  Using this additional information, analysts can validate the embedded DOSDate MAC times, among other things.

I hope that this blog post helps analysts understand the embedded DOSDate time stamps within shell items.

With respect to shellbags, something "interesting" I've found is that the MFT file reference that can be found in some shell items that comprise the shellbags artifacts can a bit misleading; well, maybe not "misleading" but not easily validated. While I've been able to validate the accuracy of this information for folders on local hard drives (I have the MFT as well as the USRCLASS.DAT hive in some data sets), for removable drives and other resources, the data cannot be validated without the MFT from that external resource.  As such, at this point, I'm debating whether to provide the MFT file reference in the plugin output, or comment out that code (which would allow someone to un-comment it).

Part of the reason why I'm debating (with myself, mostly) whether or not to provide this information in the output of the plugin is that right now, there's a great deal of information being displayed, and I'm afraid that not all of it is all that well understood.  I've seen analysts try to fit the data they're seeing in the tool output to their theory by assuming (albeit incorrectly) what the data means, and that just doesn't work.  In fact, it can be disastrous to the examination.

For example, here's an extract from the output of the current version of the shellbags.pl plugin, run against a sample data set:

| 83/8           |My Computer\D:\VM [Desktop\1\2\5\]
| 275/2         |My Computer\D:\VM\Win2008 [Desktop\1\2\5\0\]
| 84/6          |My Computer\D:\VM\Win7 [Desktop\1\2\5\1\]
| 5402/3       |My Computer\D:\VM\Win2003 [Desktop\1\2\5\2\]
| 5410/2       |My Computer\D:\VM\XP2 [Desktop\1\2\5\3\]
| 5422/6       |My Computer\D:\VM\XP3 [Desktop\1\2\5\5\]
| 404/43       |My Computer\D:\test [Desktop\1\2\6\]
| 405/43       |My Computer\D:\vsc [Desktop\1\2\7\]

Now, I have the image of the system from which this data was extracted, so I've been able to extract and parse the MFT in order to verify the MFT file references, which are listed as the MFT record number, followed by the sequence number.  So, for an analyst that has an image, or even just the hive file and the MFT available, it's a simple matter to determine whether the path listed in the output of the tool can be referenced to a current record in the MFT, or to an older, historic record.  An example of this would be where the MFT file reference for the D:\test folder (as illustrated above) is "404/43" in the shellbags, but MFT record 404 in the current MFT has a higher sequence number (44 or above) and a different name.

Okay, as if that's not confusing enough, what happens if you have MFT file references for paths that are NOT on hard drive local to the system?  Consider the following:

| 136/5        |My Computer\F:\seattle\Tools [Desktop\1\1\36\0\]
| 556/37      |My Computer\F:\seattle\Tools\case2 [Desktop\1\1\36\0\0\]
| 560/3        |My Computer\F:\seattle\Tools\case1 [Desktop\1\1\36\0\1\]

In this case, this information was pulled from one of my own systems, and I know that the F:\ volume was, in fact, an external USB-connected wallet drive.  Without the MFT from the wallet drive, this information cannot be validated.  Is this data then useful?

How Valuable Is Data?
All of this brings up a very important question...specifically, what data is valuable, and how valuable is it? Can value be assessed differently by different analysts, or is data value somewhat universal?

What is the value of the data if it is misunderstood by the analyst? Is the value of the data diminished if the analyst follows it down the wrong path, based on misunderstood data and incorrect assumptions?

Here's an example - below at the embedded MAC times taken from the D:\VM\Win2003 entry above:
M: 2011-08-18 23:55:46
A: 2011-08-18 23:55:46
C: 2011-08-18 23:48:32

What do these time stamps mean? What is the "value" of this data?

SAM Hive
Lance posted an EnScript that parses the SAM Registry hive file and displays the users in each security group.

This has been an integral part of the RegRipper samparse.pl plugin for some time now, and it's great to see the need for this information being recognized and brought to other tools.

Addendum, 17 Dec: On the heels of Corey's RecentFileCache.bcf post, Lance has written an EnScript to parse the file.  I told you...sometimes you can go weeks without anything going on in the DFIR world, and then all of sudden, things start to happen fast!

Addendum, 18 Dec: Corey posted another PCA article, this one addressing Registry keys that maintain data (not configuration information) regarding indicators of program execution.  Great stuff!

Links and News

There have been some exciting developments recently on the Windows digital forensic analysis front, and I thought it would be a good idea to bring them all together in one place.

Recover CMD sessions from the pagefile
If you perform analysis of Windows systems at all, be sure to check out Robert's blog post that discusses how to use page_brute (which I'd mentioned previously here) to recover command prompt sessions from the Windows pagefile.  In the post, the author mentions quite correctly that grabbing a memory image still isn't something that's part of standard incident response procedures.  If you receive a laptop system (or an image thereof) you may find a hibernation file, which you can then analyze, if doing so is something that will help you attain your goals.

Page_brute is based on Yara rules, and Robert shares the rule that he wrote...if you look at it, and follow his reasoning in the post, it's amazingly simple AND it works!

This sort of analysis can be very valuable, particularly if you don't have a memory dump available.  As we learned at OMFW 2013, Volatility is moving in the direction of incorporating the pagefile into analysis, which is fantastic...but that's predicated by the responder's ability to capture a memory dump prior to shutting the system down.

I got yara-python installed (with some help...thanks!) and I then extracted the pagefile from an image I have available.  I had also copied the rule out of Robert's blog post, and pasted it into the default_signatures.yar file that is part of page_brute, and ran the script.  In fact, page_brute.py worked so well, that as it was running through the pagefile and extracting artifacts, MS Security Essentials "woke up" and quarantined several extracted blocks identified as Exploit:js/Blacole, specifically KU and MX variants.  I then opened a couple of the output files from the CMDscan_Optimistic_Blanklines folder, and I wasn't seeing any of the output that Robert showed in his blog post, at least not in the first couple of files.  So, I ran strings across the output files, using the following command:

D:\Tools>strings -n 5 H:\test\output\CMDscan_Optimistic_Blanklines\*.page | find "[Version"

I didn't get anything, so I ran the command again, this time without the "[", and I got a number of strings that looked like Registry key paths.  In the end, this took some setup, downloading a script and running two commands, but you know what...even with that amount of effort, I still got 'stuff' that I would not have gotten as quickly.  Not only has page_brute.py proved to be very useful, it also illustrates what can be done when someone wants to get a job done.

Resources
Excellent Yara post; look here to get the user manual and see how to write rules.

Registry Forensics Class
If you're interested in an online course in analyzing the Windows Registry, Andrew Case, Vico Marziale, and Joe Sylve put together the Registry Analysis Master Class over at The Hacker Academy.  If you're interested in the course, take a look at Ken Pryor's review of the class to see if this is something for you.

Windows Application Experience and Compatibility
Corey's got a new blog post up where he discusses the Windows Application Experience and Compatibility feature, and how the RecentFileCache.bcf file can serve as a data source indicating program execution.  As usual, Corey's post is thorough, referencing and building on previous work.

Corey shared a link to his blog post over on the Win4n6 Yahoo group, and Yogesh responded that he's doing some research along the same lines, as well, with a specific focus on Windows 8 and the AmCache.hve file, which follows the same file format as Windows Registry hives.  Yogesh's blog post regarding the AmCache.hve file can be found here.  Why should you care about this file?  Well, from the post:

This file stores information about recently run applications/programs. Some of the information found here includes Executable full path, File timestamps (Last Modified and Created), File SHA1 hash, PE Linker Timestamp, some PE header data and File Version information (from Resource section) such as FileVersion, ProductName, CompanyName and Description.

This information can be very valuable during analysis; for example, using the SHA-1 hash, an analyst could search VirusTotal for information regarding a suspicious file.  The file reference number from the key name could possibly be used to locate other files that may have been written to the system around the same time.

More Stuff
As I was working on a RegRipper plugin for parsing and presenting the data in the AmCache.hve file, I ran across something interesting, albeit the fact that I have only one sample file to look at, at the moment.  Beneath the Root key is a Programs subkey, and that appears to contain subkeys for various programs.  The values within each of these subkeys do not appear to correspond to what Yogesh describes in his post, but there are some very interesting value data available.  For example, the Files value is a multi-string value that appears to reference various files beneath the Root\Files subkey (as described in Yogesh's post) that may be modules loaded by the program.  This can provide for some very interesting correlation, particularly if it's necessary for your analysis.

Yogesh has been posting some great information over on his blog recently, specifically with respect to Registry and Windows Event Log artifacts associated with USB devices connected to Windows 8 systems.  Be sure to add it to your daily reading, or to your blog roll, in order to catch updates.