The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics",
as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".

Thursday, April 05, 2012

New Tools, Registry Findings

Zena Forensics: Recipe -Recipes are cool. I like to cook. Not everyone cooks the same way...if they did, how much fun would that be? Not long ago, on a blog not far away, I ran across a "recipe" where someone used some of the scripts I wrote for parsing Windows XP/2003 Event Log records, and adapted them to Windows Vista+ Windows Event Logs, by tying in MS's LogParser.

LogParser is an extremely useful tool. I recently sought some assistance on the Win4n6 Yahoo group with getting LogParser to spit out Windows Event Log records TimeGenerated times in UTC format, rather than local time (from my analysis system). This was an important issue in some testing I was doing recently,

The key element was the bolded statement. Using this statement, I didn't have to reset my system clock to GMT time, or add more "moving parts" or do anything else that would have potentially led to errors.

What I really like about this recipe is that the author needed to do something, needed to do something that he may not have had the ability to do through commercial tools, and did it. Not only that but he did it open source, and provided it for others. Great job, and I, for one, greatly appreciate the fact that the author decided to share the script.

RegRipper Plugin Maintenance Script - Recently, Corey Harrell and Cheeky4n6Monkey (why does that name make me think of the episode of "Family Guy" where Chris and Peter made up the "Handi-Quacks" cartoon??) put their heads together and come up with a very interesting tool. In short, the apparent back-story is that Corey mused how "it would be cool" to have a tool that would run through the RegRipper plugins directory, as well as the profiles, and see which plugins were available that had not been included in a profile. Cheeky took this and ran with it, and came up with the RegRipper plugin maintenance script.

Up to this point, per Windows Registry Forensics, you could view a listing of plugins a couple of ways. One is to use rip.pl/.exe at the command line; the following command will print out (to STDOUT) a list of available plugins:

rip.pl -l

If you add the "-c" switch, you can get that listing in .csv format.

The other way to view the plugins is to use the Plugin Browser, which is a graphical tool that lets you browse the available plugins, as well as create your own profile.

As with the recipe listed in the first part of this post, I greatly appreciate the effort that went into creating this script, as well as the fact that it was provided to the community at large. You can download the script from Cheeky's site, or you may see it referenced at Brett's RegRipper site. I also think that this is a great benefit to the community, as I'm sure that there are folks out there who didn't even know that they could use this script, but will end up finding it to be extremely valuable.

Registry Findings
A while back, I wrote some code to parse Windows 7 Jump Lists, and as part of my research for that project, I ran into volume GUIDs (within the LNK format TrackerData block), which are based on the UUID v1 format specification, detailed in RFC 4122. Two of the pieces of information of interest that can be parsed from the GUID are a time stamp, and a MAC address.

I recently caught something online that indicated to me that there might be other opportunities to make use of the work that I'd already done. Specifically, some of the values beneath the MountedDevices key (those that begin with "\??\Volume"), as well as some of the subkeys beneath a user's MountPoints2 key, are volume GUIDs maintained in the UUID v1 format. We already know that these two pieces of information are used to help us map the use of USB devices on systems, so how does this initial information about the GUID format help us?

The usefulness of the MAC address should be somewhat intuitive. Perhaps more than anything else, what this means is that the MAC address is, in fact, stored in the Registry...not so much "stored" in the sense that there's a value named "MAC address", but more so in the sense that it's there. Testing using a live system corroborates the fact that a MAC address is used; I say "a" because my testing system is a laptop, and has a number of IPv4 interfaces (LAN, WLAN, VirtualBox). Interestingly, one of the MAC addresses that appeared in several GUIDs was from VMWare, which had been installed at one point on my system (I removed it). As entries from the UserAssist key showed when I had installed VMPlayer (launched the installer), I had a time frame that pertained to when the device(s) could have been used.

Note: Over on the Girl, Unallocated blog, Case Experience #2.4 illustrates some good examples of the volume GUIDs, from both the MountedDevices key, and the user's MountPoints2 key.

In a couple of cases, I found devices...specifically, the laptop's built-in hard drive and DVD/optical drive...where the node identifier didn't correlate to a MAC address from my system. This was an interesting finding, but not something that really needs to be run down at the moment.

What this demonstrates is that the MAC address of a system is, in fact, recorded in the Registry, albeit not necessarily as a value named "MAC address".

More research is required regarding the time stamp.

Addendum, 20120410: Testing indicates that the time stamp points to the boot time for the boot session during which the device was connected.

7 comments:

JimmyWeg
said...

While we’re somewhat on the subject, correlating MP2 with MDs could be perilous in some cases with respect to dates (Win 7). For instance, two USB drives have the same signature (happens regulalry). One shows up in MDs, with a GUID. The GUID is in MPs, but which drive does it represent? So, you look at Enum\USB and find the serial number of one of the portable drives. But, if you’re not careful and don’t look at every USB key, you may not realize that each has the same date stamp, perhaps because of the reported “service pack anomaly.” (USBSTOR keys seem to suffer the same issue in such a system, but DeviceClasses does not.) Sure, you can draw some inferences from a host of timeline objects, but one may not leap beyond a look at the correct Enum\USB key.

Can you clarify what you mean by "signature"? Do you mean serial number (extracted from the device descriptor) or unique identifier (generated by Windows when the device does not have a serial number)?

One shows up in MDs, with a GUID. The GUID is in MPs, but which drive does it represent?

I think I see what you're saying here...although I haven't actually seen it myself.

...you may not realize that each has the same date stamp...

I guess it all depends on what you're trying to demonstrate. According to Rob's guide over on the SANS site, the subkey LastWrite times beneath the USB key correspond to the the first time the device was connected during the most recent boot session.

IMHO, it's great that you brought this up, as I think that even with all of the documentation that's out there and available on USB device analysis, a lot of analysts seem to have missed the boat. I see posts in lists and receive emails from folks who seem to believe that USBStor subkey LastWrite times tell you when the device was last connected...and that simply is not the case.

If you happen to have an exemplar Windows 7 system that demonstrates what you mention in your comment, would it be possible to get a copy of the Software, System, and NTUSER.DAT hives?

I received the hives...thanks...and I'll take a look at them, as soon as I finish the comdlg32 plugin updates.

I think that this comment thread raises an excellent point...analysis has to be about process. The materials we're referring to (Rob's guides) include two Registry keys used for determining the device last connected time. If one fails, document that information, share it with the community, or more specifically Rob, and then see what we all can do to address the issue.