In which registry key does Windows store information about each user with an account on the computer?

Connected USB Devices

Windows® keeps a history of all connected USB removable storage devices (thumb drives, iPods, digital cameras, external HDD, etc.). This information is vital to know which devices were previously (or currently) connected to the suspect’s machine and by which user.

Windows® stores USB history-related information using five registry keys, and each one offers a different set of information about the connected device. When combining this information, investigators can formulate a clear view of how a suspect has used removable storage to commence an incident.

Windows registry stores information about each USB connected device in the following registry keys:

HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\ENUM\USBSTOR: This key keeps a list of all USB storage devices that have ever been plugged into the system. It shows the USB device name, vendor name (manufacturer name), device serial number (note that if the second character of the device serial number is “&” it means the connected device does not have a serial number). See Fig. 6.46 for a list of previously connected USB devices on an author machine.

HKEY_LOCAL_MACHINE\SYSTEM\MOUNTEDDEVICES: The MountedDevices subkey stores the database of mounted devices for the NTFS file system. This database matches the serial number of a USB device to a given drive letter or volume that was mounted when the USB device was inserted.

HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\EXPLORER\MOUNTPOINTS2: This key will hold information that states which user was logged into Windows® when a specific USB device was connected.

HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\ENUM\USB: This key views the USB device interface GUID, hardware ID, device class information about your device, and the last time this USB was connected to the current machine (see Fig. 6.47).

Check this file at C:\Windows\inf\setupapi.dev.log for Windows® Vista, 7, 8, and 10. On Windows® XP this file will be located at C:\Windows\setupapi.log. Keep in mind that you need to open this file and search for a particular USB device through its serial number to find when it was first connected to the system (see Fig. 6.48).

If you want to automate your work with USB mass storage discovery in Windows® OS, you can download a free tool by nirsoft that can perform all the manual tasks we already did called USBDeview. According to its creator, “USBDeview is a small utility software that lists all USB devices that currently connected to your computer, as well as all USB devices that you previously used. For each USB device, extended information will display: Device name/description, device type, serial number (for mass storage devices), the date/time that device was added, VendorID, ProductID, and more…” This tool can be downloaded from http://www.nirsoft.net/utils/usb_devices_view.html (see Fig. 6.49).

In Fig. 6.49, the Last Plug/Unplug Date represents the first time that the device was connected to the system. This date does not change when the same device is repeatedly reinserted. The second date appears: Created Date represents the last time that the same device was attached to the system.

Note that not all USB devices are connected and leave traces in Windows registry as we already described. Some modern USB devices use a media transfer protocol (MTP) when connecting with computers. New Android versions, Windows phones, and Blackberry all use this protocol, which does not leave traces in Windows registry keys we already talked about. For example, when an Android smartphone is connected to a computer running Windows® using the MTP, the Android device will not expose its contents to Windows® as USB mass storage, allowing it to have access to its raw file system. Instead the Android device will only allow Windows® to have access to a short list of media files that Windows® can see. If Windows® requests a file, the phone will respond by sending the file over the MTP connection.

What we want to conclude from this brief discussion is that USB devices connected through a MTP connection do not leave traces on the previously mentioned USB storage device registry keys. However, there are some forensic tools that can reveal such connected devices. Check your computer forensic tool feature list for such functions. Nicole Ibrahim has conducted research about MTP devices as a series of blog posts, which can be found at http://nicoleibrahim.com/part-1-mtp-and-ptp-usb-device-research.

Windows Registry Recovery

The Windows Registry Recovery (WRR) from MiTeC is a tool that I like to use if I simply want to view the contents of a Registry hive file. One of the things I like about WRR is that the interface is very similar to that of RegEdit, and as such, it’s nice to be able to operate in a familiar environment.

When you first launch WRR and open a hive file, you’ll be presented with an interface similar to what is shown in Fig. 2.3.

On the left-most side of Fig. 2.3, you’ll notice that there are several “Explorer Tasks” available, which can be very useful for collecting and parsing specific data from specific hive files. Clicking on any of the available buttons will populate a view with the data retrieved from the hive. Something to be aware of is that the buttons do not pertain to actions that work for all hives. For example, with a Software hive loaded, clicking on the “Windows Installation” button will populate a view similar to what is seen in Fig. 2.4, because the information is available in that hive. Clicking on the “Hardware” button, however, will populate a view that simply states “” because the necessary information is found in the System hive, not the Software hive.

The Explorer Task functions act as parsers (discussed later in this chapter), albeit without any specific indicators as to the hives to which they apply. Even so, these functions can still be very revealing to an analyst, providing insight into components and information available from various hive files. The information these functions can retrieve is not extensive but it can be informative.

WRR also has a pretty good search capability, or “Find” function that can be very useful when looking for indications of specific artifacts or indicators within a hive file. With a hive opened in WRR, and the “Raw Data” view opened, click on the button with the magnifying glass icon to open the Find dialog, as illustrated in Fig. 2.5.

Once the dialog is open, enter your search term, select what structures you want searched (keys, values, data), and click “Find Next”. Depending upon how large the hive file is, the search can take several minutes. When the search is complete, any hits will be displayed in the bottom-most pane in the WRR user interface, and double-clicking on any of the hits will cause that location to be opened for viewing. I’ve used this search functionality to look for globally unique identifiers (GUIDs), key and value names, as well as portions of text that may occur within value data.

Something else that’s very useful about WRR is that with the “Raw Data” view open, you can right-click on a key, choose “Properties,” and view information about the key, such as the index, the relative offset of the key structure within the hive file, and the LastWrite (or “Date Modified”) time.

Perhaps my most prevalent use of WRR is to use it in conjunction with other analysis processes, such as to view the values and data within a specific key of interest during timeline analysis (more information regarding timeline analysis will be presented later in the chapter). Knowing that a key was modified at a specific time is very helpful, but it can be even more helpful to understand either what values and data are beneath that key, or what was actually modified. I’ve also used WRR to browse through a hive file after other analysis processes have completed, looking for data that may be of use. This is usually a less specific approach, but often results in interesting findings that I can incorporate into other, future analysis. For example, in one instance, I found that specific information about a particular model of cell phone had data stored within the Software hive of the system to which it had been connected, and that information included the electronic serial number, among other things. There have also been times where I’ve discovered information about other Registry keys and values that were unrelated to the case at hand but may be useful during future analysis.

As mentioned, a drawback of WRR is that there is nothing that identifies to which hives the specific data extraction applies. What I mean by that is that if you open a Software hive in WRR and click the “Services and Drivers” button, you will be presented with a “Services” and a “Drivers” tab, both of which will be empty. Some of the buttons will display “no information found” if the hive file does not contain the information that the function is attempting to retrieve. This functionality can be very useful, if you are aware of what data is being retrieved, and from which hive file.

Another drawback of WRR is that it doesn’t handle “big data” at all. What I mean by “big data” is binary value data types that are larger than 2 or 3 KB. Now, there aren’t many values that have “big data”; there is one that many forensic analysts look to (the ShimCache or “AppCompatCache” data, which we will discuss in greater detail in chapter Analyzing the System Hives) for clues, and it’s clear that WRR doesn’t handle that data. Not only does it not parse it and display it in a more readable manner, but it doesn’t properly read the data within the hive so that it can be exported from the hive and parsed with another tool.

The Windows Registry is a veritable treasure trove of data that can be valuable, or even critical, to an investigation. As such, analysts need to have some familiarity with the Registry, and what can be found within the various hive files. Other resources have provided considerable background information on the Registry itself, as well as what can be found within the Windows XP Registry hive files. Every new version of Windows brings a new application-level structure to the Registry, and this information needs to be explored, documented, and understood.

Windows Registry

The Windows registry is a database storing settings for a computer defining all the users; applications; and hardware installed on the system; and any associated settings, allowing the system to be configured correctly at boot-up. The registry is stored in a format that requires decoding to be read; there are numerous tools that can do this. Once opened it provides a wealth of information including, but is in no way limited to, evidence of the applications and files a user has opened; what devices were connected; and the IP addresses used.

Publisher Summary

The Windows Registry is a core component of the Windows operating systems and it maintains a considerable amount of configuration information about the system. The Windows Registry contains a great deal of extremely valuable information that can provide significant context to a wide range of investigations. All the information can be extremely valuable to a forensic analyst, particularly when attempting to establish a timeline of activity on a system. This chapter illustrates how valuable a forensic resource, the Registry, can really be during Malware, intrusion, or data breach examinations. A wide range of cases would benefit greatly from information derived or extracted from the Registry if the analyst is aware of the information and how to best exploit or make use of it. There are many Registry values that can have a significant impact on how the system behaves. The approach to Registry analysis has traditionally been one of looking at a specific key or at several specific values, and this approach has long been reflected in commercial tools. Commercial forensic analysis applications tend or attempt to represent the Registry in much the same manner, as one would expect to see it on a live system. The analysis plan can lead the analyst directly into documenting the analysis process itself. It is important to understand the binary structure of the Registry so that one knows Registry viewing applications.

From the Case Files: The Windows Registry

The Windows Registry helped law enforcement officials in Houston, Texas crack a credit card case. In this case, the suspect's stolen credit card numbers were used to purchase items from the Internet. The two suspects in this case, a married couple, were arrested after a controlled drop of merchandise ordered from the Internet. Examination of the computer's NTUSER.DAT, Registry, and Protected Storage System Provider information, found a listing of multiple other names, addresses, and credit card numbers that where being used online to purchase items. After further investigation, investigators discovered that these too were being used illegally without the owners consent.

The information recovered from the registry was enough to obtain additional search warrants. These extra searches netted the arrest of 22 individuals and lead to the recovery of over $100,000 of illegally purchased merchandise. Ultimately, all of the suspects plead guilty to organized crime charges and were sentenced to jail time.

From the case files: the Windows registry

The Windows Registry helped law enforcement officials in Houston, Texas, crack a credit card case. In this case, the suspect’s stolen credit card numbers were used to purchase items from the Internet. The two suspects in this case, a married couple, were arrested after a controlled drop of merchandise ordered from the Internet. Examination of their computer’s NTUSER.DAT, Registry, and Protected Storage System Provider information found a listing of multiple other names, addresses, and credit card numbers that were being used online to purchase items. After further research, investigators discovered that these also were being used illegally without the owners’ consent.

The information recovered from the registry was enough to obtain additional search warrants. These extra searches netted the arrest of twenty-two individuals and led to the recovery of more than (100,000 in illegally purchased merchandise. Ultimately, all of the suspects pleaded guilty to organized crime charges and were sentenced to jail time.

Introduction

The Windows Registry is a core component of the Windows operating systems, and yet when it comes to digital analysis of Windows systems, is perhaps the least understood component of a Windows system. This may be due to how little information seems to have been written on the subject; however, if you spend just a little time looking around, you’ll find that there has actually been quite a bit of information regarding the Windows Registry documented. This apparent disparity may be due to the fact that most of the commercial forensic analysis applications do little more than open the Windows Registry in a viewer-type application and do not provide for the application of previously developed (from the analyst’s most recent case, or provided by other analysts) intelligence to the available data. Whatever the reason, my purpose for writing this book is to illustrate the vital importance of the Windows Registry to digital forensic analysis. This is not to say that the Windows Registry is the only aspect of the system that requires attention; nothing could be further from the truth. However, the Windows Registry can provide a great deal of valuable information and context to a digital examination, and as such, there is a particular value in addressing this topic in a book such as this one.

The Windows Registry maintains a great deal of configuration information about the system, maintaining settings for various functionality within the system (ie, may be enabled or disabled). In addition, the Registry maintains historical information about user activity; in order to provide the user with a “better” overall experience, details about applications installed and accessed, as well as window positions and sizes, are maintained in a manner similar to a log file. All of this information can be extremely valuable to a forensic examiner, particularly when attempting to establish a timeline of system and/or user activity. A wide range of cases would benefit greatly from information derived from the Registry, if the analyst were aware of the information and how to best exploit it for the purposes of their examination.

What’s in the Registry?

The first thing to keep in mind when conducting Registry analysis is that not everything can be found there. Believe it or not, one particular question that I still see asked is, “Where are file copies recorded in the Registry?” Windows systems do not record file copy operations, and if such things were recorded, I’d think that some other resource (Windows Event Log, maybe) would be far more suitable.

Not everything is recorded in the Registry, but the Windows Registry is still an incredibly valuable forensic resource.

Information in the Registry can have a much greater effect on an examination than I think most analysts really realize. There are many Registry values that can have a significant impact on how the various components of the system behave; for example, there is a Registry value that tells the operating system to stop updating file last access times, so that whenever a file is opened (albeit nothing changed) for viewing or searching, the time stamp is not updated accordingly. And oh, yeah…this is enabled by default beginning with Windows Vista and is still enabled by default on Windows 7 and Windows 8 systems. Given this, how do examiners then determine when a file was accessed? Well, there are other resources, both within the Registry and without (Jump Lists, for example) that can provide this information, particularly depending upon the type of file accessed and the application used to access the file.

A few examples of Registry values that can impact an examination include (but are not limited to) the following:

Alter file system tunneling (specifics of file system tunneling can be found online at http://support.microsoft.com/kb/172190) behavior, or the updating of last accessed times on files and folders

Have files that the user deletes automatically bypass the Recycle Bin

Modify system crash dump, Prefetcher, and System Restore Point behavior

Clear the pagefile when the system is shut down

Enable or disable Event Log auditing

Enable or disable the Windows firewall

Redirect the Internet Explorer web browser to a particular start page or proxy

Automatically launch applications with little to no input from the user beyond booting the system and logging in

All of these Registry settings can significantly impact the direction of an investigation. In a number of instances, I have found valuable data in the pagefile (such as responses from web server queries) that would not have been there had the pagefile been cleared on shut down. When examining a Windows system that was part of a legal hold (an order was given to not delete any data), it can be very important to determine if the user may have cleared the Recycle Bin, or if the system was set to have deleted files automatically bypass the Recycle Bin. The use of application prefetching, which is enabled by default on workstation versions of Windows (but not server versions, such as Windows 2008 R2), can provide valuable clues during intrusion and malware discovery cases.

These are just a few examples; there are a number of other Registry keys and values that can have a significant impact (possibly even detrimental) on what an analyst sees during disk and file system analysis. Some of these values do not actually exist within the Registry by default and have to be added (usually in accordance with a Microsoft (MS) Knowledge Base (KB) article) in order to affect the system. At the very least, understanding these settings and how they affect the overall system can add context to what the analyst observes in other areas of their examination.

Registry Values and System Behavior

The Windows Registry contains a number of values that significantly impact system behavior. For example, an analyst may receive an image for analysis and determine that the Prefetch directory contains no Prefetch (∗.pf) files. Registry values of interest in such a case would include those that identify the operating system and version; by default, Windows XP, Vista, and Windows 7 will perform application prefetching (and generate ∗.pf files); however, Windows 2003 does not perform application prefetching (although it can be configured to do so) by default. The Prefetcher itself can also be disabled, per MS KB article 307498 (found online at http://support.microsoft.com/kb/307498). This same value can be used to enable or disable application prefetching.

The purposes of this book are to draw back the veil of mystery that has been laid over the Registry, and to illustrate just how valuable a forensic resource, the Registry, can really be during malware, intrusion, or data breach examinations, to name just a few. The Windows Registry contains a great deal of information that can provide significant context to a wide range of investigations. Not only that, but there are also a number of keys and values, as we’ll discuss later in this book, in which information persists beyond that deletion or removal of applications and files. That’s right…if a user accesses a file or installs and runs an application, the indications of these actions (and others) will remain long after the file or application has been removed and is no longer available. This is due to the fact that much of the “tracking” that occurs on Windows systems is a function of the operating system, of the environment, or ecosystem in which the application or user functions. As such, much of this activity occurs without the express knowledge of the user or application…it just happens. Understanding this, as well as understanding its limitations, can open up new vistas (no pun intended) of data to an analyst.

Data Types Supported in the Windows Registry

The Windows Registry stores values of keys as data. Data types define what kind of data can be stored in the Registry. There are five main data types:

REG_BINARY Stores the value as binary data of 0’s and 1’s but displayed in hexadecimal format. Information about most hardware components is stored as binary data.

REG_DWORD Represents the data as a four-byte number and is commonly used for Boolean values—for instance, 0 is disabled and 1 is enabled. The data is displayed as a 32-bit (four-byte) long hexadecimal number.

REG_EXPAND_SZ A variable-length data string. It is replaced by applications or services when they use this data. This value usually contains the file path associated with the application or service.

REG_MULTI_SZ A multiple string used to represent values that contain lists or multiple values; each entry is separated by a NULL character.

REG_SZ A standard fixed-length string, used to represent human-readable text values.

Warning

Microsoft recommends that you not edit the Registry unless you have no other way of changing the system configuration. You can perform most configuration changes using alternative methods. Incorrectly editing the Registry can result in an unstable system, or a system that won't even start. Use of the Reg command and the Regedit.exe or Regedit32.exe utilities should be left to experienced administrators or programmers only. Even if you need to change something in the Registry, first test the effects of these changes in a test lab.

When working with the Windows Registry from the command line, you will need to understand the notations for Registry keys and data types. The commands for the Reg utility also require that you know the correct path to the Registry subkey in order to view or change the stored values. For example, if you want to work with the Print Spooler service, you should know where it is located in the Registry structure. The correct path to the Print Spooler service is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Spooler. The path you would use with a particular Reg command would be HKLM\ System\CurrentControlSet\Services\Spooler. We will discuss some of the common tasks associated with the Windows Registry in the following sections.

Registry

Windows relies on the Windows registry as the primary configuration store for most system settings. The registry is comprised of several files that contain both system-specific and user-specific settings. The registry is arranged in a hierarchical format and is split into five trees (also called hives). These trees are:

Hkey_Classes_Root

Hkey_Local_Machine

Hkey_Users

Hkey_Current_User

Hkey_Current_Config (Only in some versions)

Corporate Memo…

The Windows registry is technically stored as a database in binary format, which leads to faster load speeds and data queries. In addition, the registry supports permission-based editing, which is effectively the application of an access control list (ACL) on the registry itself. Modifications to the registry can be done via the Registry Editor, command-line tools, or through applications using the registry. The Windows Registry Editor also supports imports and exports as well as direct editing of the registry through the use of .REG files.

Many enterprise applications store their configuration information in the Windows registry, in local .XML files, or internal application-specific configuration stores. In the case where this information is stored in the registry, the enterprise applications administrator will need to understand in which hive the configuration is stored, what the various configuration options control and how to navigate to and change these settings. It is also important to understand how individual user accounts use the registry settings especially in a Terminal Services or Citrix environments. When configuring user-specific application settings saved in the Windows Registry, a Terminal Services environment could require logon and logoff scripts that import and export the registry settings.