Finding Users
Information about users is maintained in the Registry, in the SAM hive file. Under normal circumstances, this hive is not accessible, even to administrators, not without taking special steps to manually edit the access permissions on the hive. There’s a good reason for this: Although much of the Registry can be "messed with," there are areas of the Registry where minor changes can leave the system potentially unusable. The SAM file is one of those areas.
Much of the useful information in the SAM hive is encoded in binary format, and fortunately, Peter Nordahl-Hagen’s sam.h C header file is extremely helpful in deciphering the structures and revealing something understandable.
You can use the userdump.pl ProScript (v.0.31, 20060522 provided in the ch4\code\ ProScripts directory on the media that accompanies this topic) to extract user and group membership information from the Registry Viewer in a ProDiscover project, once the Registry Viewer has been populated. To run the ProScript, click the Run ProScript button on the menu bar and select the location of the ProScript from the Run ProScript dialog box. (Optionally, you can enter any arguments for a ProScript as well.) Select the user-dump.pl ProScript, and once the execution of the script has completed, the information parsed from the SAM hive will be visible in the results window, where it can be selected, copied, and pasted into a file or report.
Running the userdump.pl ProScript against a sample case that I have available, we can view excerpts from the results to see the breadth of information returned by the script. For example, the ProScript parses information about user accounts on the system, including the username, comment, account creation date, number of logins, and user flags (which provide information about the account). The ProScript will also display the last login time, if it is nonzero.
This user information is maintained in the F value located in the following path:
The {RID}, or Relative Identifier, is the portion of a Security Identifier (SID) that identifies a user or group in relation to the authority that issued the SID. Besides providing quite a bit of information about how SIDs are created, Microsoft also provides a list of RIDs (http://support.microsoft.com/kb/157234) for well-known users and groups as well as well-known aliases (seen in the SAM\SAM\Domains\Builtin\Aliases key).
The F value within the key is a binary data type and must be parsed appropriately (see the sam.h file, part of the source code for Peter’s utility) to extract all the information. Some important dates are available in the contents of the binary data for the F value—specifically, several time/date stamps represented as 64-bit FILETIME objects. Those values and their locations are as follows:
■ Bytes 8-15 represent the last login date for the account.
■ Bytes 24-31 represent the date that the password was last reset (if the password hasn’t been reset or changed, this date will correlate to the account creation date).
■ Bytes 32-39 represent the account expiration date.
■ Bytes 40-47 represent the date of the last failed login attempt (because the account name has to be correct for the date to be changed on a specific account, this date can also be referred to as the date of the last incorrect password usage).
Tools such as AccessData’s Registry Viewer will decode this information for you automatically, as Figure 4.18 illustrates.
Figure 4.18 Portion of AccessData’s Registry Viewer Showing Decode of a User’s F Value
AccessData’s Registry Viewer is available for download (www.accessdata.com/downloads.html) and will run in demo mode if you do not have an AccessData dongle. To use the Registry Viewer to decode these values, you must first extract the raw Registry file (in this case, the SAM file) from the image, copying it to another location.
The Perl module Parse::Win32Registry (available from http://search.cpan.org/ -jmacfarla/) provides a freely available, cross-platform method for parsing the contents of raw Registry files that have similarly been extracted from an acquired image (or have been made available via some other means). To install Version 0.41 (as of this writing) of this module on Windows systems, simply use ActiveState’s Perl Package Manager (ppm) utility as follows:
The samparse.pl plugin (the stand-alone sam_parse.pl Perl script is located in the ch4\code\old directory on the accompanying media) uses this module to extract and display much of the same information available from the Registry Viewer, plus some additional information:
The samparse.pl plugin not only displays the time stamps available from the user information in the SAM file, but also parses the user flags and the number of times the user has logged in to the system.
Because the Parse::Win32Registry module does not rely on Windows APIs, Perl scripts that use the module will be platform-independent. This means analysts and investigators are not restricted to a Windows platform when they want to parse the contents of raw Registry files. As long as the files are available (i.e., extracted from an image file, etc.), code written using the module can be run on Linux, Windows, or even Mac OS X systems that support Perl.
Each of these keys also has a V value that is also a binary data type and can be parsed to get the user’s account settings, such as full name, comment, path to the login script (if any), and encrypted password hashes.
The samparse.pl plugin also retrieves information about groups on the system, including the group name, the group comment, and the users assigned to the group:
Information about group membership is maintained in the SAM\SAM\Domains\ Builtin\Aliases key. Each RID subkey beneath the Aliases key has a C value that is a binary data type and needs to be parsed to determine which users are members of the group. The best road map I found for parsing this binary data is available from Andreas Schuster’s blog (http://computer.forensikblog.de/en/2006/02/list_members_of_a_windows_group.html). This information was incorporated into the userdump.pl ProScript.
Information about users and group membership is extremely valuable in understanding the context of an examination, specifically which users had access to the system and what level of access they had (via group membership). Much of this information is easily extracted during live response using available tools. With a bit more information about the various structures maintained within the Registry, you can extract similar information from a postmortem image.
Tracking User Activity
You can use a number of Registry keys to track user activity. This type of Registry key is different from the autostart/user activity Registry keys, which are keys accessed when a user performs a specific action. You can find these Registry keys in the NTUSER.DAT file for the user and they are updated (i.e., entries are added) when a user performs specific actions. When this happens, the key’s LastWrite time is updated, which brings us back to the concept of the Registry as a log file. Also, there are keys that track user activity and add or modify time-stamp information associated with the Registry values (e.g., UserAssist subkeys); this time-stamp information is maintained in the value data.
The HKEY_CURRENT_USER hive contains the most information about user activities in locations referred to as most recently used, or MRU, lists. This name comes from the fact that, as you’ll see, these keys maintain a list of files or commands as well as a value referred to as the MRUlist. Each value within the key is designated by an identifier, such as a lowercase letter, and the MRUlist value displays the order in which they were accessed.
The UserAssist Keys
Quite a lot has been written about the UserAssist keys, most of which has appeared in the form of questions. The specific keys we’re interested in are located beneath the following key path in the user’s NTUSER.DAT file:
The GUID is a globally unique identifier; in this case, two such keys are beneath the UserAssist key: 5E6AB780-7743-11CF-A12B-00AA004AE837 and 75048700-EF1F-11D0-9888-006097DEACF9.Within the HKEY_CLASSES_ROOT hive, the GUID 5E6AB780-7743-11CF-A12B-00AA004AE837 points to the Internet Toolbar (such as %SystemRoot%\system32\browseui.dll), and the GUID 75048700-EF1F-11D0-9888-006097DEACF9 points to the ActiveDesktop (such as %SystemRoot%\system32\ SHELL32.dll). The importance of this will become apparent after you discover what’s in these keys and why it’s useful.
Beneath each Count key are several values; in fact, there might be many, many values. When I first began researching these keys (most often referred to as UserAssist keys rather than Count keys), I found sites on the Internet that reported upward of 18,000 or more entries beneath one key and 400 or so beneath the other. That system was a Windows 2000 system that had been running for about five years when the post was made to the Web site. What’s so special about these keys? In a nutshell, they log user activity, to a degree. Yes, that’s right, you read it correctly. To a degree, these keys actually record user activity like a log file.
However, if you navigate to these keys in RegEdit, you won’t see that at all. You’ll see something like HRZR_HVGBBYONE, which makes absolutely no sense. That’s because the value names beneath these two keys are ROT-13 "encrypted." ROT-13 refers to a Caesarian cipher in which each letter is replaced with the letter 13 spaces farther down in the alphabet. Using a simple substitution (in Perl, tr/N-ZA-Mn-za-m/A-Za-z/), we can then see that HRZR_HVGBBYONE is really UEME_UITOOLBAR. Okay, that’s a little more readable, but we’re really no closer to an answer at this point, are we?
The value names beneath both keys are ROT-13-encrypted and can be easily decrypted. In fact, the Perl script uassist.pl (included on the accompanying media) illustrates how simple this translation is to accomplish on a live system. The real treasure within these keys is in the data associated with each value. In many cases, the decrypted value name points to an application or an executable. In those cases, the data is often 16 bytes (four DWORDs) long and includes not only a run count (the number of times that application or executable has been run), but also a last run time (an 8-byte FILETIME object). The run count is stored in the second DWORD and starts at 5; therefore, a run count of 6 means the application was launched once. The FILETIME object is in the third and fourth DWORDs.
When you decrypt the value names, you’ll see that many of them are preceded by UEME_, and then RUNPATH, RUNPIDL, RUNCPL, and so on. These tags can be relatively easy to sort out:
■ RUNPATH Refers to an absolute path within the file system; it occurs when you double-click an icon for an executable in Windows Explorer or type the name of the application in the Start | Run box.
■ RUNCPL Refers to launching a Control Panel applet.
■ RUNPIDL A PIDL, or pointer to an ID list, part of the internal Explorer namespace and used to refer to an object. In the case of the UserAssist keys, these are most often shortcuts or LNK files, as when you choose Start | Documents and select a file.
For example, the system I’m writing this topic on is a Dell Latitude D820, purchased in the beginning of August 2006. Whenever I purchase a new system, I reformat the hard drive and install the operating system all over again. For Dell systems, this means I have to download and install several drivers (Dell makes it very easy to locate the necessary drivers). When I ran the uassist.pl script on my system, I saw the following entry:
The script returns the FILETIME object in a local time, so we can see that the application D820_A02_bios.exe was executed one time, on August 7. Other entries include:
Here we can see that the Display and Power Options Control Panel applets were both executed on August 24, and that was the only time each was launched. Just for fun, on October 4, at about 10:55 p.m., I opened the Display applet in the Control Panel and then reran the Perl script to find that the date had been changed to Wed Oct 4 22:55:59 2006.
So, essentially, these keys record the number of times certain applications have been launched and the last time that action was taken. This information can be very helpful when you’re working on a case. For example, seeing something such as UEME_RUNCPL:timedate.cpl might indicate that the user accessed the Date and Time Control Panel applet; possibly to alter the system time.
The userassist.pl will assist you in collecting information from NTUSER.DAT files during an investigation. The plugin uses the Parse::Win32Registry module to access the raw NTUSER.DAT file (which you’ve extracted from your acquired image) and locate the UserAssist key that contains the GUID that points to ActiveDesktop. It gets the LastWrite time for the key and then parses through the key, extracting and "decrypting" value names. The output from the script, which follows, is sorted based on the time stamps found in the data for each of the values:
One question I get time and again when I illustrate these tools running against Registry hive files from Windows XP and 2003 systems is "Yeah, but does it work on Vista?" Well, yes, it does. Here’s an excerpt of the output from a user’s hive file from a Vista system:
One of the benefits of parsing the contents of the UserAssist key is that it not only shows what actions the user took through the shell (e.g., double-clicking icons, launching an application through the Start menu, or accessing Control Panel applets), but also shows when these actions occurred.
The Parse::Win32Registry Perl module allows easy access to the binary contents of the Registry hive files. Some aspects of the Registry changed between various releases of the operating system; however, the binary structure does not appear to have changed. The UserAssist key structure and values have remained the same from Windows 2000 through Vista, but a brief look at the Windows 7 Beta in January 2009 indicated to me that there were changes that need to be addressed. Although the binary format of the Registry hive files has not changed, the contents of the UserAssist keys have, and will require analysis and additional coding to be added to RegRipper plugins.
Uassist.pl, a ProScript for use with ProDiscover, is available on the media that accompanies this topic, in the ch4\code\Proscripts directory. You can run this ProScript (Version 0.11, 20060522) against the Registry once the Registry Viewer has been populated. The script parses through the UserAssist Registry key entries for all users and extracts the information in a readable format, decrypting the value names and parsing the run count and last run times from the data, where applicable. Once this is done, the script sorts all the values with time stamps so that the information can be used for timeline analysis. This version of the ProScript sends its results to the command window in ProDiscover, where the investigator can then select, copy, and paste those results into a file or report.
Are You Owned?
Case Study: Defragged?
I dealt with an incident in which an employee for my client might have known he was under suspicion, and while he was allowed access to his system he might have deleted a number of files. The suspicious filenames were located as deleted files, but the content simply wasn’t there. There was the additional suspicion that he’d not only deleted the files, but also defragmented the hard drive. The information in the UserAssist key showed that the employee had run the Add/Remove Programs Control Panel applet. Information in the Prefetch directory showed that the defrag utility had been run, but there was nothing in the UserAssist key to indicate that the employee had done so. This activity was determined to be part of the limited defrag that Windows XP runs every three days.
Tip::
If you’ve installed or are examining an image of a system on which the user had installed Internet Explorer Version 7, you will find a third subkey beneath the UserAssist Registry key.
