Registry Analysis (Windows Forensic Analysis) Part 5

Enumerating Autostart Registry Locations

One of the best tools currently available for retrieving information from a great number of autostart locations on a live system is Autoruns, from Microsoft (Version 9.39 is available at the time of this writing from http://technet.microsoft.com/en-us/sysinternals/bb963902.aspx). This is an updated tool that comes in both GUI and CLI versions. Figure 4.12 shows the GUI version of Autoruns.

Figure 4.12 Autoruns (GUI)

As shown in Figure 4.12, Autoruns will retrieve entries from a number of Registry keys and display what it finds. This information provides a quick indicator to the investigator as to whether anything that could be suspicious is running in one of these locations and should be investigated.

Other tools exist for enumerating the contents of autostart Registry locations. One in particular is the Visual Basic script called Silent Runners, which you can find at www. silentrunners.org. The Web site includes a complete list of launch points enumerated by the script, which was first made available to users via NTBugTraq (www.ntbugtraq.com) on May 12, 2004. The script is intended to run on most versions of Windows, including Windows 98, which is outside the scope of this topic. Keep this in mind when running the script, because several of the locations enumerated (in the Registry and within the file system) apply only to those versions of Windows. These locations are pointed out in the listing of launch points.

For postmortem investigations, analysts require tools that allow not only viewing but also enumeration of a Registry that has been reconstructed from the component files with a system image. ProDiscover’s ProScript capability allows the analyst to use Perl scripts similar to those written for live systems to search the Registry on an image during postmortem analysis. Tools such as Autoruns are kept up to date and provide the most comprehensive lists of Registry keys that have some sort of autostart functionality.

AutoRun Functionality

In addition to autostart locations within the Registry, Windows systems also provide something referred to as "AutoRun" or "AutoPlay" capability. You are probably most familiar with this when you put a music CD into your CD-ROM drive, and once you hear the drive spin up, the appropriate application (such as Windows Media Player or RealPlayer) will automatically start and the first track of the CD will play. Another example of AutoRun capability is when you put a software installation CD into the CD-ROM drive and the installation routine automatically starts.

The way this capability works is that on designated drive types, Windows will look for an autorun.inf file in the root of the drive, and if it finds one, it will parse and execute the load= or run= lines within the file. Microsoft has long stated that this behavior is controlled or regulated by the following Registry key:

Within this key, the NoDriveTypeAutoRun value allows you to disable the AutoPlay functionality on specific drive types. The value is a bitmapped value, meaning that each bit within a byte corresponds to a specific drive type, and a "1" at any position disables the AutoPlay functionality on the corresponding drive type. Therefore, a value of 0×95 (149 in decimal notation) disables AutoPlay functionality on removable and network drives, and a value of 0xFF disables the functionality on all drive types.

Warning::

You can find the NoDriveTypeAutoRun value in either the HKLM or HKCU hive. According to Microsoft, if the value exists in the HKLM hive, the value in the HKCU hive is ignored.

On September 11, 2008, Microsoft first published Knowledge Base article 953252 (http:// support.microsoft.com/kb/953252), which stated that for Windows 2000, XP, 2003, and Vista (Windows 2008 was not affected), for the NoDriveTypeAutoRun capability to actually be effective users had to install an additional patch which would add the HonorAutorunSetting value to the \Policies\Explorer key within the HKLM hive, setting it to 0×1. The Knowledge Base article contains a complete treatment of both the NoDriveTypeAutoRun and HonorAutorunSetting values. This was an important issue around the time the Knowledge Base article was published, as variants of the Sality (and later, Conficker) malware would propagate, in part, by writing the malware and an autorun.inf file referring to the malware to the root of every drive found on an infected system. In fact, some variants of Sality were found to infect removable storage devices that were connected to the system long after it was initially infected.

Tools & Traps…

CD-ROMs

In addition to the NoDriveTypeAutoRun value, you can enable the AutoPlay capability for CD-ROM drives by setting the Autorun value in the HKLM\System\CurrentControlSet\ Services\CDRom key to 1 (you can disable it by setting it to 0). According to Microsoft Knowledge Base article 319287 (http://support.microsoft.com/kb/319287), the real function of the Autorun value is to enable or disable media change notifications. If the NoDriveTypeAutoRun value is set to 0xb5, the AutoPlay capability will also be disabled for CD-ROMs. For details on these settings, as well as additional information, see Microsoft Knowledge Base article 330135 (http://support.microsoft.com/kb/330135).

NtfsDisableLastAccessUpdate

Most analysts are aware that Windows systems (as with many operating systems) maintain time stamps on files referred to as "MAC time".What many may not realize is that Windows systems can be configured, through a single Registry value, to not update the file time-stamp data when the file is accessed. You can use the NtfsDisableLastAccessUpdate Registry value to disable this functionality, as a means of increasing the performance of high-volume file servers, as described in Microsoft Knowledge Base article 894372 (http://support.microsoft.com/kb/894372). However, this value is enabled by default on Windows Vista and Windows 7 systems, as illustrated in the output of the disablelastaccess.pl RegRipper plugin shown here:

This can be an important factor to take into account, particularly when performing analysis of Windows Vista and Windows 7 systems, as a lack of file last access time stamps may appear to be a significant obstacle during an examination. This value is not enabled by default on Windows XP and 2003 systems, so its existence, in addition to a value of 1, can be very telling during an examination. Even with this value set, however, as you’ll see later in this topic, there are a number of locations in the Registry where you can find indications of access to files, as well as the type of access.

NukeOnDelete

When users delete files on a Windows XP or 2003 system, in most instances the default behavior is that the Explorer shell will send that file to the Recycle Bin. Users can bypass the Recycle Bin by holding down the Shift key when deleting the file, or by adding the NukeOnDelete value that can be found in the following Registry key in the Software hive file:

Adding the NukeOnDelete value and setting it to 1 effectively disables the Recycle Bin, as deleted files will bypass the Recycle Bin. Therefore, if during an examination you find that there are no files in the Recycle Bin, be sure to check this Registry value to see whether perhaps it has been added and set to 1.

As I mentioned previously, although the binary structure of the Registry has remained the same from Windows NT through Windows 7 beta, keys and values have been found to change between versions of the operating system. For example, the location of the NukeOnDelete value just discussed applies to Windows XP and 2003, and changed with the advent of Windows Vista. On Windows XP and 2003 systems, the BitBucket key is located in the Software hive file, so the setting applied to all users on the system. On Vista and Windows 7, the BitBucket key moved into the user’s hive file (NTUSER.DAT) in the following path:

Whereas Windows XP and 2003 maintained the NukeOnDelete value on a systemwide basis, Vista and Windows 7 provide the functionality on a per-user, per-volume basis.

USB Removable Storage Devices

One of the more popular topics when I’ve presented at conferences has been how to track USB removable storage devices across Windows systems. When I first presented on this topic, there was a lot of the "Hey, I didn’t know you could do that" kind of interest. Since then, I’ve answered or witnessed a continual stream of questions regarding this topic.

When a USB removable storage device, such as a thumb drive, is connected to a Windows system, footprints or artifacts are left in the Registry. (Artifacts are left in the setupapi.log file as well.) When the device is plugged in, the Plug and Play (PnP) Manager receives the event and queries the device descriptor in the firmware (this information is not located within the memory area of the device) for information about the device, such as the manufacturer. The PnP Manager then uses this information to locate the appropriate driver for the device (based on the contents of .inf files) and, if necessary, loads that driver.

(This information is recorded in the setupapi.log file.) Once the device has been identified, a Registry key will be created beneath the following key:

 

Beneath this key, you will see subkeys that look like this:

This subkey represents the device class identifier, because it identifies a specific class of device. The fields represented by ### are filled in by the PnP Manager based on information found in the device descriptor. For example, I have a 1GB Geek Squad thumb drive that I purchased from Best Buy; the class ID for the device looks like this:

You can use UVCView to view the contents of the device descriptor. Figure 4.13 illustrates a portion of the device descriptor for the Geek Squad thumb drive mentioned previously.

Figure 4.13 Portion of a Device Descriptor via UVCView

As you can see in Figure 4.13, the iManufacturer and iProduct information from the device descriptor is mapped to the device class ID.

Note

Microsoft used to provide the UVCView utility as a free download, but has since moved it to the Windows Driver Kit (wDk), per http://msdn.microsoft.com/en-us/library/aa469207.aspx. UVCView is an application that allows an analyst to view the device descriptor information from a USB device; this information is not part of the memory area of a USB thumb drive, for example, and is therefore not retrieved when an image is acquired from such a device.

Once the device class ID has been created, a unique instance identifier needs to be created for the specific device. Notice that in Figure 4.13 there’s a value called iSerialNumber. This is a unique instance identifier for the device, similar to the MAC address of a NIC. This value is used as the unique instance ID for the device so that multiple devices of the same class (e.g., two 1GB Geek Squad thumb drives) can be uniquely identified on the system. From the USB FAQ: Intermediate (www.microsoft.com/whdc/connect/usb/usbfaq_ intermed.mspx):

"If the device has a serial number, Microsoft requires that the serial number uniquely identify each instance of the same device. For example, if two device descriptors have identical values for the idVendor, idProd-uct, and bcdDevice fields, the iSerialNumber field will distinguish one from the other."

Figure 4.14 illustrates a device class ID and subordinate unique instance ID as it appears in RegEdit.

Figure 4.14 Portion of RegEdit Showing Device Class ID and Unique Instance ID

Although a unique serial number is required for devices that manufacturers want to qualify for the Windows Logo program (www.microsoft.com/whdc/archive/usbfaq.mspx#ERCAC), not all devices include a serial number. For devices that do not have a serial number, the PnP Manager will create a unique instance ID for that device, which will look similar to the following:

Notice that the second character is an ampersand (&). If you see a unique instance ID beneath the USBSTOR key that looks like this, you know the device that was plugged into the system does not have a serial number in its device descriptor.

So, if the unique instance ID does not have an & as the second character, you might be able to identify the unique device that was connected to the system. In cases involving multiple systems and storage media, investigators should be sure to include the use of UVCView in their methodology so that the devices can later be tied to the system, not only through Registry artifacts in the USBSTOR key but also in the MountedDevices key as well as in Shortcuts and other references to files located on the system.

Once the unique instance identifier key has been created, the key is then populated with several values, including a FriendlyName. The value of interest to investigators will be the ParentldPrefix value. Microsoft does not provide any information regarding how this value is created or whether this value is unique across Windows systems. However, the ParentldPrefix value can be used to correlate additional information from within the Registry.

For example, using both the unique instance identifier and the ParentIdPrefix, you can determine the last time the USB device was connected to the Windows system. On a live system, you need to navigate to the following key:

You’ll see a number of subkeys beneath this key, all of which are GUIDs. The specific device classes that we’re interested in are {53f56307-b6bf-11d0-94f2-00a0c91efb8b} and {53f5630d-b6bf-11d0-94f2-00a0c91efb8b}. These two classes are defined in the ntddstor.h header file (you can see an example of the header file at www.reactos.org/generated/doxygen/ d1/d09/ntddstor_8h.html) as being the GUIDs for the disk and volume device interfaces, respectively. Navigating to the disk device GUID, we see a number of subkeys with some really long names; referring back to the device illustrated in Figure 4.13, we see a subkey with the following name:

For the purpose of this example, I’ve highlighted the unique instance identifier (in this case, the serial number of the device) to illustrate where within the key name the ID is located. The LastWrite time of this key corresponds to the last time the disk device was connected to the system. This is because when a device is connected to a Windows system, a subkey named "Control" is created; when the device is disconnected from the system, the Control subkey is deleted. Both of these actions cause the LastWrite time of the DeviceClasses key for the specific device to be modified.

We can also conduct the same correlation with the volume device interface GUID, using the ParentIdPrefix for the device, as follows:

Again, I’ve highlighted the ParentldPrefix within the device subkey to illustrate where it can be found. The LastWrite time of this key corresponds to the last time the volume was connected to the system. As with the disk device GUID, a Control subkey is created beneath the volume device GUID, and then deleted when the volume (i.e., the device) is disconnected, causing the key’s LastWrite time to be updated accordingly.

We will cover more information regarding use of the ParentldPrefix to correlate information from the Registry in the "Mounted Devices" section later in this topic.

RegRipper includes several plugins to extract USB removable storage data from the System hive file. The first is the usbstor.pl plugin that parses the contents of the USBSTOR key, listing each of the device classes’ keys, and all of the unique instances of devices within those keys, as illustrated here:

In the preceding excerpt of output from the usbstor.pl plugin, we see a number of devices listed, the first of which is a U3 device (we will discuss these devices in detail in the next section). We also see two Maxtor OneTouch devices listed, and we can surmise that because neither of these has a ParentldPrefix value listed, they are external hard drives rather than thumb drives (and in fact, they are). The devclass.pl plugin retrieves the data we described previously from the DeviceClasses key, for both the disk and volume GUID keys; an excerpt of the output from the disk GUID key is shown here:

Notice that in the output from the devclass.pl plugin the various devices are listed sorted by the LastWrite times of their respective keys. Again, when a device is connected to a Windows system, the device keys beneath the DeviceClasses keys have a Control subkey added, and when the device is disconnected, the Control subkey is removed. These actions cause the LastWrite time for the device key itself to be modified.

Another plugin that I wrote due to a request is the usbstor2.pl plugin. Like all other plugins, this plugin can be run as part of RegRipper, but it was intended to run with rip.pl as part of a batch file. I received a request from an analyst who said he had acquired images from 30 systems, and his task was to correlate USB removable storage devices across all 30 systems, looking for a pattern of usage of the devices. To facilitate that, I wrote the usbstor2. pl plugin, which extracts the same information as the usbstor.pl plugin, plus additional information, and presents it in a comma-separated value (.csv) format. Here is an excerpt of the output of usbstor2.pl:

As you can see, the output lists the system name, the device class identifier, the unique instance identifier (or serial number), the key LastWrite time in 32-bit UNIX time format, and the friendly name of the device. The last value is the ParentldPrefix value, if there is one. So, I suggested to my friend that he run the usbstor2.pl plugin via rip.pl, and output each iteration of the command to a single file using redirection:

Once the plugin had been run across all of the System hive files, he could open the devices.csv file in Excel and sort based on the various devices, or system names, or however he chose to look at the data. Had he worked with a Registry viewing application, even one built into a forensic analysis application, it might have taken him days to accomplish what he was able to do in minutes with rip.pl.