The Windows Registry as a Forensic Source

Hive files: where registry data lives on disk

The Windows Registry appears as a single unified tree when viewed through regedit.exe or the Registry Editor, but it is physically stored across multiple hive files on disk. Each hive file is a binary file containing a hierarchy of keys, values, and security descriptors. The hive files are loaded into memory at boot time (SYSTEM, SOFTWARE, SAM, SECURITY) or at user logon (NTUSER.DAT, UsrClass.dat), and the in-memory copy is the active registry. Changes to the registry are written to the in-memory copy and then flushed to disk periodically or at shutdown.

This architecture has two forensic implications. First, the on-disk hive file may be slightly behind the in-memory state — changes made since the last flush are in memory but not yet on disk. For live forensics, this means registry tools that read the hive file directly may miss very recent changes. For dead-box forensics (analyzing a disk image), this is not a concern because the system was shut down (or crashed), and the last flush captured the state.

Second, each hive file has companion transaction log files (.LOG1 and .LOG2) that record pending changes before they are committed to the main hive file. These transaction logs serve a dual forensic purpose: they ensure registry integrity after a crash (NTFS replays the transactions on next boot), and they preserve evidence of recent registry modifications that can be recovered even if the main hive file was subsequently modified. Registry Explorer can apply transaction logs to a hive to reconstruct its most recent state, and it can analyze the logs independently to identify recent modifications.

The five hive files an examiner needs

SYSTEM (%SystemRoot%\System32\config\SYSTEM) contains hardware configuration, service definitions, driver registrations, and device history. For forensic examiners, the critical subkeys are: CurrentControlSet\Services (every installed service — persistence mechanism), CurrentControlSet\Enum\USBSTOR (USB device history with device serial numbers), CurrentControlSet\Control\Session Manager\AppCompatCache (Shimcache), CurrentControlSet\Services\bam\State\UserSettings (BAM execution records), MountedDevices (volume mount history), and CurrentControlSet\Control\TimeZoneInformation (system timezone — essential for timestamp interpretation).

Determining the active ControlSet is itself a forensic step. SYSTEM contains multiple ControlSets (ControlSet001, ControlSet002, sometimes ControlSet003). The Select\Current value identifies which ControlSet was active at last boot. The Select\LastKnownGood value identifies the last successfully booted ControlSet. Tools like RECmd and Registry Explorer handle this automatically, but manual analysis requires checking Select\Current first.

SOFTWARE (%SystemRoot%\System32\config\SOFTWARE) contains machine-wide software configuration. Forensically significant subkeys include: Microsoft\Windows\CurrentVersion\Run and RunOnce (machine-wide autostart persistence), Microsoft\Windows\CurrentVersion\Uninstall (installed program inventory with install dates), Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles and Signatures (Wi-Fi network connection history with first/last connected timestamps and SSID), Microsoft\Windows NT\CurrentVersion (OS version, installation date, registered owner), and Classes (COM object registrations — used for COM hijack persistence).

SAM (%SystemRoot%\System32\config\SAM) contains local user account information. Each account record includes the username, the Security Identifier (SID), the account creation timestamp, the last logon timestamp, the last password change timestamp, the login count, and account flags (enabled/disabled, password required, locked out). SAM analysis is essential for account forensics: identifying accounts created during a compromise, detecting accounts that were enabled then disabled (indicating attacker cleanup), and establishing the timeline of account modifications.

NTUSER.DAT (%UserProfile%\NTUSER.DAT) contains per-user settings and activity records. This is the richest source of user activity evidence in the registry. Key forensic locations include: Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist (GUI program execution with run count and last run time — values are ROT13 encoded), Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths (paths typed into Explorer's address bar), Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery (Windows search queries), Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs (most recently used documents by file type), Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU (files opened/saved via file dialogs), and Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 (mounted drive letters the user interacted with).

UsrClass.dat (%LocalAppData%\Microsoft\Windows\UsrClass.dat) contains per-user class registrations and — most importantly for forensics — the ShellBag data. ShellBags record every folder the user navigated to in Windows Explorer, including folders on network shares, removable media, and ZIP file contents. The ShellBag data is stored under Local Settings\Software\Microsoft\Windows\Shell\BagMRU and Bags keys. UsrClass.dat is often overlooked by examiners who focus on NTUSER.DAT, but for insider threat investigations where folder access history is critical evidence, it is one of the most valuable hive files.

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.

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).

Troubleshooting

"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.