Windows Registry Forensics: Hives, Keys and Workflow

The registry is the single richest source of configuration and user-activity evidence on a Windows system, and one of the easiest to misread. This guide shows you where the hive files live, how to get a consistent copy, what timestamps you can and cannot trust, which keys answer the usual investigative questions, and how to process hives at scale with Registry Explorer, RECmd and RegRipper.

Hive files and where they live

The registry you see in regedit is assembled at runtime from several hive files, each a binary regf file mounted under a root key. A registry hive is the unit you collect and parse. The registry hives cheat sheet lists every path; the ones you will use in almost every case are:

NTUSER.DAT and UsrClass.dat exist once per profile, so collect them for every user, including service and administrator accounts. Amcache is technically a hive too and parses with the same tools, although dedicated parsers present it better.

Transaction logs and dirty hives

Windows does not write every change straight to the hive file. Changes are first recorded in transaction logs sitting next to each hive: SYSTEM.LOG1, SYSTEM.LOG2, NTUSER.DAT.LOG1 and so on. Since Windows 8.1 a newer log format lets modified data stay in the logs for a while (the commonly cited figure is up to an hour) before it is flushed to the primary file.

The base block (header) of a hive has a primary and a secondary sequence number. When they differ, the hive is dirty: the file on disk is behind the logs. This is normal for a copy taken from a running or crashed system, and for cloud snapshots.

Consequences:

• Always collect the .LOG1 and .LOG2 files with each hive. KAPE's RegistryHives targets and Velociraptor's equivalents do this.
• Replay the logs before analysis. Registry Explorer prompts you when it loads a dirty hive; RECmd replays them automatically unless told not to; regipy-process-transaction-logs produces a clean copy.
• RegRipper does not replay logs itself. Feed it a hive that has already been cleaned.
• Keep the original dirty hive and logs as evidence, and work on the replayed copy.

Collection of locked hives on a live system is covered in acquisition and triage with KAPE and Velociraptor.

CurrentControlSet versus ControlSet00x

HKLM\SYSTEM\CurrentControlSet does not exist in the SYSTEM file. At boot, Windows picks one of the stored control sets (ControlSet001, occasionally ControlSet002) and links CurrentControlSet to it. Offline, you must work out which one was live:

SYSTEM\Select
  Current        = 1   -> ControlSet001 was in use
  Default        = 1
  LastKnownGood  = 1   (may be absent on recent builds)
  Failed         = 0

Most modern systems only have ControlSet001, but do not assume it. Tools such as RECmd batch files and RegRipper plugins resolve Select\Current for you; when you browse manually, check it first. A second control set that differs from the current one can itself be interesting, for example a service that exists in one but not the other.

LastWrite times and their limits

Every key has a LastWrite time, a FILETIME in UTC updated whenever a value in the key changes or a subkey is added or removed. It is useful, and routinely over-interpreted:

• Keys only. Values have no timestamp. If a key has ten values, the LastWrite tells you that something in the key changed at that time, not which value.
• Not recursive. Changing a value in a subkey does not update the parent's LastWrite.
• Windows rewrites keys itself. Updates, servicing, profile loads and maintenance tasks can touch many keys at once. A cluster of identical LastWrite times across unrelated keys usually points to the OS, not to the user.
• Cleanup leaves a trace. When an attacker or a cleaner deletes an MRU value, the key's LastWrite records the deletion time.
• Embedded timestamps are separate. Artifacts such as UserAssist, BAM and network profiles store their own times inside value data. Each has its own format and may be local time rather than UTC; see UTC and local time.

The header of the hive file also has a timestamp, but it is not updated on Windows 8.1 and later, so do not rely on it.

Deleted keys and unallocated cells

Hives are made of cells. Deleting a key or value marks its cell as free but does not wipe it, so the content survives until the space is reused. Registry Explorer lists recovered entries under deleted or unassociated records; yarp and some RECmd options recover them too. Transaction logs and volume shadow copies may hold older versions of the same data.

This matters for anti-forensics: an attacker who deletes a Run value or a service key after use often leaves the data in a free cell, and the parent key's LastWrite marks when it happened.

RegBack: empty since Windows 10 1803

Older guides tell you to compare live hives with C:\Windows\System32\config\RegBack. Before Windows 10 version 1803, a scheduled task copied the system hives there periodically. Since 1803 Microsoft disabled that backup by default: the files are still present but 0 bytes. Administrators can re-enable it with the EnablePeriodicBackup DWORD under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager; Microsoft documents this on learn.microsoft.com. Check the file sizes before you plan on RegBack, and turn to shadow copies or Windows.old for historical hives.

Keys that answer investigative questions

Paths below use ControlSet001; substitute the control set from Select\Current.

System profile

Two traps: ProductName still reads "Windows 10" on Windows 11, so use CurrentBuild (22000 and above is Windows 11); and InstallDate reflects the last feature upgrade on many systems, not the original installation. Network profiles store their dates as local-time SYSTEMTIME structures, not UTC. MountedDevices is the starting point for USB and volume history, together with USBSTOR and friends. Account details are covered in SAM and user accounts.

User activity (NTUSER.DAT and UsrClass.dat)

BAM lives in SYSTEM but is keyed by SID, so it bridges system and user evidence. The user-activity artifacts are covered in depth in ShellBags, LNK files and Jump Lists, and execution artifacts such as ShimCache in evidence of execution. Persistence locations (Run keys, services, Winlogon, IFEO) have their own guide: hunting Windows persistence.

Tools

Registry Explorer

Eric Zimmerman's GUI viewer loads multiple hives, replays transaction logs, recovers deleted keys and values, and ships with bookmarks and plugins that decode common artifacts (UserAssist, ShellBags summaries, BAM, and more). Use it to explore, validate a finding, or understand an unfamiliar key.

RECmd with batch files

RECmd is the command-line counterpart. Its strength is batch files (.reb): YAML lists of keys and values to extract, with plugins for decoding. The distribution includes BatchExamples, such as Kroll_Batch.reb and DFIRBatch.reb, which cover the keys in this article and many more, producing a single CSV per run that loads straight into Timeline Explorer.

# Process every hive under a triage folder (recursively) with a curated batch file
RECmd.exe -d E:\case\HOST01\tout\C --bn E:\tools\RECmd\BatchExamples\Kroll_Batch.reb --csv E:\case\HOST01\registry

# Query a single hive for a key, useful for quick checks
RECmd.exe -f E:\case\HOST01\SYSTEM --kn "ControlSet001\Control\TimeZoneInformation"

RECmd replays transaction logs when it finds dirty hives and the logs are present. The !EZParser KAPE module runs RECmd with a batch file for you.

RegRipper

Harlan Carvey's RegRipper runs Perl plugins against a hive and prints human-readable reports, often with analyst notes about what an artifact means. It is excellent for a quick narrative view and for artifacts other tools do not decode.

# Run a single plugin against a user hive
rip.exe -r E:\case\HOST01\users\jdoe\NTUSER.DAT -p userassist

# RegRipper 3.x: run all plugins for the detected hive type
rip.exe -r E:\case\HOST01\SOFTWARE -a > E:\case\HOST01\software.txt

Remember that RegRipper does not replay transaction logs: clean dirty hives first. Plugin coverage and options differ between versions, so check rip.exe -l for what your copy supports.

Comparison

For timeline work, Plaso's winreg parsers add key LastWrite times and decoded artifacts to a super timeline.

Common mistakes

• Parsing a dirty hive without its logs: the most recent activity, usually the most relevant, is missing.
• Reading CurrentControlSet paths literally in an offline hive, or assuming ControlSet001 without checking Select.
• Treating LastWrite as the time a value was set: it is the time the key last changed, for any reason.
• Forgetting UsrClass.dat: ShellBags and per-user COM hijacks live there, not in NTUSER.DAT.
• Attributing a user hive to the wrong account: map each profile folder to its SID through ProfileList; renamed accounts keep their old folder name.
• Mixing time zones: some embedded timestamps are local time. Record the system's time zone from the SYSTEM hive before building a timeline.
• Counting on RegBack on Windows 10 1803 and later.

Practical workflow

1. Collect every hive with its .LOG1/.LOG2: SAM, SECURITY, SOFTWARE, SYSTEM, DEFAULT, Amcache, and NTUSER.DAT plus UsrClass.dat for each profile. Add hives from shadow copies if available.
2. Hash and preserve the originals; work on copies.
3. Replay transaction logs (Registry Explorer, RECmd or regipy) and note which hives were dirty.
4. Profile the system: Select\Current, computer name, time zone, OS build, last shutdown, network interfaces. Write the time zone at the top of your notes.
5. Map users: SAM accounts and ProfileList SIDs to profile paths and hives.
6. Bulk extract with RECmd and a batch file such as Kroll_Batch.reb; load the CSV into Timeline Explorer and filter to the incident window.
7. Pivot on findings: persistence keys, execution (BAM, ShimCache, UserAssist), user activity (RunMRU, TypedPaths, RecentDocs, ShellBags), devices (MountedDevices, USBSTOR).
8. Validate each key finding in Registry Explorer, check the raw value data, and look for deleted keys nearby.
9. Correlate with the file system and event logs: a registry entry is strongest when a Prefetch file, an event log record or an $MFT entry agrees with it.
10. Document each finding with hive, full key path, value, data and the timestamp source (LastWrite or embedded).

If you are new to the field, start with Getting started with Windows forensics and come back here once you have a triage collection to work on.