Registry files, if deleted, can be restored from those saved in what folder?

Creating a System Restore Point

A system restore point is an image of the system configuration and settings in the Windows Registry that helps in restoring the system to an earlier date when the system was running perfectly. You can create a system restore point manually from the System Protection tab of the System Properties window. The Backup and Restore Center also takes you to the same window when you click the Create a restore point or Change settings button. The following explains how you can manually create a system restore point:

Open the Control Panel from the Start menu.

Click the System link in the System and Maintenance group.

Click the System protection link.

Click Continue in the User Account Control dialog box to confirm your action. Figure 5.5 shows the System Protection tab.

You can turn on or off the default automatic creation of system restore points by clearing the checkboxes under Available Disks.

If you want to create a restore point for only one of the disks, clear the checkbox for the other.

Click the Create button and follow further instructions.

The system restore point is created on the same disk where the operating system is installed. It uses a maximum of 15 percent of the disk space; older files are automatically deleted in order to make space for new files.

What are “Volume Shadow Copies”?

Volume Shadow Copies [VSCs] are one of the new, ominous-sounding aspects of the Windows operating systems [specifically, Windows XP, in a limited manner, and more so with Vista and Windows 7] that can significantly impact an analyst’s examination. VSCs are significant and interesting as a source of artifacts, enough to require their own chapter.

With the release of Windows XP, Microsoft introduced the Volume Shadow Copy Service [VSS] to provide functionality for backing up critical system files to assist with system recovery. With Windows XP, users and administrators saw this functionality as System Restore Points, which were created automatically under various conditions [e.g., every 24 hours, when a driver was installed, etc.], and could also be created manually, as illustrated in Figure 3.1.

As illustrated in Figure 3.1, users can not only create Restore Points, but they can also restore the computer to an earlier time. This proved to be a useful functionality, particularly when a user installed something [application, driver, etc.] that failed to work properly, or the system became infected with malware of some kind. Users could revert the core functionality of their systems to a previous state through the System Restore functionality, effectively recovering it to a previous state. However, System Restore Points do not back up everything on a system; for example, user data files are not backed up [and are therefore not restored, either], and all of the data [specifically, the passwords] in the SAM hive of the Registry are not backed up, as you wouldn’t want users to restore their systems to a previous point in time and have them not be able to access their systems, as a previous password [which they may not remember] had been restored.

So, while System Restore Points did prove useful when users needed to recover their systems to a previous state, they did little to back up user data and provide access to previous copies of other files. From a forensic analysis, a great deal of historical data could be retrieved from System Restore Points, including backed-up system files and Registry hives. Analysts still need to understand how backed up files could be “mapped” to their original filenames but the fact that the files are backed up is valuable in itself.

Tip

System Files in Restore Points

One use of system files being backed up to Windows XP System Restore Points is that when malware is installed as a device driver [executable file with a .sys extension], it would be backed up to a Restore Point. If the installation process had included modifying the file time stamps so that the file appeared to have been created on the system during the original installation process, the true creation date could be verified via the master file table [see Chapter 4]. Further, if there were six Restore Points, and the system file was not backed up in the older five Restore Points, and was only available in the most recent Restore Point, this would also provide an indication that the observed creation date for the file was not correct.

With the release of Vista, the functionality provided by the VSS to support services such as Windows Backup and System Restore was expanded. In particular, the amount and type of data captured by System Restore was expanded to include block-level, incremental “snapshots” of a system [only the modified information was recorded] at a given point in time. These “snapshots,” known as Volume Shadow Copies, appeared in a different manner to the user. VSCs operate at the block level within the file system, backing up and providing access to previous versions of system and user data files within a particular volume. As with System Restore Points, the actual backups are transparent to the user, but with VSCs, the user can restore previous versions of files through the Previous Versions shell extension, as illustrated in Figure 3.2 [from a Windows 7 system].

Okay, so what does this mean to the forensic analyst? From an analyst’s perspective, there is a great deal of historical information within backed-up files. Accessing these files can provide not just historical data [e.g., previous contents, etc.] but additional analysis can be conducted by comparing the available versions over time.

Disable System Restore Points and File History

As we have already seen during previous chapters, system restore points can contain hidden data and previously deleted files. This imposes security risks because our previous data and deleted files can be easily recovered from previous restore points. To disable this feature in Windows® 7 do the following:

Go to Control Panel  >>  System  >>  System Protection

Select the partition where you want to disable protection and click Configure. A new window appears; select the option Turn off system protection, and finally click OK to apply changes [see Fig. 7.19].

Repeat the same process for all disks/partitions where you want to disable system restore.

In Windows® 8 and 10, you need also to disable File History, which is a modern Windows® feature that backup all your default and custom libraries, Contacts, Documents, Music, Pictures, Videos, Desktop and the OneDrive files available offline on your PC.

This feature is disabled by default in Windows® and it only saves its backup copies to external drives. In case it is enabled, however, follow these steps to disable it:File History®

Go to Control Panel  >>  File History

If it is already enabled, click Turn Off [see Fig. 7.20].

Mapping Devices to Drive Letters

Once we have information about the USB devices attached to the system, we can attempt to map that device to a drive letter. This may not always be possible, particularly, if multiple devices had been successively connected to the system. For example, I've connected a thumb drive to my system that has been mounted as the drive letter F:\. Later, I disconnect the device, and then at some point connect another device, which is also mounted as the F:\ drive.

Before continuing, we need to understand that Windows treats external USB drives [hard drives in enclosures, such as “wallet” drives] and thumb drives or USB keys differently. Specifically, thumb drives contain a value within their unique instance ID key called the ParentIdPrefix; external drives do not contain this value. I have also seen that neither the storage component of my Motorola MB300 BackFlip smartphone nor a Garmin Nuvi [both the SD card and the flash device] will have a ParentIdPrefix value populated beneath the unique instance ID key. The usbstor.pl RegRipper plug-in will display the ParentIdPrefix value for those devices that have the value, as illustrated as follows:

Disk&Ven_Generic-&Prod_Multi-Card&Rev_1.00 [Sat Jan 2 12:56:01 2010]

 S/N: 20071114173400000&0 [Sun Aug 1 10:06:03 2010]

 FriendlyName : Generic- Multi-Card USB Device

 ParentIdPrefix: 7&24e8d74f&0

However, as indicated, external drives [usually, those in enclosures, produced by Maxtor, Western Digital, and so on] will not have ParentIdPrefix values, as illustrated as follows:

Disk&Ven_Maxtor&Prod_OneTouch&Rev_0125 [Thu Mar 4 15:50:13 2010]

 S/N: 2HAPT6R0____&0 [Wed Jun 30 01:27:21 2010]

 FriendlyName : Maxtor OneTouch USB Device

 S/N: 2HAPT6VY____&0 [Thu Jul 8 00:34:48 2010]

 FriendlyName : Maxtor OneTouch USB Device

This is important because we may be able to use this information to map a thumb drive or key to a drive letter. I say “may be able to” because it really depends on how soon after the device being connected to the system that an image [or just the System hive] is acquired from the system. As I mentioned earlier, drive letters will very often be reused, so disconnecting one device and connecting another may result in both devices being assigned the same drive letter.

All of the values within the MountedDevices key have binary data. However, different data can mean different things. For instance, Figure 3.18 illustrates an excerpt of values from the Mounted Devices key of a System hive file, viewed through the Windows Registry File Viewer [RFV].

As you can see from Figure 3.18, there are two basic types of value names; those that begin with “\DosDevices\” and refer to a drive or volume letter, and those that begin with “\??\Volume” and refer to volumes. These values have data of different lengths; some are 12 bytes long, whereas others are longer. Many of the longer ones are actually Unicode strings that refer to devices, strings that we can read by double-clicking the value [RFV opens a Data View dialog]. The contents of the data for “\DosDevices\H:” [highlighted in Figure 3.18] is shown in Figure 3.19.

The Unicode string in Figure 3.19 refers to a removable storage device [“\??\Storage#RemovableMedia#,” in this case, a USB device], and the highlighted substring “7&24e8d74f&0” is the ParentIdPrefix value for one of the USB devices that had been connected to the system. Therefore, we can use the Parent IdPrefix value to map a USB thumb drive from the Enum\USBStor key to a volume identifier within the MountedDevices key, and possibly even to a drive letter. An important factor to keep in mind, however, is that if you plug in one device that is mapped to drive H:\, disconnect it, and then connect another device that is mapped to drive H:\, the previous data for “\DosDevices\H:” is replaced.

Getting Historical Information

Historical information about drive mappings in the hive files can be found in Windows XP system restore points, as well as within hive files from volume shadow copies on Vista and above systems.

Using the usbstor.pl RegRipper plug-in, we can obtain information about USB removable storage devices attached to the system [note that the key LastWrite times are displayed, but are irrelevant to this example], an excerpt of which is illustrated as follows:

Disk&Ven_Generic-&Prod_Multi-Card&Rev_1.00 [Sat Jan 2 12:56:01 2010]

 S/N: 20071114173400000&0 [Sun Aug 1 10:06:03 2010]

 FriendlyName : Generic- Multi-Card USB Device

 ParentIdPrefix: 7&24e8d74f&0

From the mountdev.pl plug-in, we can get information about the values listed in the MountedDevices key, which appears as follows:

Device: \??\STORAGE#RemovableMedia#7&24e8d74f&0&RM#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}

 \??\Volume{47042c43-f725-11de-a8a5-806d6172696f}

 \DosDevices\H:

So now, we're able to map a USB thumb drive to a drive letter. But what about the USB external drives, such as those in enclosures [i.e., “wallet” drives, and so on]? If you remember from Figure 3.18, several of the values have data that is only 12 bytes long. These are volume identifiers and drive letters that refer to the external drives. In these cases, the first 4 bytes [DWORD] are the drive signature [also known as a volume ID] from the hard drive itself. This signature is written to a hard drive, beginning at offset 0x1b8 [440 in decimal] within the master boot record [MBR] when Windows formats the drive. You can view this value by opening the first 512 bytes of the hard drive [MBR] in a hex editor and navigating to offset 0x1b8. The remaining 8 bytes of the data are the partition or volume offset. In Figure 3.18, we see two drive letters [\DosDevices\C: and \DosDevices\F:] with partition offsets of 0x7e00, which is 32256 in decimal; dividing by 512 byte sectors, this means that the partitions or volumes start at sector 63 on their respective hard drives [note that \DosDevices\C: refers to the hard drive installed in the system, and is used as an example].

What this means is that there is not a direct method for mapping a USB external hard drive listed in the Enum\USBStor key to a drive letter listed in the MountedDevices key.

Although not specifically recognized as a device, per se, the MountedDevices key also maintains information about True Crypt [21] volumes that had been mounted on the system, as shown in Figure 3.20.

As you can see, the value name is a bit different from other entries within the Mounted Devices key, and the binary data is 16 bytes long and spells out “TrueCryptVolumeU.” I have seen other similar values where the data spells out “TrueCryptVolumeT” or “TrueCryptVolumeS.” Although this will give you an indication of a user-accessing TrueCrypt volumes, it does not explicitly tell you where those volumes exist.

Portable Devices

On Vista and Windows 7, even more information is maintained about attached [portable] devices, albeit in the Software hive. Beneath the Microsoft\Windows Portable Devices\Devices key, you will see a number of subkeys that refer to devices. The subkey names can be parsed to get the name of the device and, if available, the device serial number. These subkeys also contain a value named “FriendlyName,” which, in many instances, will include the drive letter to which it was mounted, such as “Removable Disk [F:].” Further testing is required, but in some limited sample cases, the LastWrite time for the device subkey seems to correlate closely to the time that the device was last connected to the system. For example, on one Vista test system, a device [DISK&VEN_BEST_BUY&PROD_GEEK_SQUAD_U3&REV_6.15, with serial number 0C90195032E36889&0] had a subkey beneath the Devices key with the LastWrite time of Thu Feb 7 13:26:19 2008 [UTC]. The corresponding subkey for the same device, beneath the DeviceClasses subkey [we will discuss this key later in the chapter], had a LastWrite time of Thu Feb 7 13:26:02 2008 [UTC].

When a USB device is first plugged into a Windows system, the PnP manager queries the device to determine information about the device, in order to figure out which drivers to load for that device. On Windows XP and 2003 systems, this information is maintained in the setupapi.log file [for Vista/Windows 7, the file is setupapi.dev.log [22]]. Once the device is loaded, two additional keys are created for the device beneath the DeviceClasses key within the System hive. Both of these keys are globally unique identifiers [GUIDs]; one refers to disks, and the other refers to volumes, as shown below:

Disk GUID – {53f56307-b6bf-11d0-94f2-00a0c91efb8b}

Volume GUID – {53f5630d-b6bf-11d0-94f2-00a0c91efb8b}

Both of these GUIDs are defined in the ntddstor.h header file used in Windows. The first GUID, which begins with “53f56307,” is defined as GUID_DEVINTERFACE_DISK, or DiskClassGUID, and refers to disk devices. An example of what the DiskClassGUID subkeys look like is shown in Figure 3.21.

As shown in Figure 3.21, we see keys whose names begin with “##?#USBSTOR#”; these keys go on to contain device names that look very much like the device descriptor names from the USBStor key mentioned earlier in the chapter. The key name also contains the unique device descriptor or serial number for the device. According to research conducted and published by Rob Lee [of Mandiant and SANS fame], the LastWrite time for this key indicates the first time that the device was last connected to the system during the most recent boot session. What this means is that if the system was booted at 8:30 a.m. and the device was connected to the system at 9:00 a.m., disconnected, and then reconnected later that day, the LastWrite time of the device's subkey beneath the DiskClassGUID key will be 9:00 a.m. This should remain consistent regardless of the number of times the device is disconnected and reconnected to the system.

Tip

According to Rob Lee's research, the time that a USB device was last connected to a Vista system can be correlated to the LastWrite time of the ControlSet00n\Enum\USB key for the device. For Windows 7 systems, the LastWrite time of the ControlSet00n\Enum\USBStor key for the device will tell you when it was last connected to the system.

The other GUID is defined as GUID_DEVINTERFACE_VOLUME, or VolumeClassGUID, and refers to volumes. The subkeys beneath this key are associated with volumes that are mounted on the system, as shown in Figure 3.22.

As illustrated in Figure 3.22, the device's key name contains the ParentIdPrefix value for the device, mentioned earlier in this chapter.

USB Devices

According to research conducted and presented by Rob Lee, additional information regarding determining the last time that a USB device was connected to a system is available in the user's NTUSER.DAT hive, specifically beneath the MountPoints2 key. This will be discussed in greater detail in Chapter 4, “Case Studies: Tracking User Activity,” but this provides an analyst with two important pieces of information: First one is, of course, the last time that the device was connected to the system. The second one is that by the presence of the key within the user's hive, there is now an association with a specific user. Although a device may have been connected to a system, the analyst will be able to determine the time frame that it was last connected, which may be important when developing a time line of activity on the system, as well as which user account was logged in when the device was connected.

Restore Points

► Some versions of Windows make routine backups of Registry hives that can contain information that is no longer present in the current Registry. In addition to looking in backup Registry hives for the same information as in the current hives as summarized earlier, there are unique types of analysis that the Restore Point backups can support.

•

Look back: Information from past states of the system that is captured in a Restore Point can be useful in an intrusion and malware investigation.15

Comparative analysis: Comparing the Registry from prior states of a compromised system can uncover important changes.16

Temporal analysis: The LastWritten date-time stamps within the backup Registry hives can help develop the time line of malicious activities on a compromised system.

Restore Points

On a routine basis, certain versions of the Windows operating system [ME, XP, and Vista] save backups of certain important files, including the Registry, for disaster recovery purposes. These backups are called System Restore Points, and are saved in the hidden “System Volume Information” folder. For instance, when certain types of files are deleted, like executables and dynamic link libraries [DLLs], copies are saved in a Restore Point [“RP#”] subfolder along with a change log that records the original path of each file. A case study of how this information can be useful in an intrusion and malware investigation is covered in Kris Harms’ “Forensic analysis of System Restore points in Microsoft Windows XP,” Journal of Digital Investigation, Volume 3, Issue 3, Pages 107–184 [September 2006] Available online at www.mandiant.com/documents/MRPA_WhitePaper.pdf.

Restore Points can occupy up to 12 percent of large hard drives, and can contain significant amounts of historical data about a Windows system. This historical information can be used by a digital investigator to compare various states of the computer over time to determine when malware was placed on the system. For instance, copies of Registry files within the “snapshot” folder within each System Restore Point can be compared using a tool such as Regsnap [www.lastbit.com], to determine what items changed in the period bounded by the two snapshots. Information about mounted network shares, user accounts, installed programs, and other items of potential relevance may be found in these archived Registry files.

Case Scenario

Other Tools to Consider

Srdiag Tool for extracting information from System Restore Points [www.kellys-korner-xp.com/xp_restore.htm]

MANDIANT Restore Point Analyzer Tool for interpreting certain files in Restore Points [www.mandiant.com/softwaredist/RestorePointAnalyzerSetup.zip].

RipXP.pl

RipXP is a unique version of rip.pl/.exe that was written specifically for Windows XP. One of the things I had wanted to do, and something Rob Lee once said, “hey, wouldn't it be cool if you could …,” was to run a single plug-in against not only a specific hive file on a Windows XP system but also to have that same plug-in run automatically against the hive files stored in any and all available Windows XP System Restore Points. For that purpose, I developed ripXP.pl, and the “XP” in the name referring to the fact that it is intended only for Windows XP, as that is the Windows operating system that maintains System Restore Points in the format accessed by the tool. The syntax information for ripxp.pl appears as follows:

C:\Perl\tools>ripxp.pl

RipXP v.20090818 - CLI RegRipper tool

RipXP [-r Reg hive file] [-p plugin module][-d RP dir][-lgh]

Parse Windows Registry files, using either a single module from the plugins folder. Then parse all corresponding hive files from the XP Restore Points [extracted from image] using the same plugin.

  -r Reg hive file…Registry hive file to parse

  -g …………….Guess the hive file [experimental]

  -d RP directory….Path to the Restore Point directory

  -p plugin module…use only this module

  -l …………….list all plugins

  -h……………..Help [print this information]

Ex: C:\>ripxp.pl -g

  C:\>ripxp.pl -r d:\cases\ntuser.dat -d d:\cases\svi -p userassist

All output goes to STDOUT; use redirection [ie, > or >>] to output to a file.

copyright 2008 H. Carvey

There's a little work required in order to run ripxp.pl [or the .exe version] correctly. System Restore Points are maintained in the “System Volume Information” directory, and NTFS permissions prevent even Administrators from directly accessing that directory. The least complicated way to handle this issue when your analysis system is running Windows is to open your acquired image in FTK Imager [or the Lite version, both of which are freely available from AccessData] and to extract the Restore Point directories to a directory structure on your analysis system, as illustrated in Figure 2.15.

Once you've extracted the Restore Point directories in a manner similar to what's illustrated in Figure 2.15, be sure to also extract the “live” Registry hives from the image as well. In the example illustrated in Figure 2.15, I extracted the files to the “training\Files” directory. Now, to run ripXP against the “live” System hive and the corresponding System hives in the Restore Point directories, simply use the following command:

C:\tools>ripxp –r d:\training\Files\System –d d:\training\rp –p mountdev

It should be easy to see that ripXP is best used with plug-ins that extract data that may have changed over time. In the case of the above example, as various external devices are attached to the system, we would expect some of the values to change, particularly those that begin with “\DosDevice\.” Another plug-in that may be useful to run across the System hives in the Restore Points is shares.pl; this may provide you with information about shares that were available at some point in the past, when a Restore Point was created, but has since been removed or “unshared.”

Another example where this would be extremely valuable would be to run the userassist.pl plug-in against a user's NTUSER.DAT hive [found in the root of the user profile, as described in Chapter 1, “Registry Analysis”], as well against all those hives available in the System Restore Points, using the following command:

C:\tools>ripxp –r d:\training\Files\ntuser.dat –d d:\training\rp –p userassist

The value of the contents of the UserAssist key will be addressed in greater detail in Chapter 4, “Case Studies: Tracking User Activity,” but it is suffice to say at this point that there may be a great deal of information available, particularly on a heavily used system. Over time, some keys and values may be updated, modified, or even deleted, and being able to see what was available at some point in the past can be [and believe me, has been] of great value to an analyst.

A tool like this can also be used to great effect when Registry keys or values have been deleted. There are tools that will delete certain keys; for example, Window Washer [version 4.7] would delete the user's RecentDocs [also discussed in detail in Chapter 4, “Case Studies: Tracking User Activity,”] key. We will discuss in some detail later in this chapter how deleted keys and values can be recovered from unallocated space within a hive file, but having the ability to retrieve historical data from the Registry can be extremely valuable. Not only can we retrieve deleted keys, but being able to go back in time and get historical information about key and value contents from points in the past can be extremely valuable.

One final point about this tool: ripXP is not intended to be used to analyze Registry hives from Volume Shadow Copies. This is a completely different backup technology employed on Windows Vista systems and beyond and does not operate or provide data in a manner similar to Windows XP System Restore Points.

What are “volume shadow copies”?

VSCs are one of the new, ominous sounding aspects of the Windows operating systems [specifically, Windows XP, in a limited manner, and more so with Vista and Windows 7] that can significantly impact an analyst’s examination. VSCs are significant and interesting as a source of artifacts, enough to require their own chapter.

With the release of Windows XP, Microsoft introduced the Volume Shadow Copy Service to provide functionality for backing up critical system files in order to assist with system recovery. With Windows XP, users and administrators saw this functionality as System Restore Points which were created automatically under various conditions [every 24 hours, when a driver was installed, etc.] and could also be created manually, as illustrated in Figure 3.1.

As illustrated in Figure 3.1, users can not only create Restore Points, but they can also restore the computer to an earlier time. This proved to be useful functionality, particularly when a user installed something [application, driver, etc.] that failed to work properly, or the system became infected with malware of some kind. Users could revert the core functionality of their systems to a previous state through the System Restore functionality, effectively recovering it to a previous state. However, System Restore Points do not back up everything on a system; for example, user data files are not backed up [and are therefore not restored, either], and all of the data in the SAM hive of the Registry is not backed up, as you wouldn’t want users to restore their system to a previous point in time and have them not be able to access it, as a previous password had been restored. So, while System Restore Points did prove useful when a user needed to recover their system to a previous state, they did little to back up user data and provide access to previous copies of other files. From a forensic analysis, a great deal of historical data could be retrieved from System Restore Points, including backed up system files and Registry hives. Analysts still need to understand how backed up files could be “mapped” to their original file names but the fact that the files are backed up is valuable in itself.

Tip

With the release of Vista, the functionality provided by the Volume Shadow Copy Service to support services such as Windows Backup and System Restore was expanded. In particular, the amount and type of data captured by System Restore was expanded to include block-level, incremental “snapshots” of a system [only the modified information was recorded] at a given point in time. These “snapshots”—known as VSCs—appeared in a different manner to the user. VSCs operate at the block level within the file system, backing up and providing access to previous versions of system and user data files within a particular volume. As with System Restore Points, the actual backups are transparent to the user, but with VSCs, the user can restore previous versions of files through the Previous Versions shell extension, as illustrated in Figure 3.2 [from a Windows 7 system].

Okay, so what does this mean to the forensic analyst? From an analyst’s perspective, there is a great deal of historical information within backed up files. Accessing these files can provide not just historical data [previous contents, etc.] but additional analysis can be conducted by comparing the available versions over time.

System-Based Security Applications

There are security applications aimed specifically at performing system security functions. Some of these applications are free. Some must be purchased. Either way, you should perform a thorough evaluation of any product before you deploy it in your environment. Not all these programs provide the same level of protection or support. Many times, you will have to deploy a combination of them to adequately protect your environment.

Deleted Keys and Values

In the spring of 2008, Jolanta Thomassen contacted me about providing an idea [and being a sponsor] for her dissertation for work at the University of Liverpool. I pointed her to an old [c.2001] post on the Internet, asking about unallocated space within a Registry hive file. Not long after, Jolanta produced regslack, a Perl script that combs through a hive file and locates deleted keys and unallocated space. If you remember from chapter Registry Analysis, when a key is deleted, the first 4 bytes [DWORD] of the key, which is the length of the key, is changed from a negative value [as a signed integer] to a positive value. For example, if the “live” key had a length of −120 as decimal value, then the deleted key length is 120.

Regslack is a command line tool, and very easy to use. Simply open a command prompt and pass the path to the Registry file in question to the program:

C:\tools>regslack.pl d:\cases\test\software

Regslack sends its output to the console [ie, STDOUT], so be sure to redirect it to a file [ie, “> file”], as in some cases, there can be quite a lot of information. Regslack has proven quite useful during a number of examinations. For example, if you find indications of a user account being active on a system but can’t find that account listed in the SAM hive, try running regslack against the hive file. In one instance, I found indications of a user account with the name “Owner” and an RID of 1003 in the Event Logs on the system, but no indication of such an account within the SAM hive. Running regslack, I found the following:

SAM\SAM\Domains\Account\Users\Names\Owner

Offset: 0x3c70 [Fri Jun 18 17:03:22 2004]

SAM\SAM\Domains\Account\Users\000003EB

Offset: 0x3d08 [Fri Jun 18 18:59:27 2004]

The second key [Users\000003EB] had two values [F and V] associated with it, just as you’d expect for a local user account. The V value included the name “Owner.” Thanks to regslack, I’d found the user account, as well as the time when the account had been deleted, indicated by the time stamp “[Fri Jun 18 17:03:22 2004].” With a little more work, using Perl code that I’ve already written [as part of RegRipper], I could extract and translate that binary data from those values into something a bit more understandable.

I have also used regslack to great effect to recover deleted keys and values from a user’s hive file, in particular after the user had run an application called Window Washer on their system. I researched the version of the application and found that it reportedly did delete certain keys when run. Sure enough, the key was not visible in the allocated [or “live”] space within the hive file, but it was fairly easy to recover using regslack. There were indications that Window Washer had been run several times, so I suggested to the customer that we extract the user hive files from the System Restore Points and see if we could find anything of value within them.

Tip

Jolanta’s dissertation is available online at the SentinelChicken website at //sentinelchicken.com/data/JolantaThomassenDISSERTATION.pdf.

As of version 0.51, the Parse::Win32Registry module also has the ability to extract deleted keys and values from within a hive file. One of the scripts that James provided with the distribution of the module, regscan.pl, includes code that references checking whether or not a found entry is allocated [ie, $entry->is_allocated]. Modifying the code slightly to skip over and not display allocated entries allows us to see just the deleted keys and values. The documentation that James has provided for the module includes a section on lower level methods for processing hive files and refers to the entry object methods that allow for a lower level of access to entries within the hive file. This can allow us to walk through a hive file and locate deleted keys and values.

Tip

I wrote a RegRipper plugin [del.pl] for extracting information about deleted keys and values found within a hive file. There is also a plugin named del_tln.pl that will output the information about deleted keys in the appropriate five-field format for use in timelines.

As we’ve already discussed earlier in this chapter, there are a number of other tools that will also retrieve deleted Registry keys and values as well as display unallocated space within the hive file. As of this writing, Eric Zimmerman has put a great deal of effort into ensuring that his tool, Registry Explorer, correctly locates and displays information about deleted keys and values.