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.

Something I picked up on recently (albeit not directly at the SANS Summit) was how to determine if a password had been set on a system, when all you have is an image to analyze. Brendan has provided tools to use with Volatility to extract Registry hives from Windows XP memory dumps, and subsequently to extract hashes, but what if you only have an image of a system? Well, one of the user flags extracted by the RegRipper samparse plugin is "Password not required"...now, this does NOT mean that the account doesn't have a password.

What I got from someone at MS is as follows:
That specifies that the password-length and complexity policy settings do not apply to this user. If you do not set a password then you should be able to enable the account and logon with just the user account. If you set a password for the account, then you will need to provide that password at logon. Setting this flag on an existing account with a password does not allow you to logon to the account without the password.

Another thing you can do is extract the System and SAM hives and run them through SAMInside. If you like CLI tools better, try using pwdump7...it's got the same functionality.

Where something like this won't work is when the system is accessed by domain users, as their user account information isn't stored in the local SAM hive file.

Not too long ago, I blogged about using the Parse::Win32Registry module to parse raw Registry files, specifically the SAM file.

Since then, I've added to the code a bit, so that not only does it retrieve user information, but group membership info, as well. In this way, it's similar to the ProDiscover ProScript I use to do the same thing, only SAMParse works on the raw Registry file, and can be used when exporting the SAM file from your image. It also works on the SAM files located in the Windows XP System Restore Points. It's a useful tool and requires some additional testing, but for the most part it does provide me with a view into a Windows system that I wouldn't otherwise have.

As a side note, I've also written a tool that parses the audit policy from the Security file, returning information similar to what you can view on a live system using auditpol.exe. When combined with other information from the Registry, this lets me know what I should expect to see in the Event Logs.

Both of these scripts, and others, are provided on the DVD that comes with my upcoming book, "Windows Forensic Analysis", due out from Syngress/Elsevier this spring. The scripts will be provided as Perl code, as well as standalone executables 'compiled' using Perl2Exe.