Registry Parser
← All articles

What is NTUSER.DAT? The per-user Windows registry hive explained

7 min read

If you have ever browsed a Windows user profile and noticed a file called NTUSER.DAT that you could not open by double-clicking, you have found one of the most evidence-rich files on the entire system. NTUSER.DAT is the per-user Windows registry hive: a single binary file that holds one specific person's settings, preferences, and — crucially for anyone doing forensics — a long trail of what that person did on the machine. This post explains what the NTUSER.DAT file is in plain terms, then shows you what an analyst actually reads out of it.

What NTUSER.DAT is

The Windows registry is not one giant file. It is assembled at runtime from several files called hives, each one a self-contained binary tree of keys and values. Some hives are system-wide (SYSTEM, SOFTWARE, SAM, SECURITY). NTUSER.DAT is different: there is one NTUSER.DAT per user account, and it stores everything that is specific to that user rather than to the machine.

Think of it this way. The machine-wide hives describe the computer. NTUSER.DAT describes a person's experience of that computer — their desktop layout, their mapped drives, their recently opened documents, the programs they launched, the folders they typed into Explorer's address bar. When two people share a laptop, they each get their own NTUSER.DAT, and the two files can tell very different stories.

Where it lives

Every user profile has one, sitting at the root of the profile folder:

C:\Users\<name>\NTUSER.DAT

So for a user jdoe it is C:\Users\jdoe\NTUSER.DAT. The file is hidden and is a system file, so a default Explorer view will not show it. There is usually a ntuser.dat.LOG1 and ntuser.dat.LOG2 alongside it — transaction logs the registry uses to recover from a crash mid-write. You want those logs too; more on that below.

A second per-user hive, UsrClass.dat, lives under C:\Users\<name>\AppData\Local\Microsoft\Windows\ and holds the user's class registrations and shell artifacts (including some Shellbags). NTUSER.DAT is the primary one, but a thorough exam pulls both.

How it maps to HKEY_CURRENT_USER

Here is the connection that ties the file to what you see in regedit. When a user logs on, Windows loads that user's NTUSER.DAT and mounts it as HKEY_CURRENT_USER (HKCU). Everything under HKCU is, physically, the contents of that user's NTUSER.DAT file.

Behind the scenes, all loaded user hives are also mounted under HKEY_USERS, keyed by the user's SID — for example HKEY_USERS\S-1-5-21-...-1001. HKCU is simply a pointer to whichever one of those belongs to the currently logged-on user. So HKCU\Software and HKEY_USERS\<the-user-SID>\Software are the same data, and both are just the live view of that person's NTUSER.DAT.

This is why, in forensic write-ups, you will see paths written as HKCU\Software\Microsoft\.... That is shorthand. When you are working from a disk image with the user logged off, there is no HKCU — there is a file on disk called NTUSER.DAT, and you open it directly. The path is the same; only the framing changes.

Why it is locked on a live system

Try to copy NTUSER.DAT off a running machine while the user is logged on and Windows will refuse with a sharing violation. The file is held open and locked by the operating system the entire time the user is logged in, because the registry is being read from and written to constantly. You cannot simply grab it like an ordinary document.

This matters for two reasons. First, acquisition needs a method that works around the lock (covered next). Second, a live NTUSER.DAT is a moving target: timestamps and counters change as the user keeps working. If you read a value at 14:00 and the user acts at 14:05, the live data may already have moved on. Note the time you acquired the hive and treat it as a fixed reference state.

What is inside that matters forensically

This is where NTUSER.DAT earns its reputation. Because it belongs to exactly one user, anything you find in it is attributable — you are not guessing who did something; the hive's owner did. A few of the keys that carry the most weight:

  • UserAssist — a per-user record of which programs the user launched through the shell (Explorer, Start menu, taskbar), with run counts and last-run times. Encoded in ROT13, which trips up first-timers. See UserAssist forensics: decoding the ROT13 program-launch history.
  • RecentDocs — the files the user recently opened, grouped by extension, with a most-recently-used ordering. A direct window into what documents passed through this account. See RecentDocs and the RegRipper plugin.
  • Run / RunOnce keys — HKCU\Software\Microsoft\Windows\CurrentVersion\Run lists programs set to start automatically for this user. A classic persistence location: malware that wants to survive a reboot frequently lands here.
  • TypedPaths — HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths records paths the user typed into Explorer's address bar, including UNC paths to network shares. Evidence of deliberate navigation, not just clicking.
  • MountPoints2 — HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 tracks drives and volumes the user mounted, including USB devices and network shares, keyed by volume GUID. A starting point for "what removable media touched this account".

That is a short list. NTUSER.DAT also holds Shellbags (folder-browsing history), the WordWheelQuery (Explorer search terms), open/save dialog MRUs, RDP connection history, and more. For the full map of where these live, see the Windows registry forensics cheat sheet.

The common thread: NTUSER.DAT does not just say what happened on the machine — it says what this specific user did. That attribution is the reason analysts reach for it early.

How analysts acquire it

Because the file is locked while the user is logged on, you cannot drag it off a live box. The standard approaches:

  • From a disk image. The cleanest method. Image the disk, then extract C:\Users\<name>\NTUSER.DAT (plus its .LOG1/.LOG2 files) from the mounted image. No lock, because nothing is running.
  • From a Volume Shadow Copy (VSS). Windows keeps point-in-time snapshots. Each snapshot contains its own copy of NTUSER.DAT, unlocked, letting you reconstruct how values changed over days or weeks. This is how you turn "last run Tuesday" into "used daily for two weeks". For a live triage box, mounting a shadow copy is also a way to grab the otherwise-locked file.
  • Offline, with the user logged off. If the account is not logged on, its NTUSER.DAT is not loaded and not locked, so it can be copied normally. The same is true once you have powered the machine down and are working from the disk.

Whichever route you take, grab the transaction logs (.LOG1, .LOG2) alongside the hive. A hive captured mid-transaction can be "dirty", and the logs let a proper parser replay pending writes so you read the correct, consistent state rather than stale values.

Never delete it

This should be obvious but it is worth stating plainly: do not delete NTUSER.DAT. It is not a temporary file, a cache, or junk that a cleanup tool should remove. Deleting a user's NTUSER.DAT corrupts their profile — at next logon Windows will fail to load the profile and may silently log them into a fresh temporary profile, stranding their settings and data. On an evidence machine, deleting or modifying it destroys exactly the artifact you are trying to preserve. Work on copies, always, and leave the original in place.

Open one and look

The fastest way to understand NTUSER.DAT is to read one. You do not need to install RegRipper or Eric Zimmerman's tools to start — you can open and read an NTUSER.DAT file online and analyze it in your browser, with nothing uploaded to a server. Drop in a hive from a test machine or an image, navigate to Software\Microsoft\Windows\CurrentVersion\Explorer, and watch the user's RecentDocs, TypedPaths, and UserAssist come into view. Once you have seen the keys in context, the cheat sheet and the per-artifact deep dives will make a great deal more sense.