Skip to content

CH4: Windows Registry Forensics – Part 1

Chapter Overview

The Windows Registry is often described as the "DNA" of the operating system. While its primary function is to store configuration settings for hardware, software, and user preferences, it inadvertently serves as a detailed log of nearly every action performed on a device. For a digital forensic examiner, understanding the Registry is not optional—it is fundamental to solving cases ranging from data theft to malware infections. In this chapter, we will demystify the complex architecture of the Registry, learn how to navigate its logical and physical structures, and begin the process of extracting high-value evidence that connects a specific user to specific actions.

Learning Objectives

By the end of this chapter, you will be able to:

  • Deconstruct the logical and physical architecture of the Windows Registry, distinguishing between Hives, Keys, and Values.
  • Identify and locate critical registry files on a live or dead system to facilitate forensic acquisition.
  • Analyze key registry artifacts to reconstruct user activity, including USB device connections, program execution, and folder access.
  • Compare and select appropriate tools for registry acquisition and analysis, moving beyond native Windows tools to forensic-grade solutions.
  • Explain the mechanics of registry transaction logs and the necessity of "cleaning" dirty hives to ensure data integrity during analysis.
  • Translate Security Identifiers (SIDs) into human-readable usernames to properly attribute actions to a suspect.

4.1 Introduction: The Nervous System of Windows

If the file system (NTFS) is the "filing cabinet" of the operating system, the Windows Registry is its nervous system. It is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry. The kernel, device drivers, services, Security Accounts Manager (SAM), and user interface can all use the registry.

For a digital forensic examiner, the registry is arguably the single most dense source of evidence on a computer. It does not just store configuration data; it inadvertently logs human behavior. Every time a user inserts a USB drive, opens a file, connects to a wireless network, or types a URL, the registry changes.

In this chapter, we will strip away the complexity of the registry to understand its structure, how to capture it, and how to begin extracting the "low-hanging fruit" artifacts that solve cases.

4.2 Registry Architecture

To analyze the registry, you must first understand how Windows organizes it logically (what you see on the screen) versus physically (files on the disk).

Logical Structure: The Tree

When viewing the registry through a tool like RegEdit, it appears as a single, unified tree structure. This structure consists of Keys (which act like folders), Subkeys (sub-folders), and Values (the actual data files within the folders).

There are five root keys that serve as the entry points for the registry. As a forensic examiner, you must memorize these abbreviations and their functions:

Root Key (Handle) Abbreviation Forensic Significance
HKEY_LOCAL_MACHINE HKLM Contains configuration data for the local computer. This information applies to the system regardless of which user is logged in. Crucial for system artifacts.
HKEY_CURRENT_USER HKCU Contains the configuration data for the user currently logged in. This is a link to the specific user's NTUSER.DAT file. Crucial for attribution.
HKEY_USERS HKU Contains all actively loaded user profiles on the computer. HKCU is actually a subkey of this.
HKEY_CLASSES_ROOT HKCR Contains file association and OLE (Object Linking and Embedding) information. Less critical for general forensics, but useful for malware association.
HKEY_CURRENT_CONFIG HKCC Contains information about the hardware profile that is used by the local computer at system startup.

Physical Structure: The Hives

While the logical view looks like one big database, the registry is actually composed of several distinct files stored on the disk, known as Hives.

When you are performing a "Dead Box" analysis (analyzing a disk image of a computer that is turned off), you cannot open RegEdit. Instead, you must locate and extract specific hive files.

System-Level Hives These store machine-wide settings and are located in C:\Windows\System32\config\.

  • SAM: Security Accounts Manager (Usernames, groups, password hashes).
  • SECURITY: System security policies.
  • SOFTWARE: Installed software settings, version information.
  • SYSTEM: Windows settings, device drivers, timezone information, USB history.

User-Level Hives These store data specific to a user (search history, recent files, theme settings).

  • NTUSER.DAT: Located in the root of the user's profile folder (C:\Users\%USERNAME%\).
  • UsrClass.dat: Located in C:\Users\%USERNAME%\AppData\Local\Microsoft\Windows\. This hive stores specific ShellBag information and file associations.

Forensic Tip: You will often hear the term "AmCache." The AmCache.hve is another hive file located in C:\Windows\AppCompat\Programs\. It is technically a registry hive but is often treated separately due to its specific use in tracking application execution.

4.3 Registry Data Types and Timestamping

Data Types

Inside the keys are values, which hold specific data. Common types you will encounter include:

  • REG_SZ: A standard string of text (e.g., a file path).
  • REG_BINARY: Raw binary data. This is often where forensic gold is hidden because it is not human-readable without decoding (e.g., UserAssist ROT13 data).
  • REG_DWORD: A 32-bit number (often used for boolean flags like 0 or 1).
  • REG_MULTI_SZ: A list of strings (e.g., a list of recent files).

The "Last Write" Time

This is the most critical concept for Registry Forensics. Registry Keys have a "Last Write" timestamp; Registry Values do not.

This functions similarly to a folder in a file system. If you change a value inside a key, the key's "Last Write" timestamp is updated. However, if a key contains 50 different values, the timestamp only tells you that one of them changed, not which specific one. This limitation requires examiners to correlate registry timestamps with other system events (like file system timestamps or event logs) to build a solid timeline.

⚠️ CRITICAL FORENSIC WARNING: The UTC Trap

Unlike some file system timestamps which can be local, Registry Last Write times are stored in UTC (Coordinated Universal Time).

When you view the registry in a tool like Registry Explorer, check your settings! Are you viewing the time as it was stored (UTC) or adjusted to your forensic workstation's local time? If you are in New York (EST) analyzing a computer from London (GMT) and you do not account for the timezone offset, your timeline could be off by several hours. In a criminal case, a 5-hour difference is an alibi.

Tip

Best Practice: Always report findings in UTC to avoid confusion, especially if the investigation spans multiple time zones.

The "Rosetta Stone" of the Registry: Mapping SIDs

In a live environment, Windows politely shows you user names (e.g., "Jane Doe"). However, internally, Windows does not care about your name; it identifies you by a Security Identifier (SID).

A SID looks like this: S-1-5-21-124525095-708259637-1543119021-1001

When you are performing a "Dead Box" analysis, you will often find evidence associated with a SID rather than a name. For example, the HKEY_USERS root key lists SIDs, not names. To attribute activity to a specific suspect, you must map this number back to a username.

The ProfileList Key To do this, you check the SOFTWARE hive.

  • Key Location: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Inside this key, you will see a list of all SIDs on the system. By clicking on a SID, you can look at the ProfileImagePath value.

  • Example: %SystemDrive%\Users\JDoe

This confirms that SID ...-1001 belongs to the user account "JDoe." This is a mandatory step in any forensic report; never refer to a user solely by their SID if you can identify their actual account name.

4.4 Critical Forensic Artifacts (System & Device)

We will now cover specific registry keys that provide high-value evidence. We will divide these into System/Device artifacts (usually found in HKLM) and User artifacts (found in HKCU/NTUSER.DAT).

Mounted Devices & USB Forensics

One of the most common requests in both law enforcement and corporate espionage cases is: "Did the suspect copy data to an external drive?"

To answer this, we look at the SYSTEM hive.

Key Location: HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR

This key contains a subkey for every USB storage device ever connected to the system. The naming convention usually follows: Disk&Ven_VENDOR&Prod_PRODUCT&Rev_VERSION

Inside this key, you will find the device's Unique Serial Number. If the serial number has an & in the second position, it indicates the device does not have a unique serial number, and the system generated a generic ID—a common trait in cheap, promotional USB drives.

Cross-Reference: Once you have the serial number from USBSTOR, you verify it in the MountedDevices key: HKLM\SYSTEM\MountedDevices

This key maps the volume GUIDs and serial numbers to drive letters (e.g., E:, F:). This connects the physical device (USB Stick) to the logical action (The user accessed Drive F:).

AutoStart (Run Keys)

Malware often needs to "survive" a reboot. To do this, it places an entry in a "Run" key to ensure it executes every time Windows starts. This is known as Persistence.

Common Locations:

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Run (Runs for all users)
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce (Runs once, then deletes itself)
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run (Runs only for the specific user)

Forensic Relevance: If you find a suspicious executable (like svchost.exe) running from a Temp folder listed in these keys, it is almost certainly malicious. Legitimate Windows services generally do not run from user temp directories.

Prefetch Parameters

While .pf (Prefetch) files are files on the disk, their configuration is governed by the registry.

Key Location: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters

Here, the EnablePrefetcher value tells you if prefetching is turned on.

  • 0 = Disabled
  • 3 = Application and Boot prefetching enabled (Default on Workstations)

If this value is 0, you will not find Prefetch files on the disk. This is common on SSDs in older versions of Windows or Windows Server environments.

4.5 Critical Forensic Artifacts (User Activity)

These artifacts help establish attribution—proving a specific human sat at the keyboard and performed an action.

UserAssist

This key tracks the execution of programs via the GUI (Graphical User Interface). If a user double-clicks an icon on the desktop or runs a program from the Start menu, it is logged here.

Key Location: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist

The Twist (ROT13): Microsoft obfuscates the names of the programs in this key using ROT13 (Rotate 13), a simple substitution cipher where A becomes N, B becomes O, etc.

  • Example: cmd.exe appears as pzq.rkr.

Forensic tools like Eric Zimmerman’s Registry Explorer automatically decode ROT13 for you. This artifact is vital because it tracks the Run Count and Last Execution Time, proving not just presence, but active usage.

ShellBags

ShellBags are often considered the "smoking gun" in data theft cases. They track the view settings (icon size, window position, sort order) for folders viewed in Windows Explorer.

Why is this important? Windows only saves these settings if a user actually opens and views the folder.

  • It proves Knowledge: The user knew the folder existed.
  • It proves Access: The user opened the folder.
  • It proves Existence: Even if the folder (and the drive it was on) is deleted or removed, the ShellBag entry remains in the user's registry.

Key Locations:

  • NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU
  • UsrClass.dat\Local Settings\Software\Microsoft\Windows\Shell\BagMRU

MRU Lists (Most Recently Used)

Windows tries to be helpful by remembering things you used recently. This is great for users, and better for forensics.

  • RecentDocs: (NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs) Tracks the last 150 files opened.
  • OpenSavePidlMRU: Tracks files opened or saved via the standard Windows "Open/Save" dialog box. This is powerful because it tracks the source of the file.
  • LastVisitedPidlMRU: Tracks the specific executable used to open the files listed above.

4.6 Registry Acquisition Tools

You cannot simply copy the registry files (like SAM or NTUSER.DAT) while Windows is running. The operating system locks these files exclusively. To acquire them, you must use tools that can bypass these file locks.

KAPE (Kroll Artifact Parser and Extractor)

KAPE is the current industry standard for triage and acquisition. It uses a "Target" system to copy locked files.

  • How it works: KAPE uses the Volume Shadow Copy Service (VSS) or raw disk reading to bypass file locks, copies the registry hives to a destination folder, and can even compress them into a VHDX or ZIP container.

FTK Imager

We have used FTK Imager previously for disk imaging, but it is also excellent for live registry acquisition.

  • Method: Go to File -> Obtain Protected Files.
  • Pros: It allows you to select exactly which hives you want (Password recovery vs. Full Registry).

RegEdit (Export)

Warning: Using File -> Export in the native Windows RegEdit tool is NOT forensically sound for deep analysis. The resulting .reg file is a text-based representation, not the raw binary hive. It strips away the "Last Write" timestamps and hidden metadata. Avoid using .reg exports for forensic analysis.

4.7 Registry Analysis Tools

Once acquired, you need tools to parse the binary hive structure.

Registry Explorer (Eric Zimmerman)

This is widely considered the best open-source GUI tool for registry analysis.

  • Features: It automatically detects deleted keys, highlights modified values, decodes ROT13 (UserAssist), and parses complicated binary data (like ShellBags) into human-readable tables.
  • Bookmarks: It comes pre-loaded with "Common" bookmarks that instantly navigate to the artifacts discussed in this chapter (Run Keys, MountPoints, etc.).

RegRipper

RegRipper is a powerful tool, often used via the command line or a simple GUI, that runs "plugins" against the hive files.

  • Workflow: You point RegRipper at an NTUSER.DAT file, select a profile (e.g., "User Specific"), and it generates a text report listing all relevant findings.
  • Pros: Excellent for automation and quick triage reporting.

4.8 Advanced Concept: Dirty Hives and Transaction Logs

The registry is a database, and like modern databases (SQL), it uses transaction logging to prevent corruption. This is a critical concept often missed by novice examiners.

The Mechanism

When Windows writes data to the registry, it doesn't always write directly to the main hive file (e.g., NTUSER.DAT). To improve performance and safety, it writes the change to a Transaction Log file first. These files usually have the extension .log1 or .log2. * Example: NTUSER.DAT.log1

Later, during idle time or shutdown, the system "flushes" the data from the log file into the main hive.

The Forensic Problem

If you pull the plug on a computer (cold boot) or the system crashes, the most recent data (the last few minutes or hours of activity) might still sit in the .log files and not in the main NTUSER.DAT file.

If you open only the NTUSER.DAT in a basic viewer, you will miss that recent evidence. This is called a "Dirty Hive."

The Solution: Replaying Logs

Advanced tools like Registry Explorer automatically detect these associated log files. When you load a hive, it will ask: "This hive is dirty. Do you want to replay the transaction logs?" Always say YES. The tool will temporarily merge the log data into the hive in memory, giving you the most accurate, up-to-the-second view of the system state.

4.9 Chapter Summary

The Windows Registry is the backbone of the operating system and a goldmine for forensics. We have learned that the registry is split into logical trees (HKLM, HKCU) and physical files (Hives). We explored how System hives (SYSTEM, SOFTWARE) provide evidence of hardware and installation, while User hives (NTUSER.DAT) provide evidence of human behavior through artifacts like UserAssist, ShellBags, and MRU lists.

Crucially, we identified that acquiring the registry requires bypassing file locks using tools like KAPE or FTK Imager, and that proper analysis requires handling "dirty hives" by replaying transaction logs to ensure no evidence is left behind. Finally, we learned the importance of mapping SIDs to usernames via the ProfileList key to ensure our forensic reports are accurate and attributable.