Redirection
When an analyst encounters 64-bit versions of the Windows operating system, one thing that needs to be kept in mind is that the operating system employs something called "redirection." This means on 64-bit versions of Windows, Registry data specific to 32-bit applications is maintained in a separate location in the Software hive file. Per Microsoft Knowledge Base article 305097 (http://support.microsoft.com/kb/305097), 32-bit application data is written to the following key path:
Although Registry hive files from 64-bit versions of Windows do not appear to differ at all from those of 32-bit versions of Windows on a purely binary level, differences in Registry keys, such as in the case of redirection, can cause issues with analysts looking for specific keys, or using tools such as RegRipper, and not taking this node into account.
Virtualization
With the advent of Windows Vista, Microsoft introduced virtualization in the Registry. Prior to Vista, if an administrator installed an application that required elevated privileges to run and a regular user tried to run the application, it would fail. With Vista, Microsoft opted to employ a virtualization mechanism that allows Registry write operations that would potentially have a global impact (i.e., written to the Software hive) to be written to a per-user location. This prevents any potentially hazardous write operations to the Registry (typically the creation or modification of keys or values) from having a global impact on the system. For example, if an application attempts to write to the HKLM\Software\^pp key, it will automatically be redirected to the following key:
This key, in turn, does not exist in the user’s NTUSER.DAT hive file, but instead, the following file is mapped to that key when the user logs in:
According to Mark Russinovich’s TechNet article regarding Vista User Access Control (http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx), "only keys that are commonly modified by legacy applications … are virtualized." Modifications to the virtualized keys (keys such as Software\Classes, Software\Microsoft\Windows, and Software\Microsoft\ Windows NT are exempted from virtualization) are redirected to the user’s usrclass.dat file. This file is a valid hive file on a binary level, and can be opened by most Registry Viewers, as well as accessed via the Parse::Win32Registry Perl module. At the time of this writing, however, no RegRipper plugins that are part of the distribution were specifically designed to retrieve information from this hive file.
Deleted Registry Keys
At the beginning of this topic, we discussed the need for understanding the structure of Registry keys, as an examiner can find indications of keys in unallocated space, the page file, a memory dump, and so on. Knowing the structure of the keys will allow you to parse the data you find into something readable, providing context to what you’ve found. Another place you can locate Registry keys that aren’t seen by RegEdit or other analysis tools is with the hive files themselves, in what’s referred to as "unallocated space" within the hive file.
As you saw earlier in the topic in Figure 4.3, Registry keys can be identified by the signature nk. In spring 2008, Jolanta Thomassen (JT) determined that the four bytes, or DWORDs, immediately preceding the key signature, when read as an unsigned long value (using Perl’s unpack() function, you’ll read it as L rather than the V used in many instances to unpack() DWORD values) will, for most valid Registry keys, be a negative number. This is true for Registry keys visible through such tools as RegEdit and others. JT also found signatures for apparently valid keys for which the preceding DWORD value was positive; her research revealed that these were, in fact, deleted keys, which were resident within the hive file itself.
JT’s research was part of her graduate studies at the University of Liverpool. I had the opportunity to meet JT at the DFRWS 2008 conference held in Baltimore in August 2008. I also met Tim Morgan there, who was performing his own research into deleted keys in Registry hive files, completely independent of JT’s work. You can find Tim’s paper, titled "Recovering Deleted Data from the Windows Registry," and his presentation slides at the DFRWS 2008 conference site (www.dfrws.org/2008/program.shtml).
JT released working Perl code that will parse a hive file (extracted from an acquired image, or accessible via an image mounted as a read-only file system, or accessible via Matt Shannon’s F-Response product), extracting and displaying information about deleted Registry keys and values, as well as slack space within the hive file. JT’s Perl script, regslack. pl, is included in the ch4\code\jt directory on the media that accompanies this topic, along with a "compiled" Windows PE version of the tool.
To run regslack.pl, simply type the following at the command prompt:
Regslack.pl doesn’t require any additional Perl modules, so it can be run as a Perl script using nothing more than the basic Perl installation from ActiveState.com. The preceding command redirects the output of the script from the console to a file named sam.txt. I recommend that you do something like this because the script has a considerable amount of information that it sends to the console, so capturing that information in a file makes it easier to view, as well as preserves it for later review. An excerpt of the sam.txt file, illustrating a recovered Registry key from the SAM file, is shown here:
In this case, regslack.pl located a deleted Registry key that pertains to a user, as well as the contents of both the F and V values (the V value name is displayed, but for the sake of brevity, the entire binary contents of the value data are not displayed). The preceding output shows the name of the key with the full path recovered, the offset at which the key was found, as well as the LastWrite time of the key. In addition to the value names and data, the offsets to the values themselves are also displayed, allowing for visual verification. Regslack.pl also displays slack space from within the hive file.
Extracting this type of data as part of an examination can be extremely revealing. As you’ve seen throughout this topic, a number of keys and values within the Registry can provide clues to the presence of malware, user activities, and so on. Intruders may delete Registry keys to attempt to cover their tracks, and users may try to hide indicators of unauthorized activity. However, in some instances, even if the Registry keys themselves are deleted, you may be able to recover those keys from within the hive file itself.
Summary
Knowing how to navigate the Registry for specific information can prove to be an extremely valuable skill for administrators, consultants, and forensic analysts. The Registry will gladly spill forth its secrets to those who know where to look and how to interpret the information they find. Digging into the depths of the Registry is not unlike Indiana Jones tracking down ancient secrets in the shifting sands of time.
You can find a comprehensive (for obvious reasons, I am extremely hesitant to use the word complete) list of autostart locations and user MRU lists within the Registry in the regref.xls spreadsheet included on the accompanying media. This list should be considered a starting point, albeit a comprehensive one, for the reader. The Registry keys listed were retrieved from online lists, applications such as Autoruns, reports of malware on antivirus Web sites, and through personal experimentation.
This topic should not be considered a complete reference of all the various Registry keys that might be of importance to a specific case. Registry keys with similar functionality differ in name and location between applications and, in some cases, between versions of the same application. No topic can be considered a complete authoritative reference resource for Registry keys of interest; it would be far too large and expensive and then almost immediately out of date as soon as it was published. The purpose of this topic is to illustrate what information is available and how to go about finding additional information.
DVD Contents
The media that accompanies this topic includes a directory specifically for this topic. That directory includes several subdirectories, one that contains the code presented in this topic, in particular the RegRipper distribution (including rip.pl and all of the plugins, and as stated, ripxp.pl is not included). The media also includes all Perl scripts from the first edition of the topic (in the "old" subdirectory), as well as the ProScripts (Perl scripts specifically written to be used with the ProDiscover forensic analysis application) discussed in the topic. The "spreadsheet" subdirectory includes a copy of the Registry reference spreadsheet that I compiled a bit ago. This spreadsheet lists several Registry keys and values of interest to forensic analysts as well as a brief description of their purpose and, where applicable, references. The spreadsheet is split up into different worksheets, each covering a specific area of functionality.
There is also a "samples" subdirectory that includes several Registry files from real systems— not only those found in the system32\config directory, but also those from restore points. I encourage you to look at these files, open them in a hex editor, and use any of the tools included in the code subdirectory for this topic so that you can develop a familiarity with the tools as well as with the raw Registry files themselves.
Solutions Fast Track
Inside the Registry
- The Windows Registry is a binary, hierarchical database of configuration information that not only controls various operating system and application configuration settings, but also maintains information about various aspects of the user’s interaction with the system.
- By understanding the format of the various Registry structures (i.e., keys and values) you can then parse and view portions of the Registry found in memory and unallocated space.
- Some portions of the Registry are volatile, created when the system is started, and will not be found in an acquired image of a system.
- Registry keys (and some values) have time stamps associated with them that can be used in timeline analysis. For this reason, the Registry can be considered a log file of sorts.
- There is no apparent standard for the way information is maintained in the Registry. Some MRU keys, for example, maintain their value data as binary types, others as ASCII strings (making searches for ASCII strings somewhat easy). Other Registry keys have their value names obfuscated with ROT-13 "encryption" or their value data maintained in such a way as to hamper string searches. You need to understand the structure of the specific key and value to parse the data stored in that location.
- Tools are available to track accesses and modifications to the Registry on a live system; this information can be used to locate Registry keys of interest as well as determine artifacts left by applications and user activity.
Registry Analysis
- A number of locations within the Registry contain information pertinent to most investigations. Other locations contain information pertinent to specific types of investigations, such as intrusions, fraud, or abuse of acceptable use policies.
- Some specific Registry keys and values can be of importance to an investigation, but often it is the correlation of several Registry keys and values that can provide the most complete picture.
- Windows XP System Restore Points maintain portions of the Registry that can be useful during an investigation. For example, examining the contents of the preserved SAM file, an investigator might be able to determine when a user’s group membership changed (e.g., going from the User to the Administrators group), if that is pertinent to the investigation. You might also be able to tell what applications were installed on the system in the recent past.
Frequently Asked Questions
Q: How do I determine whether there are any browser helper objects (BHOs) installed and what they are?
A: BHOs are maintained in the HKEY_LOCAL_MACHINE hive, which means they affect all users on the system. The BHOs are listed under the Software\Microsoft\ Windows\CurrentVersion\Explorer\Browser Helper Objects key. Beneath this key, each BHO will be listed as a GUID-named subkey. From there, go to the Software\Classes\ CLSID key in the HKEY_LOCAL_MACHINE hive and locate each GUID. Once you locate the key with the same GUID as the BHO, check the Default value of that key for the name of the BHO. To get the DLL for the BHO, check the Default value of the InProcServer subkey. The Perl script bho.pl that is included on the accompanying DVD can be used to retrieve BHOs from a local system.
Q: During a search of a system, I found a Registry key in the user’s hive (Software\ Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains) that had a number of subkeys with the domains of Web sites. What is this key, and what do the subkeys represent?
A: You can add these entries to Internet Explorer by going to Tools | Internet Options | Restricted Sites and clicking the Sites button. However, look closely at the sites listed, because some malware will add sites to this key so that the user cannot access those Web sites. Although entries within this key might indicate Administrator activity or Group Policies, they could also indicate a malware infection.
Q: During an investigation, it became clear, based on information from a Windows XP system (installed software, etc.), that the user had Local Administrator rights on the system. In discussing this with the IT director, it was revealed that all users are provided with only User-level access to their systems. How can I track down when the user was added to the Administrators group on the system?
A: This sort of information about users is maintained in the SAM file. The LastWrite time on the Registry key that maintains group membership information could provide you with some clues. In addition, there could be enough historical data in the Windows XP System Restore Points for you to locate the last time the user’s RID was associated with the User group and not the Administrators group.
