WFA slashdotted!

Yes, WFA was slashdotted! Thanks to Don for the review!

In the past (Aug 2004), Richard Bejtlich showned a correlation between a book review appearing on Slashdot.org, and higher traffic to his blog, as well as "better" numbers at book vendors sites. Hopefully I can expect to see a similar effect...

Addendum, 1 April
Okay, this isn't a joke...here's a portion of the WFA page on Amazon from today (1 April 2008), prior to 3pm EST:






Comparatively speaking, "Windows Forensics and Incident Recovery" is listed as follows:





All in all, pretty cool. ;-)

Registry Analysis - What Is It??

That's right...what is this thing we call "Registry analysis"? When someone performs "Registry analysis", what are they doing?

Okay...raise your hand if, for you, Registry analysis consists of looking for strings (using strings, or BinText, or your favorite tool), or maybe using grep() to do regex searches for IP addresses, email addresses, or something else.

Great, thanks. You can put your hands down.

Now, raise your hand if when performing Registry analysis, you open the hive files you're interested in with one of the popular Registry viewers (EnCase, FTK, ProDiscover, or even good ol' RegEdit), and "look around for anything interesting". Keep it up there if you use some sort of checklist or spreadsheet of Registry keys that may be of interest for your case or exam.

Okay...great. Go ahead and put your hands down.

So, what's wrong with either of these methodologies? Cumbersome? Inefficient? In some cases, ineffective? Ever wonder what you're missing? How about...A LOT?

The fact of the matter is, I really believe that Registry analysis isn't being performed today nearly as much as it should because it isn't "easy". I mean, sure, you've got this file that contains all this data, all this potential "evidence" (depending upon the audience, of course), but you don't know (a) how to get it, and maybe even (b) how to interpret it. After all, Registry viewers don't give you what you need, do they? They just present the data as is...it's up to you, the investigator or analyst to make heads or tails of it.

What if you just want to get the most recent document accessed...not just by the user, but via various applications, such as RealPlayer, maybe an image viewer, Excel, Adobe Reader, or even just by one of the common dialogs? If you're just looking for documents accessed, there are a LOT of places to look in the Registry...and using a checklist can take a long time. Also, due to encoding used by various vendors, regular ASCII/Unicode string searches won't work. So what if your "checklist" could be run against the Registry hive file itself?

What about those times when you have to correlate between multiple Registry keys, such as when you're trying to find out about those installed BHOs, or trying to determine when a USB thumb drive was last plugged into the system? How cumbersome is that?

How would you like to rip through your Registry analysis, getting just what you need, presented in the way you need it, or at least a way that's usable? Forget spreadsheets and checklists...how about plugins (stuff like Nessus and Metasploit use plugins, right?) that reach out and get what you want? How about...in order to update this tool, plugins just need to be dropped into a directory, and they're ready to use? How about it this all came with a GUI and a nice "FindAllEvidence" button?

What if you could also get timestamped data (ie, most recently accessed documents, UserAssist entries, etc.) so that you could import it into a format such as Excel, or even XML (for use with Simile TimeLine)?

Know what's really cool about the timestamped data? In order for it to be placed in the user's Registry hive file (NTUSER.DAT), the user account needs to be logged into the system. Sounds pretty simple, doesn't it? Hit most public lists, though, and you'll see questions such as, "how do I tell when a user was logged on if auditing of logon events isn't recorded in the Security Event Log?" (I'm paraphrasing, of course). Well, in most cases, when someone logs on, they do something...right? Look at all of the user activity that is recorded (I say 'recorded" because in many ways, the Registry is a log file, of sorts) in the user's hive file...and then correlate that to other activity (Internet browser history, etc.) that may be available.

Sound pretty cool? How about flippin' sweet?!?

The fact is, there's "lookin' at" the Registry, and then there's doing real Registry analysis and getting the data you need.

Addendum
Some might be wondering, "What is it about Registry analysis that's so hot? After all, I get all of the information/evidence I need from the file system." Well, I can only speak to those things that I've determined through Registry analysis...logon history, files accessed, files NOT accessed, applications that had been installed, run, and then uninstalled, etc. There is a great deal of information...much of it historical, much of it associated in some way with a time stamp...right there in the Registry.

Addendum, 1 Apr
Okay, this isn't a joke...but I added three plugins to the RegRipper last night. One for the Uninstall key in the Software hive (all entries sorted based on the key LastWrite times), as well as one for the USBStor key, and another for the DeviceClasses keys...both in the System hive.

Adding a plugin for the Protected Storage System Provider is going to be problematic until I get some info how to decrypt the data in the "Item Data" values.

New WFA Review Posted

Rob Lee posted a review of Windows Forensic Analysis today...check it out!

I have to tell you, it's a good one! Rob really hits home with some very important points about the book, particularly regarding flow. That's something I'll have to work on for 2/e. That's right...a second edition. I plan to make it more than an update, more than just adding new stuff. One of the problems I see with the current edition is like Rob said...flow. How does one sit down and find something more than just information about a tool or file? Sure, books have indexes (hint, hint) and that's a great place to start, but talking about how Prefetch files or a particular Registry key is useful will only get you so far. What I need to do is figure out a way to tie this all together into something that describes how to use this stuff in an actual...you know...examination. After all, that's the point, isn't it?

I do have some thoughts and ideas on where to go, but to be honest, I'd really like to hear from folks regarding what might work.

Event Log Analysis

In keeping with the Getting Started posts, I wanted to include something that may be of interest with regards to finding corroborating artifacts when performing computer forensic analysis.

Many times, when performing CF analysis, we end up trying to find out when a particular user may have logged into a system, or into a Windows domain. There may be other artifacts, as well, that may lead us to the Windows Event Log (right now, I'm just talking about the Windows 2000, XP, and 2003 Event Logs). There are a number of different ways to go about this, using the commercial tools such as EnCase and ProDiscover, but sometimes the analyst may want to extract the .evt files from the acquired image and parse them. In such instances, the Windows API (used by the Event Viewer and a number of other tools) may report that the .evt file is "corrupted".

This has happened enough to others that I don't even bother any longer, and instead resort to tools such as EvtUI, a GUI-enabled Perl script based on the Evt2Xls Perl script that I wrote to parse .evt files on a binary basis, by-passing the MS API and producing something a bit more usable. EvtUI runs against an .evt file and parses out all of the event records into an Excel binary-compatible spreadsheet. The Time_Generated field of the event record structure is formated so that it can be used to sort on in the spreadsheet. EvtUI also produces a report file, which gives the analyst an overview of the .evt records based on the frequency of the various sources and event IDs. I found this particular functionality useful enough that I pulled it out into its own tool (I call it "evtrpt") and added a frequency count for event types (Info, Warning, Error, Success, and Failure). The report file also gives you the date ranges of all of the event records.

Another thing that EvtUI lets the analyst do is enter exceptions. I've seen instances with really large .evt files (when combined with an extremely verbose audit configuration) where .evt file will have more than 65,535 records...and this is the limit of entries for Excel. So, the analyst can run EvtUI once, and then check the report...if there are more than 65,535 records, she can choose event IDs to enter as exceptions and then re-run EvtUI.

Now, once you've gotten this far, the question then becomes, how do you analyze the data you've got? Well, what you look for depends not only on your case, but what's being audited (which you can see very easily by parsing the PolAdtEv value from the Security Registry hive file. This is only a start, though...I suggest that anyone who does or wants to do Event Log analysis check out the following sites:

EventID.net (indispensable and well worth the $24/yr subscription)
Eric Fitzgeralds' blog
Rob "Van" Hensing's Blog
Windows 2000 Security Event Descriptions (pt 1, 2)

Tips
There was an intrusion investigation where the intruder was suspected of having created an account (done in many cases in order to maintain persistence) within the domain. Auditing for logon events was not enabled, but auditing for account management events was...and I was able to quickly find an event ID 624 record showing the creation of the suspicious

Other Resources
EventLogRecord structure
Windows Event Log Reference (Vista, 2008)
GrokEVT (Python-based)
ScreenClean