Registry Analysis (Windows Forensic Analysis) Part 9

Search Assistant

When a user clicks the Start button in Windows XP and chooses Search, then chooses For Files and Folders, the search terms entered into the dialog box are stored in the following Registry key:

tmp1E1-110_thumb

The ACMru key will generally have some combination of four subkeys: 5001, 5603, 5604, and 5647. The 5001 subkey contains the MRU list for the Internet Search Assistant, the 5603 subkey contains the MRU list for the Windows XP files and folders search, and the 5604 subkey contains the MRU list that corresponds to the "word or phrase in a file" dialog box. The 5647 subkey maintains the MRU list for the computers entered via the "for computers or people" selection in the Search Results dialog. The value names within the subkeys are three-digit numbers. The smallest number (i.e., 000) represents the most recent search, and the LastWrite time associated with the key will give you the time and date that the search was launched. The acmru.pl plugin displays the information within this key, as illustrated here:


tmp1E1-111_thumb

Knowing the purpose of the various subkeys and the way they are populated will give you insight into the user’s activities on the system. This can be useful during investigations that concern what a user was doing and when. In the preceding example, the user searched for various terms such as port* and sol.exe, looking for filenames, and searched for disk as a keyword within files. In one examination of a system compromise in which the intruder had accessed systems via Terminal Services, we saw that he searched for the term bank*.

Search information for "legacy" systems, such as Windows 2000, is maintained in different Registry keys and might be found on the system if it was upgraded from Windows 2000 to XP. The key in question is:

tmp1E1-112_thumb

According to the contents of the HKEY_CLASSES_ROOT\CLSID key, that GUID refers to the File Search Explorer Band, contained in shell32.dll. Two subkeys beneath this key, FilesNamedMRU and ContainingTextMRU, correlate to the 5603 and 5604 subkeys (respectively) found on Windows XP systems.

Connecting to Other Systems

When a user uses the Map Network Drive Wizard (right-click the My Computer icon and choose Map Network Drive) to connect to a remote system, an MRU list is created beneath the following key:

tmp1E1-113

Each entry is given a letter as the value name, and the MRUList value illustrates the order in which the user connected to each drive or share.

Whether the user uses the Map Network Drive Wizard or the net use command, the volumes the user added to the system will appear in the following key:

tmp1E1-114

As mentioned earlier, the MountPoints2 subkeys that appear as GUIDs can be mapped to the \??\Volume entries in the MountedDevices key. These GUIDs can also be mapped to the CPC\Volume subkey beneath the MountPoints2 key.

I’ve used the net use command on my system to perform testing, and when I connect to the C$ share on another system, I see subkeys such as ##192.168.1.22#c$ and ##192.168.1.71#c$.

These IP addresses (I have a flat test network that is not a domain, so the computer names are essentially the IP addresses) also appear in the following Registry key:

tmp1E1-115

This key maintains descriptions of computers that are seen by the network browser. For systems that were part of a domain, it is normal to see several computer names listed in this key. However, for stand-alone systems, such as home users and other systems that are not part of a domain, you likely won’t see values listed for this key. On my home system, only systems that I have explicitly connected to using the net use command appear in this key. I use my work system to connect to my employer’s intranet via a virtual private network (VPN), and several systems that I have connected to appear in the ComputerDescriptions key. One in particular has the description Samba 2.2.7a, indicating that it is a Linux system running Samba. Because this key is found in the NTUSER.DAT file, there could be different entries for different users on the same system.

CD Burning

When dealing with an incident in which a user may have removed data from a system, there are a number of avenues to consider. Did the user copy the file to a USB removable storage device (e.g., thumb drive, iPod, etc.), or did the user send that data out as an attachment to a Web-based (Yahoo!, Gmail) e-mail? Another means of data extraction to consider is XP’s built-in ability to burn CDs. Although many systems come with CD and DVD burning software installed or available (e.g., my Dell systems and my Lenovo ThinkPad came with Sonic/Roxio products installed), Windows XP and Vista have the built-in capability to burn CDs. For Windows XP, this capability is described in Microsoft Knowledge Base article 279157 (http://support.microsoft.com/kb/279157). When the user inserts a blank CD-R or CD-RW into the system, a dialog box will open, offering him the opportunity to Open writable CD folder using Windows Explorer. With that folder open, he can drag files and directories to the folder, which are copied to a special staging area until he is ready to select Write these files to CD. When the user is ready to write the files to CD, a monolithic disk image file named "Cd burning stash file.bin" is created in the staging area. That special staging area is in the following directory on XP systems (by default):

tmp1E1-116

On Vista systems, the default staging area is:

tmp1E1-117

The staging area location is listed and maintained in the user’s NTUSER.DAT hive file in the following key:

tmp1E1-118

The shellfolders.pl RegRipper plugin extracts and lists all of the value names and their data from this key. Users can change the location of the CD Burning directory by editing the Registry value and providing another location. If the directory path was changed, this may indicate to the analyst that a corporate policy was in place, or that the user has some degree of technical proficiency. This may also indicate that the analyst will need to look for the .bin file artifacts in another directory.

Tip::

According to Microsoft Knowledge Base article 326982 (http://support.microsoft.com/kb/326982), users cannot copy files to a CD-R/CD-RW drive on Windows 2003 systems because, by default, the IMAPI CD-Burning COM Service is disabled. This is because Windows 2003 is considered a server operating system, and the ability to burn CD-Rs is not considered critical. However, analysts should check all Windows systems, not only for the values within the Shell Folders key but also for the status of the IMAPI CD-Burning COM Service within the Services key, when attempting to determine whether the user could have used this functionality to exfiltrate data from the system.

IM and P2P

IM and P2P file-sharing applications are immensely popular—a popularity that seems to cross all generations. Where people once wrote letters that took time to write and to get to the recipient, a quick e-mail can be sent and will be waiting for that person the next time he logs on. Or you can be half a world away and receive a notification the instant your friend logs in to her IM application. Or, using P2P file sharing, you can find any number of useful (or perhaps not so useful) files—music, movies, images, and more. The popularity of these applications has spawned a proliferation of various frameworks and client applications. Yahoo!, AOL, and Microsoft all have their own IM client applications, each with its own functionality and unique forensic "footprints" on a system. To top it off, you can use various third-party applications to replace those clients or even combine them into a single interface. For example, Trillian (trillian.cc) allows users to combine other IM "identities" into a single application, so they only have to log in to a single interface to access multiple IM networks. Meebo.com provides a similar, Web-based interface.

The same type of proliferation is true for P2P networks, as well. Each has its own unique challenges when it comes to forensic analysis. For example, how does an investigator identify with whom a suspect was chatting (on IM) if the application does not log conversations by default? Or how does an investigator determine whether a saved conversation was the result of the user specifically saving the conversation or the result of a third-party add-on for logging conversations? Regarding P2P, how does an investigator determine which search terms a suspect used, which files were retrieved from the sharing network, and from where the files originated?

When you consider that like other applications, IM and P2P clients will change between versions, including new functionality and creating new Registry keys and files, the issue of cataloguing the forensic artifacts of these applications becomes even more daunting. For example, when I was using older versions of the AOL Instant Messaging (AIM) client, there was a specific set of Registry keys within the user’s profile that you could go to and see the user’s encrypted password. This was the result of the user choosing to automatically log in to the AIM network without having to retype his password. If, as part of your investigation, you found it necessary to gather information about this user’s activities on AIM, you could use that encrypted password to set up a similar profile on another system, then log in as that user. I decided to try out the new AIM Triton client awhile ago, and it works great, although it takes a little getting used to. One of the major interface changes was that instead of a different client window being opened for each conversation, each window is now tabbed in a single window. From a forensic perspective, however, I now open RegEdit and there are no entries for AOL or AIM beneath the HKEY_CURRENT_USER\Software hive.

To make matters worse, no effort has been made to publicly catalogue these artifacts. Over the years, forensic investigators and law enforcement have encountered situations requiring that they analyze IM and P2P artifacts, yet there haven’t been any attempts to develop a database or online Wiki for these items. This is an area of research that needs to be developed.

Tip::

Other Registry keys can be used to track user activity. For example, the ShellNoRoam\BagMRU (http://support.microsoft.com/kb/813711) key maintains information about the user’s view settings and customizations for folders. This means the user has to have shell access (i.e., Windows Explorer, by default, via either the keyboard or a remote desktop application) to make these customizations. The Explorer\Streams (http://support.microsoft. com/kb/235994) and StreamMRU keys maintain information about the size and location of a window when it’s closed. This indicates that the user took specific actions to modify the size and/or location of the window on the desktop, which also indicates specific user interaction with the Windows Explorer shell.

Windows XP System Restore Points

Windows XP includes something called System Restore, which maintains a series of restore points so that should your system become unusable or start performing oddly, you can roll back the system to a previous configuration, when it was working properly. I’ll readily admit to having had to do this several times myself. Every now and then I’ll do ("do" usually means "install") something that ends up causing my system to start having fits. Or the installation might simply be a coincidence. Having the ability to "roll back" to a day when I know the system was working properly is great. I’m sure that many other users have found the same to be true.

This is an extremely useful utility for users as well as for forensic investigators. After all, here’s a facility that operates in the background without the user’s knowledge, silently creating backups of critical system configuration information. Restore points are created based on certain triggers, such as when applications or unsigned drivers are installed, or during AutoUpdate installations. Restore points can be created manually and the System Restore service also creates restore points once a day by default.

To better understand how useful System Restore Points can be for forensic analysis, you need to understand a bit about how System Restore works: what gets backed up, what doesn’t get backed up, and what Registry keys control how System Restore behaves.

System Restore restores the following items:

■ Registry

■ Local (not roaming) profiles

■ COM+ database

■ Windows File Protection DLL cache

■ WMI database

■ Internet Information Server (IIS) Metabase

■ Files with extensions listed in the <include> portion of the Monitored File Extensions list in the System Restore section of the Platform SDK

System Restore does not restore the following:

■ DRM settings

■ SAM hive

■ WPA settings (Windows authentication information is not restored)

■ Specific directories/files listed in the Monitored File Extensions list in the System Restore section of the Platform SDK

■ Any file with an extension not listed as <included> in the Monitored File Extensions list in the System Restore section of the Platform SDK

■ User-created data stored in the user profile

■ Contents of redirected folders

It is important to note that although the System Restore service does not restore the SAM hive, it does back it up—at least part of it, anyway. Checking the contents of the restore points, you will see copies of the SAM hive backed up, along with other Registry files.

For the purposes of this topic, we are most interested in the System Restore Points because they contain backups of certain Registry files, such as NTUSER.DAT, SYSTEM, SOFTWARE, and SAM. Figure 4.22 illustrates the contents of the snapshot directory of a restore point, as shown in ProDiscover.

Figure 4.22 Excerpt from ProDiscover Showing a Restore Point Snapshot Directory

Excerpt from ProDiscover Showing a Restore Point Snapshot Directory

As you can see, from a Registry analysis perspective the System Restore backs up quite a bit of very useful information. The Registry files that are backed up to the restore points are only a percentage of the size of those found in the system32\config directory, but they can still provide an investigator with valuable insight into the configuration of the system at points in the past.

Our analysis techniques, particularly using tools such as the Offline Registry Parser, are just as effective with the Registry files located in the restore points as they are with the raw Registry files that we find in the system32\config directory. In fact, many of the keys and values we discussed in this topic are also found in the restore point backups of the Registry files. This allows the investigator to take a peek into the past and see some of the configuration settings and installed software on the system at that time.

Some caveats about System Restore are in order, though. By default, System Restore requires that 200 MB of disk space be available on the system. If this space requirement is not met, the System Restore service will go dormant until that space becomes available. This fact could be important during an investigation if you don’t see the restore points you would expect to see on the system. Some investigators might suspect that someone was able to access the System Volume Information directory and intentionally delete the restore points when in fact they had not been created.

Another thing to be aware of when working with restore points is that the SYSTEM\ ControlSet00x\Control\BackupRestore key also plays a role in determining what is and what isn’t backed up or restored by the System Restore service. This key has three subkeys (AsrKeysNotToRestore, FilesNotToBackup, and KeysNotToRestore) that are fairly self-explanatory. Beneath each subkey you’ll see a list of Registry keys or files (in the case of the files, you’ll see extensions listed with wildcards, meaning all files with that extension). These values and their data may also have an effect on what the investigator sees or has access to during a postmortem investigation.

System Restore configuration information (http://support.microsoft.com/kb/295659) is maintained in the following Registry key:

tmp1E1-120

Several important values are beneath this key. The RPGloballnterval value specifies how often restore points are created. The default value is 86400, which tells XP to create a restore point each calendar day (60 sec x 60 sec/hr x 24 hrs/day = 86400, or one calendar day). If the DisableSR value is set to 1, the System Restore functionality was disabled. By default, this value is set to 0. The RPLifelnterval value specifies how long restore points will be retained (7776000 seconds = 90 days).

A simple way to access information about System Restore on a live Windows XP system is via the SystemRestore (http://msdn.microsoft.com/en-us/library/aa378951.aspx) and SystemRestoreConfig (http://msdn.microsoft.com/en-us/library/aa378955.aspx) WMI classes. The sr.pl Perl script on the accompanying DVD provides an example of how these classes can be used. The Perl script will retrieve the System Restore configuration settings (essentially, Registry values) that are accessible via the SystemRestoreConfig WMI class and display information about each restore point (i.e., the sequence number, the creation date, and the string describing why the restore point was created).

Knowing this, how are the Registry files within the restore points useful from an investigative standpoint? The Registry hive files maintained in the restore points contain much of the same information as what is on the live system itself. If you don’t have a system image available and want to see what these files look like, download a copy of psexec.exe from Microsoft to a Windows XP system, then type the command psexec —s cmd. This opens a command prompt running as SYSTEM, which is required in order to access the System Volume Information directory due to NTFS permissions. Change directories to the System Volume Information directory by typing:

tmpDE-121_thumb[2][2][2][2][2][2][2]

From there, proceed to the subdirectory that holds the restore points:

tmpDE-122_thumb[2][2][2][2][2][2][2]

At this point, if you request a directory listing, you should see several restore points, listed as directory names that start with RP. If you cd to one of these directories and then again to the snapshot subdirectory, you’ll see the Registry files. From here, you can copy any of these files to another directory for analysis. One way to view the information in the Registry hive files is to open RegEdit and select the HKEY_USERS hive. Click File | Load Hive, and then navigate to one of the hive files you copied out of the restore point. When asked, give the hive a name, such as test hive or test system (if you’re using the System file). Figure 4.23 illustrates a System hive loaded in this manner.

Figure 4.23 System Hive from Restore Point Loaded in RegEdit

System Hive from Restore Point Loaded in RegEdit

From here, you can view the contents of keys and even run tools against the Registry to extract the values and data, just as you would against a live system. You can also export values from within the hive.

Another way to do this is to use one of the RegRipper tools mentioned earlier in the topic, called ripxp.pl. This is a specific version of rip.pl written to work with Windows XP restore points found within acquired images. Ripxp.pl works by examining a specific hive file, running one plugin against it (at this time, ripxp.pl runs only one plugin at a time, as running several plugins listed in a plugins file could lead to simply too much information being displayed), and then accessing the restore points and running the same plugin against the corresponding hive file located in those restore points. It does all of this automatically to reduce the potential for mistakes, and to increase the efficiency of the analyst.

In this example, I mounted an acquired image on my test system as H:\. Next, open a command prompt and type the command psexec —s cmd as described earlier; again, this is required to access the restore point files within the System Volume Information directory.

At this point, it may be a good idea to open another command prompt, using the psexec.exe command already employed, and then navigate to the Restore Point directory within the mounted image, using the commands listed previously in this topic. At this point, the output of the dir command on my test image looks as follows (some of the lines will wrap):

tmp1E1-124

So, it appears that we have three restore points within the mounted image. Now, go back to the first command prompt that we opened and navigate to the directory where you stored ripxp.pl and the plugins directory. Typing just ripxp.pl (or ripxp, if you’re using the "compiled" version running on Windows) will show you the syntax for the CLI tool. We will start by running a simple query for the computer name, using the compname.pl plugin. The command you will need to enter appears as follows:

tmp1E1-125

As you can see, it’s probably a good idea to paste the complete path to the Restore Point directory from one command prompt window to another, or into a Notepad document for later use. The command is quite long, even with only three elements. As the path to the Restore Point directory contains spaces, we have to enclose the path in quotes.

What’s really interesting is the output of the command, which appears as follows:

tmp1E1-126

As discussed, ripxp.pl starts by running the selected plugin (compname.pl) against the selected hive file (i.e., the System hive, located in the default directory). It then accesses each restore point, parses the rp.log file,displays the information about the restore point (i.e., reason and date for creation), and then runs the plugin against the appropriate hive file (ripxp.pl contains code that allows it to identify the specific type of hive file).

You can run ripxp.pl against more than just a System hive file. For example, you can use the following command to run the userassist.pl plugin against an NTUSER.DAT file, as well as all corresponding NTUSER.DAT files in the restore points:

tmp1E1-127

Or you can use a command such as the following to run the auditpol.pl plugin against all of the Security hive files, both in the system32\config directory and in the restore points:

tmp1E1-128

By now, it should be clear that you can retrieve a great deal of historical data from Windows XP System Restore Points. As an example of why you might want to use a tool such as ripxp.pl, say you are investigating a case and you suspect that a software program was deleted from the system. Setting up your analysis system as described earlier and using ripxp.pl, you may be able to use the compname.pl plugin to determine when a system’s name was changed, or use the muicache.pl plugin to determine when an executable may have first been run on a system. Ripxp.pl is an extremely powerful tool that uses all of the same plugins used by RegRipper and rip.pl, and can be used to view historical data from the system, and possibly even to observe changes that occurred over time. Say, for example, that you suspect the user disabled auditing or hibernation during a specific period of time, or deleted some critical entries from his NTUSER.DAT hive file. You may be able to quickly and easily get a view into that data, adding additional insight to your examination.

Next post:

Previous post: