Quick Guide to Windows Registry Hives

9 min readJun 2, 2024

Scenario Anna, the IR lead at Deer Inc., is investigating suspicious activity on one of the systems. She had been tipped off due to a new user creation activity on the machine. For further analysis, she decided to pull the registry data from the system to answer some questions and identify the scope of the incident. Let’s help Anna verify the following information by analysing the attached VM: Information that can be used to identify the system. User accounts on the system, as well as any suspicious user account. Any password resets or wrong password inputs. Networks that the system connected to in the past.

Scenario Overview

Anna, the Incident Response (IR) lead at Deer Inc., is investigating suspicious activity on a system. She received a tip-off about a new user creation activity on the machine. To analyze this further, she decided to pull the registry data from the system. The goal is to help Anna by analyzing the attached Virtual Machine (VM) and verify the following information:

Information that can be used to identify the system.
User accounts on the system, as well as any suspicious user account.
Any password resets or wrong password inputs.
Networks that the system connected to in the past.

Steps for Analysis

To assist Anna in verifying the requested information, we will need to perform the following steps:

Acquire the Registry Hives:

Extract the necessary registry hives from the live or cold system. The primary hives of interest include:
SYSTEM: Contains system-wide configuration settings.
SOFTWARE: Contains installed software information.
SECURITY: Contains local security policies.
SAM: Contains user account information.
NTUSER.DAT: Contains user-specific settings for each user profile.

2. Tools for Analysis:

Use tools such as RegRipper, FTK Imager, KAPE (Kroll Artifact Parser and Extractor), or Eric Zimmerman’s Tools to parse and analyze the registry hives.
These tools help extract meaningful data and automate parts of the analysis process.

3. Identify System Information:

Look for system identifiers such as:
Computer Name: Located in SYSTEM hive under ControlSet001\Control\ComputerName\ComputerName.
Installed OS Information: Located in SOFTWARE hive under Microsoft\Windows NT\CurrentVersion.

4. Analyze User Accounts:

Extract user account information from the SAM hive.
Look for recently created or suspicious user accounts by examining the Users and Groups keys.

5. Check for Password Resets and Incorrect Password Inputs:

Analyze the SECURITY and SYSTEM hives for any password reset activities or incorrect password attempts.
Event logs (if available) in the SYSTEM hive under Windows\CurrentVersion\Authentication\LogonUI can provide insight into login activities.

6. Identify Network Connections:

Review the SYSTEM hive, specifically the ControlSet001\Services\Tcpip\Parameters\Interfaces key for historical network connections.
Check for DHCP leases and other network settings that might indicate previous network connections.

Practical Implementation

Using the tools mentioned, follow these practical steps:

Extracting Registry Hives:

Use FTK Imager to mount the VM and extract the registry hives (SYSTEM, SOFTWARE, SAM, SECURITY, NTUSER.DAT).

2. Running RegRipper:

Use RegRipper to parse the extracted hives and generate reports.

3. Analyzing the Reports:

Review the RegRipper reports to identify system information, user accounts, password activities, and network connections.

Learning Objective:

How to acquire registry hives from both live and cold systems.
Tools for analyzing and parsing data within registry hives.
Questions that can be answered through system registry analysis.

Live Acquisition

During a live acquisition, data is gathered from a system while it’s operational. The Windows OS is already loaded into memory, containing all configurations. However, registry hive files are typically locked on a live system and cannot be copied without specialized tools. Since the configuration is already loaded, there’s no need to analyze the registry to identify the active configuration (e.g., the CurrentControlSet key is readily available, indicating which configuration is in use).

However, a challenge with live acquisition is that the tools used may leave traces and overwrite critical data points. For instance, using FTK Imager to collect live data can add entries to registry keys tracking program execution. Despite this, live acquisition is commonly preferred to save time, especially in urgent situations where immediate results are necessary.

Cold Acquisition

In contrast, cold data acquisition occurs when the system is offline. A full disk image of the system is taken with the hard disk drive placed in a write blocker to maintain data integrity. After shutting down the system, the disk image is hashed, copied, and analyzed, preserving the original evidence’s integrity. To analyze the registry from a cold acquisition, the disk image is mounted using image mounting software, and the data is extracted from the mounted image.

Although cold acquisition is time-consuming due to multiple steps involved, it minimally impacts the system under analysis. Cold acquisition is preferred when data integrity must be ensured, such as for legal purposes. Tools like FTK Imager and Autopsy can perform both steps simultaneously, eliminating the need for separate image mounting software.

Data Acquisition Using FTK Imager

In a cold system, we don’t access the C drive of the current system. Instead, we navigate to the path of the target system and choose the disk image containing the data we want to extract. This is accomplished by selecting “Image File” from the “Add Evidence Item” menu.

After selecting “Image File” from the “Add Evidence Item” menu, we navigate to the location where the image file is saved and add it to FTK Imager. This step is the only distinction between exporting files from a live disk versus a cold disk image. Once the evidence is added to FTK Imager, the subsequent process remains unchanged.

In a live system, registry data can be obtained by selecting the “Obtain Protected Files” option in FTK Imager. It’s important to note that registry files are locked and not readily copyable in a live system. While we won’t utilize this option presently, it serves as a method to access these locked and protected files. If chosen, we can export these files to a preferred location for further analysis.

However, the aforementioned method has limitations as it doesn’t capture all registry hives. For instance, the Amcache hive, crucial for understanding program execution, isn’t copied using this method. Additionally, the option at the bottom-left of the screenshot indicates that this feature exports files primarily for facilitating a SAM attack, targeting the SAM registry hive to exploit user credentials.

A more effective approach to exporting registry keys with FTK Imager involves navigating to the specific location where the hives are stored and exporting the necessary files. This can be achieved by manually expanding the disk image and navigating through directories. Importantly, this method is applicable to both live and cold acquisitions. Once the desired location is reached, the relevant files are selected for export. Subsequently, by clicking the “Export Files” option, the chosen files are exported to a designated location.

In the provided screenshot, we’re copying registry hives, transaction logs, and backup files containing changes not yet written in the registry hives but already made. These components, discussed in Windows Forensics 1, can hold crucial pieces of information essential for our analysis.

In Task 1’s scenario, we outlined Anna’s objective to extract information from the system. As learned in Windows Forensics 1, this information typically resides in the SAM, SYSTEM, and SOFTWARE registry hives within the C:\Windows\System32\config directory. Anna can use FTK Imager to extract these hives. To ensure comprehensive data capture, she also needs to extract transaction logs, a process achievable with FTK Imager, available on the Desktop of the attached VM.

The primary advantage of using FTK Imager for data extraction lies in its specificity and granularity. We can precisely select the files we want to extract. However, this process demands precise knowledge and time for execution. In certain scenarios, automation tools may offer a more efficient approach, as we’ll explore in subsequent tasks.

While Anna could utilize FTK Imager for registry data extraction, it involves a manual process. Ideally, she seeks a method that minimizes human involvement to reduce the risk of errors and simplifies delegation to her team members. Although automated processes typically prioritize speed and efficiency, manual methods offer advantages such as granularity and specificity. In this task, we’ll explore automating the data acquisition process using KAPE.

Data Acquisition Using KAPE

KAPE, short for Kroll Artifact Parser and Extractor, is a powerful tool designed to swiftly collect and process triage data from systems. While commonly used on live systems, KAPE can also be applied to disk images by mounting them and specifying the mounted disk image drive as the target location. Any image mounting software can be utilized for this purpose, maintaining a consistent process. Although FTK Imager is capable of mounting images, running KAPE concurrently with FTK Imager may result in issues, requiring the selection of the “Ignore FTK warning” checkbox to proceed with KAPE execution.

To initiate the process, the gkape.exe executable, located in the KAPE folder within the attached VM, can be launched, opening the KAPE GUI interface. This interface provides a user-friendly environment for initiating data acquisition tasks.

Since we are to collect data, we will select the Use Target Options checkmark. This will make the left side of the KAPE GUI available for us to modify.

KAPE is an extensible and highly configurable tool. Essentially, the KAPE binary collects files and processes them based on the provided configuration.

During file collection (targets), KAPE adds the files to a queue and copies them in two passes. In the first pass, it copies the files that are accessible, i.e., those not locked by the operating system. The remaining files are placed in a secondary queue. The secondary queue is processed using a different technique that involves raw disk reads to bypass OS locks and copy the files. The copied files retain their original timestamps and metadata and are stored in a similar directory structure.

After data collection, KAPE can process it using modules. These modules are independent binaries that run on the collected data and extract information. For instance, during target collection, KAPE will gather and copy the Prefetch file to the destination. Running a Prefetch Parser (PECmd) module on this target will extract the prefetch file and save it in a CSV format file.

Once in the KAPE GUI interface, we can proceed by specifying the source disk drive’s path in the “Target source” option and indicating the desired destination path for storing the collected triage data in the “Target destination” field. When collecting triage data from a disk image, we select the disk drive where the disk image mounter has mounted the disk image. In a live system, the C drive (or the OS drive if it’s different from C) can be chosen.

After selecting the source and destination paths, we can opt for one of the available collection options. For a comprehensive triage package encompassing essential forensic artifacts, we can choose “KapeTriage.” Alternatively, if only the registry is needed, we can utilize the search option to locate and select one of the registry triage collections. It’s important to remember to uncheck the “Flush” checkbox if we don’t want to overwrite all data in the destination folder.

For the target option and module option, I create a file called Target Collected File in Desktop, and then I create a file called outpu in the same folder. I will give the output to Module Destination.

Since I want to perform Kape triage, I click find on the left and select KapeTraige. On the right, I select EvtxECmd, a command line tool developed by Eric Zimmerman. This tool is used to process Windows event log files. Finally, I click Execute and wait for the process to end.