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 command I ended up using looked similar to the following:
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:
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.
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 command I ended up using looked similar to the following:
Logparser -i:evt -o:csv "SELECT RecordNumber,TO_UTCTIME(TimeGenerated),EventID,SourceName,Strings from System" > system.csv
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.