Registry Analysis (Windows Forensic Analysis) Part 3

RipXP

The family of RegRipper tools also includes another useful tool that is a variation of rip.pl, called ripxp.pl. I chose the name because this is a CLI tool based on rip.pl that is specific to Windows XP. Windows XP maintains System Restore Points which contain portions of Registry hive files. To run ripxp.pl, you need to identify the path to the hive file you’re interested in parsing, the path to the Restore Points directory, and then which plugin you want to run.

Note

Ripxp.pl is not provided on the media that accompanies this topic. At the time of this writing, this tool is far too raw to be released for public consumption. I demonstrated the use of the tool at the SANS Forensic Summit in Las Vegas in October 2008, and provided an evaluation copy of the tool to a friend, who had great success with it. Part of the reason for this is that you need to follow some very specific steps to run ripxp.pl, so not only do additional training materials need to be developed, but additional work also needs to be done to make the tool more functional and "forgiving."

Ripxp.pl will "guess" the type of the hive file and then determine whether the plugin can be run against the hive file. It will run the plugin against the hive file, and then navigate to the Restore Points directory, locate each restore point, identify and display the creation date of the restore point, and then run the plugin against the specific hive file. It does all of this automatically.

The capability of tools such as ripxp.pl to provide historical data from within Windows XP System Restore Points has been extremely useful. As with most of the tools I’ve developed, the need for such functionality arose either from my own needs or from someone else saying, "Hey, wouldn’t it be really cool if you could…". In fact, the credit for the idea of ripxp.pl goes to Rob Lee, because in spring 2008, he said just that: "Wouldn’t it be cool if you could automatically run a tool like RegRipper against the XP System Restore Points?" I thought, yeah, it would be. I will demonstrate the use of ripxp.pl later in this topic.

System Information

When working with an acquired image of a Windows system during postmortem analysis, there is a great deal of basic information about the system that you might be interested in. Much of this information is relatively easy to obtain during live response; for example, in many cases you can determine the version of the operating system (such as Windows 2000, XP, 2003, or Vista) by simply looking at the shell. Or you can right-click My Computer and choose Properties to see a lot of basic information, such as the version of the operating system, the Service Pack level, and the name of the computer. This information is also available in the Registry, where it is easily accessed during postmortem analysis. More importantly, information about the system itself is maintained primarily in the System and Software hive files (there is some in the Security hive file), and information about users is maintained in the SAM hive file. Information specific to users and their activity is maintained in the user’s NTUSER.DAT file. In this section of the topic, we’ll focus primarily on the System, Software, and Security hive files.

If you remember, the CurrentControlSet is a volatile portion of the Registry, and you won’t find it in an acquired image. The "Finding the CurrentControlSet" sidebar illustrates ways in which you can determine which ControlSet was marked as "current" on the live system. Once you determine which ControlSet was current, you want to focus your examination on keys within that particular ControlSet.

Forensic Feats …

Finding the CurrentControlSet

Most times when you access an acquired image, you’ll be interested to know which of the two ControlSets visible in the Registry Viewer (in ProDiscover) the operating system used as the CurrentControlSet. To do so, navigate to the HKEY_LOCAL_MACHINE\ System\Select key and you’ll find several values, as illustrated in Figure 4.7.

The RegRipper distribution ships with a template file that you can use to quickly begin creating a plugin; this template includes code for determining the current control set from a System hive file. In addition, you can use any of the plugins within the /plugins directory that access the System hive as a basis for your own plugins.

Figure 4.7 Locating the CurrentControlSet in an Image

As shown in Figure 4.7, the ControlSet that the operating system used as the CurrentControlSet while it was active is numbered 1. Within the Registry Viewer are two ControlSets: ControlSet001 and ControlSet002. (In some cases, you’ll find different numbers, including ControlSet03 and ControlSet04; however, you will generally see only two ControlSets.)

ComputerName

You can use much of the information available in the System and Software hives to determine basic information identifying the system. These hive files contain a great deal of information that you can use to perform basic system identification (i.e., the system name, the time zone the system was configured to use, and information about attached devices and available shares), as well as to guide your analysis, such as the system’s audit configuration, as demonstrated earlier.

You can find the computer’s name in the following key, in the ComputerName value:

The compname.pl plugin returns the following information:

You can find the time at which the system was last shut down in the following key:

The ShutdownTime value beneath this key is a FILETIME object and can be correlated with other times on the system, such as Event Log entries and the like to assist in developing a timeline of activity and system use.

The following key could also be of value during an investigation:

This key holds several values that provide information about the system. The ProductName, CurrentBuildNumber, and CSDVersion values will tell you which operating system and version (including the Service Pack) you’re working with. The RegisteredOrganization and RegisteredOwner values, although not always filled in, can be used to further identify the system. The ProductId and InstallDate values can also be of use. The winnt_cv.pl plugin extracts all of the values and their data from the key:

 

 

 

 

 

The winnt_cv.pl plugin is written to sort and display the various value data based on the length of the data itself. All of this information provides basic identification of the system being examined, and you can use it to document the system, as well as to guide follow-on analysis.

TimeZoneInformation

You can find information about the time zone settings in the following key:

This information can be extremely important for establishing a timeline of activity on the system. Throughout the rest of this topic, we’ll discuss various scripts that you can use to retrieve information from the Registry; in other topics we will discuss files, Event Log entries, and the like. Many of the available tools will extract information regarding times and dates in UTC/GMT time, and you can use the ActiveTimeBias (listed in minutes) value from the TimeZoneInformation key to translate or normalize the times to other sources from the system, such as entries in log files. RegRipper’s timezone.pl plugin displays the information for you.

Network Interfaces

Information about network interfaces, or network interface cards (NICs), is maintained in both the Software and System hive files. Within the Software hive file, the following Registry key contains information about network cards:

Within the System hive, information about network interfaces is maintained in the following Registry key:

Both RegRipper and rip.pl can use the networkcards.pl and nic_mst2.pl plugins to retrieve network interface information from the respective hive files. For example, from a Vista system the networkcards.pl plugin retrieves the following information:

From the same Vista system, the nic_mst2.pl plugin retrieves the following:

The preceding information can be extremely useful in not only identifying a system, but also correlating a Windows system to other data, such as network device log files or network packet captures.

MAC Address

As you can see, considerable information about a Windows system’s networking setup (i.e., network interfaces and their configurations) is maintained in the Registry. However, the system’s Media Access Control (MAC) address, which is the address hardcoded or "burned" into a NIC, is not usually maintained as part of that configuration information. When the Windows operating system needs to determine the MAC address, it will first check a Registry key, and if it cannot find an address it will query the NIC itself. Windows looks for the NetworkAddress value in the following key:

In this Registry key, "000n" is the number of the adapter. Again, the MAC address is not maintained within this key by default; those who write tools which allow users to change or "spoof" their MAC address (sometimes for nefarious purposes), such as the Technitium MAC Address Changer (http://tmac.technitium.com/tmac/index.html), are aware of this.

Another location where you may find that MAC address (and I emphasized "may" here because I have not found this to be consistent behavior) is in the following key:

I have, upon occasion, found a value within this key, named MAC, that contained one or more MAC addresses listed as strings (as opposed to binary data that needed to be parsed and translated). For example, on one of my systems, the MAC value is visible in the preceding key, and contains the following data (this was copied and pasted out of the Registry):

Each MAC address listed corresponds to values that I can clearly see in the output of the ipconfig /all command; those beginning with "00-50-56-C0" correspond to interfaces for my VMware application installation.

The macaddr.pl plugin included with the RegRipper distribution on the accompanying media is something of a hybrid plugin, in that rather than being specific to a single hive file (e.g., either the Software or the System hive file), it includes code that allows it to determine which hive file (Software or System) it is being run against, and then it queries the appropriate Registry key for the necessary information. If the appropriate value is located beneath the aforementioned keys in the respective hive files, the macaddr.pl plugin will extract the information. Interestingly, during testing ofVista, Vista 64-bit, and Windows 7 systems, some of the keys in the System hive files will have the NetworkAddress value, albeit with no data.

Locating MAC address information within an image may assist an analyst in a number of ways. Windows shortcut (*.lnk) files may have MAC addresses embedded in them,or an analyst may also have network traffic capture data to work with and may need to uniquely identify a system based on the MAC addresses found in the collected data. At the very least, the MAC address information can help to uniquely identify a system, even if Dynamic Host Configuration Protocol (DHCP) is used to assign a different Internet Protocol (IP) address, and the user changes the system name.

Shares

Many times, Windows systems will have shares available so that users can access the system remotely. In most instances, this is true for file servers, but it may also be true for user workstations, laptops, and so forth. By default, Windows 2000, XP, 2003, and Vista systems will create hidden administrative shares on a system, as well. There is the IPC$ (interprocess communications) share, ADMIN$, shares that refer to the root of the hard drive(s) on the system (C$, D$, etc.), among others. If a user creates an additional share, such as via the net share command, that share will appear in the following key (unless otherwise specified, all Registry keys in this section are located in the HKEY_LOCAL_MACHINE hive):

You can use the shares.pl plugin to retrieve information about available shares from a System hive file, as illustrated here:

As you can see, the plugin retrieves information about the share, including the name, the path for the share, any remarks, and the type of share. According to the Win32_Share

Windows Management Instrumentation (WMI) class (http://msdn.microsoft.com/en-us/ library/aa394435(VS.85).aspx), Type=0 means the share is for a disk drive and Type=1 means the share is for a print queue.

Now, by default, you might not see any shares listed under the Shares key. This simply means the user hasn’t created any new shares. However, Windows systems will create certain administrative shares automatically. If the user or administrator took steps to disable the creation of those hidden administrative shares, you’ll want to look beneath the following key:

If you see a value named AutoShareServer (http://support.microsoft.com/kb/288164) beneath this key and the data is 0, this indicates that the system has been modified specifically to prevent the creation of the hidden administrative shares. The shares.pl plugin checks for the presence of the AutoShareServer value.

Warning::

Different versions of the Windows operating system can spell some subkeys differently. For example, on Windows XP, the Lanmanserver subkey is spelled "lanmanserver", whereas on Vista it’s spelled "LanmanServer". On Windows XP, the Parameters subkey (beneath the Lanmanserver key) is spelled "parameters", and on Vista it’s spelled "Parameters". The shares.pl plugin includes code that compensates for this disparity.

Audit Policy and Event Logs

On Windows 2000, XP, and 2003 systems, the system’s audit policy (http://support.microsoft.com/kb/246120) is maintained in the Security hive, beneath the Policy\PolAdtEv key. The (Default) value is a REG_NONE data type and contains binary information into which the audit policy is encoded. The audit policy extracted from a sample image using the Offline Registry Parser shows:

The first DWORD (four bytes) of the binary data (actually, the first byte) lets you know whether auditing was enabled. In this case, the value is 01, so auditing was enabled (00 indicates that it was disabled). Windows 2000 and XP systems have nine event types that can be audited, and each of those areas is represented by a DWORD value in the sequence of bytes. The final DWORD value is not used.

Warning::

The information in this section applies only to Windows 2000, XP, and 2003. The audit and logging mechanisms for the Windows operating systems were changed with the advent of Vista, to include a greater number of logs and a different log format (XML, rather than binary).

To decipher this information, we need to understand a bit about the format. Map the following template over the data retrieved from the PolAdtEv key:

0Z	XX	XX	XX	AA	00	00	00	BB	00	00	00	CC	00	00	00	DD	00	00	00	EE	00	00	00
FF	00	00	00	GG	00	00	00	HH	00	00	00	II	00	00	00	XX	00	00	00

The value for Z determines whether auditing is enabled (1 for enabled, 0 for disabled). The rest of the values correspond to the following listing (we don’t care about the X values):

AA	Audit	System Events
BB	Audit	Logon Events
CC	Audit	Object Access
DD	Audit	Privilege Use
EE	Audit	Process Tracking
FF	Audit	Policy Change
GG	Audit	Account Management
HH	Audit	Directory Service Access
II	Audit	Account Logon Events

For each lettered pair, 00 means there is no auditing, 01 means success events are audited, 02 means failure events are audited, and 03 means both success and failure events are audited.

We can see that both success and failure auditing was enabled on the sample image for System events, Logon events, Policy Change events, Account Management events, and Account Logon events.

This information can be useful during an examination of Windows 2000, XP, and 2003 systems, because it will tell us what sorts of events we should expect to see in the Event Log.The auditpol.pl RegRipper plugin will extract and interpret the data from the Security hive file, as illustrated here:

 

 

 

 

As you can see, in one instance, the auditpol.pl plugin indicated that auditing was not enabled, and in the other, that auditing was enabled and what the various settings are for the different events (N = no auditing, S = auditing of successful events, F = auditing of failure events, and S/F = auditing for both successful and failure events).

Information about the Event Log files themselves is maintained in the HKLM\System\ ControlSet00x\Services\EventLog key. This is true on all Windows systems, including Windows 2000, XP, 2003, Vista, and Windows 7; however, the difference for each is how many subkeys are found beneath the EventLog key on each version of Windows, as the number of subkeys equates to the number of different Event Logs that are available. For example, on Windows XP systems, you will most often find Application, System, Security, and possibly even Internet Explorer (if the system has been upgraded to Internet Explorer Version 7) subkeys. In the case of Windows 2003, you may also find a domain name system (DNS) Server Event Log, and I have seen instances of Event Logs for specific applications. In most instances (particularly with the default Microsoft Event Logs), you will find values that pertain to the name and location of the Event Log file, its maximum size, and how many days Event Log entries are to be retained (although Microsoft Knowledge Base article 102998, http://support.microsoft.com/kb/102998, is older, the information still pertains). The eventlog.pl plugin extracts this information, processes some of the various settings into something a bit more readable, and displays it as illustrated here:

 

 

 

 

 

As you can see, the eventlog.pl plugin extracts considerable information about the Event Log settings. Each Event Log name is displayed along with the key’s LastWrite time, indicating the last time the contents of the key were changed. Maximum file sizes and retention times (listed in the Registry as seconds, but displayed by the plugin as days), in addition to the file path to the log file itself, are displayed. As you can see from the preceding Application Event Log entry, the AutoBackupLogFiles value (the value is described in Microsoft Knowledge Base article 312571, http://support.microsoft.com/kb/312571/) is displayed, if it is available. Another value specific to the Security Event Log is the WarningLevel value (described in Microsoft Knowledge Base article 945463, http://support.microsoft.com/kb/945463), which will cause the Security Event Log to generate an event with ID 523 when it reaches the designated capacity. The eventlog.pl plugin will also display this value, if it is available.

Tip::

Around the same time I was writing the eventlog.pl plugin, Don Weber of Cutaway Security (www.cutawaysecurity.com/) wrote his own plugin called eventlogs.pl, and posted it to the RegRipper.net forum.

Also, as part of the Windows 2000 Resource Kit, Microsoft released an Event Log management Perl script named eventlog.pl, which is described in Microsoft Knowledge Base article 318763 (http://support.microsoft.com/ kb/318763). This script is intended to be run on a live system, and allows an administrator to get a lot of the same information as is available from the RegRipper eventlog.pl plugin—in particular, the properties of the Event Logs.