Registry Parser
← All articles

What is the Windows Registry? A forensic investigator's primer

7 min read

If you have spent any time on a Windows machine you have probably heard of the registry, usually in the context of someone telling you not to touch it. For an investigator, that warning is exactly backwards. The registry is one of the first places you should look. So let's answer the question plainly: what is the Windows Registry, and why does it end up at the center of so many forensic investigations?

A hierarchical configuration database

The Windows Registry is a database. Not a folder, not a file in the usual sense, but a structured store of settings that Windows and the programs running on it read from and write to constantly. Every time you change a desktop wallpaper, install an application, plug in a USB drive, or log in, something gets recorded in the registry. Windows itself cannot boot without it.

The reason it matters to a forensic investigator is a side effect of that design. The registry was built to hold configuration, but configuration is just a record of decisions and events, and those records carry timestamps. The operating system is, almost by accident, keeping a running log of what happened on the machine. Your job is to read it.

Structurally the registry looks like a filesystem. It is a tree. The folders are called keys, and the things inside them are called values. That is the whole model, and once you have it, everything else is detail.

Keys versus values

A key is a container. It can hold other keys (subkeys) and it can hold values. Think of it as a directory. A full path to a key looks like this:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Each backslash-separated segment is a key, nested inside the one before it.

A value is the actual data. A value has a name, a type, and the data itself. The type tells you how to read the bytes: REG_SZ is a text string, REG_DWORD is a 32-bit number, REG_BINARY is raw bytes, and there are a handful of others. A key called Run might contain a value named OneDrive of type REG_SZ whose data is the path to the OneDrive executable. The key is the folder; the value is the file inside it.

One detail that trips up newcomers: every key has one unnamed value, the "(Default)" value. You will see it in any registry viewer. Most of the time it is empty.

The five root keys

At the very top of the tree sit the root keys, also called hives in casual usage (the word "hive" means something more specific on disk, which we'll get to). There are five, and each is a window onto a different slice of the system. Here they are in one line each:

  • HKEY_LOCAL_MACHINE (HKLM) — machine-wide settings that apply to every user: installed software, services, hardware, boot configuration.
  • HKEY_CURRENT_USER (HKCU) — settings for the user who is currently logged in: their preferences, their recently opened files, their environment.
  • HKEY_USERS (HKU) — the settings for all loaded user profiles; HKCU is simply a shortcut to the current user's subtree inside HKU.
  • HKEY_CLASSES_ROOT (HKCR) — file associations and COM registrations; a merged view built from machine-wide and per-user class data.
  • HKEY_CURRENT_CONFIG (HKCC) — the current hardware profile; a small, mostly legacy view derived from HKLM.

For an investigator, the two that carry the most weight are HKLM (what the machine is configured to do) and HKCU/HKU (what each person did). The other three are derived or merged views — useful, but not where the primary evidence lives.

Where it actually lives: hive files

Here is the part that matters most for forensics, because it is where the live system and the disk image diverge. When Windows is running, the registry presents itself as that single clean tree under five root keys. But on disk it is not one file. It is several, and they are called hive files.

A hive is a binary file in the regf format. The root keys you see in a running system are assembled from these files at boot and login. The ones you will collect from a disk image are:

  • SYSTEM — services, drivers, the control sets, and a great deal of device history. Found under C:\Windows\System32\config\.
  • SOFTWARE — installed applications and machine-wide software configuration. Same directory.
  • SAM — local user accounts and their group memberships. Same directory.
  • SECURITY — local security policy and secrets. Same directory.
  • NTUSER.DAT — the per-user hive that backs HKCU. One per profile, at the root of each user's folder, e.g. C:\Users\Alice\NTUSER.DAT.
  • USRCLASS.DAT — per-user class registrations and, importantly, shellbags. Found at C:\Users\Alice\AppData\Local\Microsoft\Windows\.

Knowing which file holds what you are after is half the battle in acquisition, and it is easy to grab the wrong one or miss a per-user hive entirely. We keep a registry forensics cheat sheet for exactly this, and a companion piece on which registry hive to grab for a given question. If you want the byte-level picture of how these files are structured, the Windows registry internals post goes deeper.

One practical warning that follows from the file-based design: a hive copied off a live or imaged system is often not the whole story on its own. Each hive has transaction logs (.LOG1, .LOG2) that may contain changes not yet written into the hive itself. Reading the hive without replaying those logs gives you a stale view. Any serious tool handles this for you, but it is worth knowing the data is split.

Why the registry matters in DFIR

Now the real question. You can read configuration anywhere — why do investigators care so much about this particular database? Because the registry is not just configuration. It is a record of activity, and it records things the user never intended to leave behind. A few of the threads you can pull:

Execution. Windows tracks programs that have run in several registry-backed artifacts — AmCache, the UserAssist counters under HKCU, the BAM/DAM entries under SYSTEM. These can tell you that a specific executable ran, sometimes with a timestamp and a run count, even after the file itself is gone.

Persistence. Malware needs to survive a reboot, and the registry is the classic place to arrange that. The various Run and RunOnce keys, service definitions under SYSTEM, scheduled-task references, and a dozen lesser-known autostart locations are all in the registry. When you are hunting for how an intruder kept their foothold, you are reading registry keys.

Device history. Plug in a USB stick and Windows remembers it — vendor, product, serial number, and the times it was first and last connected, recorded across SYSTEM and SOFTWARE. This is how data-exfiltration and "was this drive ever here" questions get answered.

User activity. Recently opened documents, typed paths in Explorer, search terms, the folders a user browsed (shellbags), the networks a laptop joined. The registry holds a surprisingly intimate diary of what someone did and when.

Tying it together is the LastWrite timestamp. Every key carries the time it was last modified, which gives many of these artifacts a place on a timeline. Used carefully — it is a per-key, not per-value, timestamp — it turns the registry from a pile of settings into a sequence of events.

That is the forensic value in one sentence: the registry is a timestamped, system-maintained record of execution, persistence, device history, and user activity, written continuously and largely without the user's awareness. Few other artifacts on a Windows host pack that much story into so little space.

Where to go from here

If you understand keys, values, root keys, and hive files, you have the mental model you need to start reading a registry like an investigator rather than a tourist. The next step is to look at a real hive. You can analyze a hive in your browser with no install and nothing uploaded to a server — point it at an NTUSER.DAT or a SYSTEM hive and walk the tree yourself.

The registry rewards curiosity. Open one, find the Run key, find the USB history, look at the LastWrite times. Once you have seen the evidence sitting there in plain sight, the warning to never touch it starts to sound less like caution and more like an invitation.