Registry Analysis (Windows Forensic Analysis) Part 6

USB Device Issues

USB removable storage devices have long been known (particularly by security professionals) to pose a threat to security, especially within the corporate infrastructure. Since the days of the floppy disk (even back as far as when these things really were floppy!), the amount of storage capacity has increased as the size of the device (the "form factor") has decreased. As I write this, thumb drives with 2GB and 4GB capacity are available on the shelves of many local stores, all at reasonable prices. Want to steal a file from an organization? How about an entire database? And they call these things "thumb" drives; remove the plastic casing and strip the device down to just the circuit board, and you’ve got a "thumbnail" drive that is quite literally the size of a thumbnail.

To make matters worse, these devices are ubiquitous. It used to be that anyone who had a 64MB thumb drive was probably some kind of uber-admin. Now just about everyone has these things and uses them for storing pictures, presentations, and more. How about iPods and MP3 players? We see them in the gym, in the office, on the bus; they’re everywhere. In fact, we’re used to seeing them, so seeing one on a desk, plugged into a laptop, isn’t unusual at all. Right now, you can purchase an 8GB iPod Nano for around $200. If someone plugs one of these into a laptop that’s connected to a corporate local area network (LAN), who’s to know whether the user is listening to music or downloading financial forecasts, compensation plans, contract bids, and other confidential information to the storage device?

Another issue has to do with the AutoPlay functionality mentioned previously in the topic. When a CD or DVD is placed in the drive on a Windows system, the new media is detected, and if an autorun.inf file is located in the root of the drive, it is parsed and the run= and load= lines are executed. This is all part of the enhanced user experience Windows offers. By default, AutoRun functionality is not enabled for removable storage devices such as thumb drives; however, it is enabled by default for what the system believes to be CD-ROMs, which is what part of the U3 device appears to be, due to how it’s formatted. Instructions are available on the Internet that show you how to create your own data and programs to be written over the existing U3 partition, making this an extremely dangerous mechanism for gaining access to systems.

The company U3 provides a utility to give users more mobility with their applications. This utility creates a small partition at the beginning of a thumb drive and marks it as a CDFS (CD file system) partition so that Windows systems recognize the partition as a CD rather than a removable storage device. The utilities (browser and the like) are then run from the CDFS partition, and the rest of the device is used for storage. However, this means that even though AutoRun functionality is disabled (by default) for removable storage devices, it is enabled (by default) for the CDFS partition.

When I connected a U3-enabled thumb drive to my Windows XP system, I found that two separate device class ID entries were created for the same device:

and

Both of these device class IDs had the same unique instance ID subkey beneath them. When you’re performing postmortem forensic analysis, this is definitely something to look for because it might identify an infection vector or method of compromise. Where this comes into play is that an attacker can create a custom ISO image to install into the CDFS partition and then remove all indication of the U3 utilities or logo on the device. If someone plugs that device into a system, the AutoRun functionality for the CDFS partition will kick in, and anything the attacker can conceive of (installing Trojan backdoors, collecting Protected Storage info and other passwords) will be executed automatically.

See the "USBDumper" sidebar for additional information regarding threats posed by removable storage devices. Although not specifically associated with Registry analysis, these threats do pose interesting issues for security professionals.

Tools & Traps…

USBDumper

A utility called USBDumper exposes another security risk associated with USB removable storage devices, but with a different twist (http://wiki.hak5.org/wiki/USB_ Hacksaw). USBDumper is installed on a Windows system, and whenever a USB removable thumb drive is connected to the system, the contents of the device are silently copied off the device. There has also been talk of a utility that silently acquires an image of a thumb drive when it’s connected to a system so that not only can all the currently active files be retrieved, but deleted files can be as well. Both of these issues were mentioned in Bruce Schneier’s "Schneier on Security" blog on August 25, 2006.

Mounted Devices

The MountedDevices key stores information about the various devices and volumes mounted to the NTFS file system. The complete path to the key is:

For example, when a USB removable storage device is connected to a Windows system, it is assigned a drive letter; that drive letter shows up in the MountedDevices key. If the device is assigned the drive letter F:\, the value in the MountedDevices key will appear as \DosDevices\F:. We can map the entry from the USBSTOR key to the MountedDevices key using the ParentldPrefix value found within the unique instance ID key for the device. The ParentldPrefix value for the USB device discussed in the previous section has the data 7&326659cd&0. Note that this is not the unique instance ID and is therefore not the serial number we discussed earlier.

Once we have the data from the ParentldPrefix Registry value, we then locate the drive letter that was assigned to it by locating the DosDevices entry within the MountedDevices key that contains the ParentldPrefix within its data. On a live system, we can do this easily by right-clicking each Registry value and choosing Modify; when the Edit Binary Value dialog opens, we can view the contents of the data to see whether the ParentldPrefix value is there. The ParentldPrefix value is stored in the Registry as a string, but the DosDevices values within the MountedDevices Registry key are stored as binary data types, so some translation is necessary. Figure 4.15 illustrates the Edit Binary Value dialog box for the \ DosDevices\F: entry.

Figure 4.15 Data for the MountedDevices \DosDevices\F: Value

We can clearly see the ParentldPrefix value of 7&326659cd&0 in Figure 4.15. Using the ParentldPrefix value to map between the USBSTOR and MountedDevices Registry keys, we can locate the driver letter assigned to the device. As we continue our postmortem forensic investigation, we might find references in other locations in the Registry or in Shortcut files that point to the F:\ drive. We can then correlate the LastWrite times of the unique instance ID key, the MountedDevices key, and the MAC times on files to develop a timeline.

Warning::

When performing correlation between the USBSTOR and MountedDevices keys using a device’s ParentIdPrefix value, be sure to keep in mind that several devices might have been connected to the system in a serial fashion, and mapped to the same drive letter. I have several different USB thumb drives from different manufacturers and of different sizes, and whenever I connect them to my laptop one at a time they all get mapped to the F:\ drive. When performing this type of correlation, it is important to keep this in mind, particularly when analyzing a Windows XP or 2003 system. As you’ll see later in this topic, Windows Vista and Windows 7 systems offer some additional avenues of analysis as far as mapping a device to a drive letter is concerned.

Looking at the MountedDevices key, you might notice that there are \DosDevices entries (in particular, \DosDevices\C:) whose data is only 12 bytes (three DWORDs) long. Figure 4.16 illustrates an example of this.

Figure 4.16 Data for MountedDevices \DosDevices\C: and D: Values

The binary values shown in Figure 4.16 consist of the drive signature (also known as a volume ID) for the hard drive (first DWORD) and the partition offset (second and third DWORDs). A drive’s signature is located at offset 0x1b8 (440 in decimal) within the Master Boot Record (MBR) of the hard drive.

For the \DosDevices\C: value shown in Figure 4.16 the second and third DWORDs together translate to the hex value 0x7e00, which is 32256 in decimal. Each sector on the hard drive is 512 bytes in size; 32256/512 = 63, so the C:\ partition starts at sector 63.

In looking at the entry for \DosDevices\D: in Figure 4.15, we see that the binary data indicates that the D:\ drive has the same drive signature as the C:\ drive, but a different partition offset. This is because the D:\ drive is another partition on the same physical disk as the C:\ drive. Using the information about the partition offsets, we can compute the C:\ partition to be a little more than 29 GB in size.

To show how to find this information during a forensic investigation, I opened ProDiscover and then opened a sample case. I located the \DosDevices\C: entry in the MountedDevices key in the Registry Viewer and saw that the drive signature was 5D EC 5D EC in hex. I then clicked the cluster view for the case (which starts at 0). Figure 4.17 illustrates an excerpt from ProDiscover, showing a portion of the MBR.

Figure 4.17 Excerpt from ProDiscover Cluster View Showing Drive Signature (5D EC 5D EC)

As Figure 4.17 shows, the drive signature we got from the MountedDevices key is clearly visible at offset 0x1B8.

Why is this important? After all, if we’ve acquired an image of the hard drive, we should already have and be able to verify the drive signature from both the Registry and the MBR. However, where this information becomes useful to us is if there are external hard drives associated with the case. In my "day job" as an incident responder and forensic engineer, I use external hard drives for storing things such as client data, drive images, and log files. I do this because once the case is complete and the final report has been accepted, I can easily wipe the external drive. If I maintained all of this data on my laptop’s hard drive, I would have to wipe the drive and reinstall the operating system and all my applications and data, including PGP keys and the like. Also, as I’m writing this topic, all the files associated with the topic are maintained on a 120GB Western Digital USB-connected hard drive. This device appears in the USBSTOR key with the following device class ID:

As one might expect, this device has a serial number (which I can verify with UVCView), as indicated by the unique instance ID I see in my Registry. However, within the unique instance ID Registry key, there is no value named ParentldPrefix. When the device is plugged into my laptop, it appears as the G:\ drive, and the appropriate information, including the drive signature, is stored in the MountedDevices key. Had this been a case I was investigating, I could then uniquely tie the external hard drive to the system, even though there is no ParentldPrefix value for the external drive.

Values within the MountedDevices key that begin with "\??\Volume" can be tied to a specific user, by navigating to the following key within the user’s NTUSER.DAT file:

Several different types of subkeys are beneath this key, but the ones we’re interested in at this point are those that look like GUIDs; for example, "{d37df1d3-265b-11db-a216-0015c51b9712}". Beneath the MountedDevices key, you should expect to see a corresponding \??\Volume {d37df1d3-265b-11db-a216-0015c51b9712} value, as well. The RegRipper mp2.pl plugin parses the subkeys beneath the user’s MountPoints2 key and lists the entries according to the type of mount point, as illustrated here (emphasis added):

 

 

 

 

 

 

The GUIDs listed under "Volumes:" can then be correlated to the values listed in the MountedDevices key. For example, the RegRipper mountdev2.pl plugin was run against the System hive file extracted from the same system image as the NTUSER.DAT file used earlier, and the following information was displayed (emphasis added):

In this case, the removable storage device with the listed ParentldPrefix value had been mounted as the E:\ drive, and had been accessible to the user from whose profile the NTUSER.DAT file was retrieved. Now, intuitively this makes sense on systems used predominantly by one user; however, on systems with multiple user profiles, it may be important for an analyst to determine which user had access to a removable storage medium.

Tools & Traps…

Data Exfiltration

I’ve received a number of questions both via e-mail and from customers, asking about data exfiltration. In the vast majority of cases, someone has a system (or an image acquired from a system) and wants to know what data was copied off that system, possibly onto a removable storage device. The fact of the matter is that there are a number of means by which a user can copy data off a system, such as by attaching files to Web-based e-mails, using the built-in File Transfer Protocol (FTP) client, and so forth. When you’re looking for indications or "evidence" that files were copied from the system to removable media (e.g., a thumb drive, iPod, etc.), the simple fact is that at this time, there are no apparent artifacts of this process, and you would need to acquire and analyze both pieces of media (i.e., the system that was the source, and the removable media that was the target). Artifacts of a copy operation, such as using the copy command or drag-and-drop, are not recorded in the Registry, or within the file system, as far as I and others have been able to determine.

One caveat to this is that if a user copies data to a thumb drive and then doubleclicks the file that was copied to the thumb drive (say, to verify that it was copied correctly), a Windows shortcut (.lnk) file will be generated in the user’s Recent Documents folder for that file. Although this will provide a great deal of useful information (e.g., time stamps, a file path, etc.), the only information that may indicate that the file was copied from the system to the thumb drive may be the file’s MAC times, which are embedded within the shortcut file itself. Still, no available artifacts clearly indicate that the file was copied from the system to the thumb drive.

Portable Devices

In spring 2008, Rob Lee (of SANS fame) contacted me to tell me he’d found that Windows Vista maintains a history of portable devices within the Software hive file. Although the Microsoft Web site contains a great deal of information with respect to portable device standards, it offers very little information (if any at all) with respect to the following Registry key:

Beneath this key, there may be a number of subkeys whose names appear to be formatted in a similar manner as those beneath the USBSTOR key mentioned previously in this topic. In fact, some of the subkey names may include the word USBSTOR. Within these subkeys, you may find a FriendlyName Registry value that appears to be what you’d see in the My Computer applet when you attach a removable storage device. The port_ dev.pl RegRipper plugin extracts and displays the information from the Devices key, as illustrated here:

Device
LastWrite		Fri Dec 12 03:22:09 2008 (UTC)
SN
Drive		Apple iPod
Device		DISK&VEN APPLE&PROD IPOD&REV 1.62
LastWrite		Fri Sep 21 01:42:42 2007 (UTC)
SN		0 0 0A270018A0E610&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 Jun 28 18:38:28 2008 (UTC)
SN		1100101211329640&0
Drive		Removable Disk (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:)

As you can see, a number of devices have been connected to this Vista system (the output shown is only an excerpt of what is available), to include iPods, digital cameras, and a Geek Squad thumb drive. Also, a serial number (if available) is displayed, as is the FriendlyName value, listed in the output along with Drive:. Of the four devices listed, you can see that they were all mapped to the F:\ drive. I have found on several XP systems that when connecting multiple USB removable storage devices to the systems one at a time in a serial fashion, they all get mapped to the same drive letter. On XP and Windows 2003 systems, this can be a serious shortcoming when attempting to map a removable storage device to the drive letter assigned when it was plugged into the system, as you saw previously in this topic during our discussion of the MountedDevices key. However, with Vista (and Windows 7, it seems), at least a partial history of drive letter assignments appears to be maintained in the Software hive.