The Windows Registry as a Forensic Source

Hive files: where registry data lives on disk

The Windows Registry appears as a single unified tree in regedit.exe, but it is physically stored across multiple binary hive files on disk. Each hive is loaded into memory at boot (SYSTEM, SOFTWARE, SAM, SECURITY) or at user logon (NTUSER.DAT, UsrClass.dat). Changes are written to the in-memory copy and flushed to disk periodically or at shutdown.

This architecture has two forensic implications. First, the on-disk hive may be slightly behind the in-memory state, so live registry tools might capture changes the hive file hasn't received yet. For dead-box forensics this isn't a concern. Second, each hive has companion transaction log files (.LOG1 and .LOG2) that record pending changes before they're committed. These logs ensure integrity after crashes and preserve evidence of recent modifications recoverable even after the main hive is modified.

The hive binary format uses hive bins (4096-byte-aligned allocation units beginning with "hbin") containing cells: key cells (key name, last write timestamp, subkey/value counts, parent reference) and value cells (value name, data type, data). Deleted keys and values become free cells that retain their content until the space is reallocated. This is the mechanism behind deleted registry key recovery: tools scan free cells for parseable structures, analogous to MFT deleted file recovery.

The five hive files an examiner needs

SYSTEM contains hardware configuration, service definitions, driver registrations, and device history. Critical subkeys: CurrentControlSet\Services (persistence), CurrentControlSet\Enum\USBSTOR (USB device history with serial numbers), CurrentControlSet\Control\Session Manager\AppCompatCache (Shimcache), BAM/DAM execution records, MountedDevices (volume mount history), and TimeZoneInformation (essential for timestamp interpretation). Determining the active ControlSet requires checking Select\Current because SYSTEM contains multiple ControlSets.

This is what USB device history looks like in the SYSTEM registry hive. Each USBSTOR subkey represents a device class, and each device entry includes the serial number and last connection timestamp:

Key: SYSTEM\CurrentControlSet\Enum\USBSTOR
├── Disk&Ven_SanDisk&Prod_Ultra&Rev_1.00
│   └── 4C530001220803121180                   ◄ Device serial number
│       Last Write: 2026-03-12 16:45:08        ◄ Last time this USB was connected
│       FriendlyName: SanDisk Ultra USB 3.0
│       ContainerID: {a4f2b1c3-8d91-4e27-b456-1234abcd5678}
├── Disk&Ven_Kingston&Prod_DataTraveler&Rev_PMAP
│   └── 60A44C413C44B0209A20                   ◄ Different device
│       Last Write: 2025-11-28 09:12:33
│       FriendlyName: Kingston DataTraveler 3.0
│       ContainerID: {b5e3c2d4-9e82-5f38-c567-2345bcde6789}

The SanDisk device was last connected on March 12, the same date the Prefetch evidence shows 7-Zip executing. Cross-referencing MountedDevices reveals which drive letter was assigned, and MountPoints2 in the user's NTUSER.DAT confirms the user interacted with that drive letter.

SOFTWARE contains machine-wide software configuration. Key subkeys: Run and RunOnce (autostart persistence), Uninstall (program inventory with install dates), NetworkList\Profiles and Signatures (Wi-Fi connection history with timestamps and SSIDs), OS version and installation date, and Classes (COM object registrations used for COM hijack persistence).

SAM contains local user account information: username, SID, account creation timestamp, last logon timestamp, last password change, login count, and account flags. Essential for identifying accounts created during compromise and detecting accounts enabled then disabled (attacker cleanup).

NTUSER.DAT is the richest source of user activity evidence. Key locations: UserAssist (GUI program execution with run count and last run time, ROT13 encoded), TypedPaths (Explorer address bar history), WordWheelQuery (Windows search queries), RecentDocs (most recently used documents by file type), ComDlg32\OpenSavePidlMRU (files opened/saved via dialogs), and MountPoints2 (mounted drive letters the user interacted with).

UsrClass.dat contains per-user class registrations and the ShellBag data. ShellBags record every folder navigated in Explorer, including folders that have been deleted. The data is stored under Local Settings\Software\Microsoft\Windows\Shell\BagMRU and Bags keys.

Last write timestamps: scope and limitations

Every registry key has a last write timestamp recording when the key was last modified. This timestamp updates when any value under the key is created, modified, or deleted. Critically, the timestamp applies to the key, not to individual values. If a key contains 15 values and one is modified, the key's timestamp updates but there is no way to determine which value changed.

This limitation affects analysis directly. The UserAssist key {GUID}\Count contains dozens of values, each representing a program execution record. The key's last write timestamp tells you when the most recent UserAssist update occurred, not when a specific program was last executed. Individual execution timestamps are in the value data, not the key timestamp.

Transaction logs and deleted key recovery

Transaction logs (.LOG1, .LOG2) record registry modifications before they're committed to the main hive. They serve two forensic purposes: reconstructing the hive's most recent state (apply "dirty" pages), and recovering evidence of modifications subsequently overwritten. If an attacker created a persistence key then deleted it during cleanup, the creation may be recorded in the transaction log even though the main hive no longer contains it. The recovery window depends on subsequent registry activity.

Deleted key recovery from hive slack is separate from transaction log recovery. When a key is deleted, its cell becomes a free cell retaining its content until reallocated. Registry Explorer recovers deleted keys automatically from slack space. Reliability depends on time since deletion and subsequent hive activity.

Windows 10 introduced RegBack (periodic hive backups in System32\config\RegBack), but starting with version 1803, Microsoft disabled it by default. The RegBack directory may still exist but contain zero-byte files. Check file sizes before relying on them. For systems where RegBack is disabled, Volume Shadow Copies remain the primary source of historical registry states.

Common analysis issues

"There are thousands of registry keys — how do I know which ones to examine?" You don't examine the entire registry. You examine the keys that are relevant to your investigation type. For persistence analysis: Services, Run/RunOnce, Scheduled Tasks, COM objects, WMI subscriptions. For user activity: UserAssist, TypedPaths, RecentDocs, ShellBags, WordWheelQuery, ComDlg32. For device history: USBSTOR, MountedDevices, MountPoints2. For account forensics: SAM accounts, group membership, logon timestamps. WF7 provides the complete forensic reference for each key. This subsection provides the architectural understanding to interpret what you find.

"The last write timestamp on a service key shows last week, but the incident was three months ago." The last write timestamp updates on any modification to the key or its values. If Windows Update modified a service's ImagePath or Start value last week, the last write timestamp reflects that — not the original service creation time. The original creation time is not explicitly recorded in the registry. You can sometimes infer it from the first $UsnJrnl entry for the hive file that coincides with the key's creation, from the service's executable file creation timestamp in the MFT, or from Event Log records of service installation (System Event ID 7045). Multi-artifact correlation is essential for registry timeline analysis.

"How do I handle registry hives from a live system vs a disk image?" On a live system, hives are locked by the OS — you cannot copy them directly. KAPE handles this using raw disk access to extract locked files. On a disk image, hives are regular files accessible at their standard paths. In both cases, always collect the companion .LOG1 and .LOG2 files alongside each hive — without transaction logs, the hive may be in an inconsistent state that causes parsing errors.

Transaction logs and deleted key recovery

Each hive file is accompanied by transaction log files (.LOG1, .LOG2, and sometimes additional .LOG files for NTUSER.DAT). These logs record registry modifications in a journaling format: before a change is committed to the main hive file, it is written to the transaction log. If the system crashes during a write, NTFS replays the transaction log on next boot to bring the hive to a consistent state.

For forensic examiners, transaction logs serve two purposes. First, they can contain modifications that haven't been flushed to the main hive — applying the logs reconstructs the hive's most recent state. Registry Explorer prompts to apply "dirty" pages from transaction logs when loading a hive. Always apply transaction logs unless you specifically need the pre-modification state.

Second, transaction logs can contain evidence of modifications that were subsequently overwritten in the main hive. If an attacker created a persistence key, then deleted it during cleanup, the creation may be recorded in the transaction log even though the main hive no longer contains the key. The recovery window is limited. Transaction logs wrap as new transactions are recorded — but for recent modifications (within hours to days), transaction log analysis can reveal registry changes that are no longer visible in the main hive.

Deleted key recovery from hive slack is separate from transaction log recovery. When a key is deleted, its cell is marked as free but its content persists until the space is reallocated. Registry Explorer can recover deleted keys from slack space automatically (shown with a strikethrough or special icon in the key tree). The reliability of recovered data depends on how much time has passed since deletion and how much subsequent registry activity has occurred. High-churn hive files (SOFTWARE, NTUSER.DAT) reallocate deleted cells faster than low-churn files (SAM).

Last write timestamps: scope and limitations

Every registry key has a last write timestamp. A 64-bit Windows FILETIME recording when the key was last modified. This timestamp updates when any value under the key is created, modified, or deleted, and when any subkey is created or deleted. Critically, the timestamp applies to the key, not to individual values. If a key contains 15 values and one value is modified, the key's last write timestamp updates. But there is no way to determine which of the 15 values was the one that changed.

This limitation affects forensic analysis directly. Consider the NTUSER.DAT key Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{GUID}\Count. This key contains dozens of values, each representing a different program execution record. The key's last write timestamp tells you when the most recent UserAssist update occurred. Not when a specific program was last executed. The individual program execution timestamps are stored within the value data, not in the key's last write timestamp. An examiner who cites the key's last write timestamp as the execution time for a specific program is making an incorrect claim.

The second limitation is that last write timestamps are writable. An application with write access to a registry key can modify the key's last write timestamp by simply writing any value under the key. The act of writing triggers the timestamp update to the current time. An attacker who wants to obscure when they modified a persistence key can write a benign value to the key afterward, updating the last write timestamp to a later time. The original modification time is not preserved.