NTUSER.DAT vs SOFTWARE vs SYSTEM: which hive answers which question

The single most common mistake in registry triage is grabbing the wrong hive. Not failing to grab any hive at all. Grabbing one and assuming it will answer a question that lives in a different file. The map below is the one I wish someone had pinned next to my desk in my first year.

The five hives that matter

There are more than five hives on a Windows system, but five carry the weight of an actual investigation:

C:\Windows\System32\config\SYSTEM: services, drivers, the live ControlSet, hardware configuration, Shimcache, the network list service identifiers.
C:\Windows\System32\config\SOFTWARE: installed applications, machine-wide Run keys, Winlogon, AppCompatFlags, the file association map.
C:\Windows\System32\config\SECURITY: local security policy, audit configuration, cached domain credentials.
C:\Windows\System32\config\SAM: local user accounts, group memberships, password hashes (need SYSTEM to decrypt).
C:\Users\<user>\NTUSER.DAT: per-user settings, UserAssist, RecentDocs, per-user Run keys, TypedPaths, RunMRU.

Plus one more that often gets forgotten:

C:\Users\<user>\AppData\Local\Microsoft\Windows\UsrClass.dat: per-user class registrations, including ShellBags under modern Windows.

Each of these has a transaction log pair (.LOG1, .LOG2). Pull them. If you forget, you are choosing to ignore in-flight writes.

SYSTEM: the machine's nervous system

SYSTEM is where you go when the question involves services, drivers, devices, the boot configuration, or the local timeline. The active ControlSet is referenced through Select\Current (a DWORD pointing at ControlSet001, ControlSet002, or rarely a higher number).

What lives here:

ControlSet001\Services\: every service and driver, with ImagePath, ServiceDll, Start, and the security descriptor. Persistence often hides here as a fake service.
ControlSet001\Control\Session Manager\AppCompatCache\AppCompatCache: the Shimcache. Lists executables that have been on the system, with their MFT-derived sizes and a "last update" flag. Crucial for finding binaries that have since been deleted.
ControlSet001\Control\TimeZoneInformation: the timezone the host is configured for. You will need this to interpret every other timestamp on the system. Get this wrong and you will misread evidence by hours.
ControlSet001\Control\ComputerName\ComputerName\ComputerName: the hostname. Less trivial than it sounds when you are working from acquired hives and need to know which host you are looking at.
ControlSet001\Services\Tcpip\Parameters\Interfaces\<GUID>: historical IP configurations.
MountedDevices: drive-letter assignments and their volume identifiers, useful for correlating with USB device history.
Setup\: initial install metadata, including the original install date and the source media identifier.

If you only had time to grab one hive on a service-persistence case, SYSTEM is it.

SOFTWARE: the machine's application world

SOFTWARE is the big one for malware persistence and application footprints. It is also the largest of the standard hives by a wide margin, which means tools without good indexing will take longer here than anywhere else.

Where to look:

Microsoft\Windows\CurrentVersion\Run and RunOnce: machine-wide autoruns. The first place to look on any compromised host.
Microsoft\Windows NT\CurrentVersion\Winlogon: the Userinit, Shell, Notify, and LegalNoticeCaption values. Modified Userinit is an old technique that still works.
Microsoft\Windows NT\CurrentVersion\Image File Execution Options\: the IFEO debugger key, abused for accessibility-feature hijacks.
Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>: every profile that has ever logged in to the host, with the SID, the username path, and the last-load timestamp. The fastest way to enumerate users from offline hives.
Microsoft\Windows\CurrentVersion\Uninstall\: installed software, with display names, install dates, and (sometimes) install paths. Useful for distinguishing legitimate applications from things that pretend to be installed software.
Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\<GUID>: every network the host has connected to, with the SSID, the gateway MAC, and the last-connect time. This is one of the best location-of-host artifacts on a roaming endpoint.
Microsoft\Windows\CurrentVersion\Explorer\FileExts\<.ext>: file extension associations as the user configured them. Useful for catching extension hijacks.

SOFTWARE is also where AmCache lives, in a separate hive at C:\Windows\AppCompat\Programs\Amcache.hve. Some people forget that AmCache is a hive at all. It is. Treat it the same way you treat any other regf file.

NTUSER.DAT: per-user, per-investigation

The most common mistake I see is reaching for HKLM\Software\Microsoft\Windows\CurrentVersion\Run (SOFTWARE hive) and stopping there. The per-user equivalent is at HKCU\Software\Microsoft\Windows\CurrentVersion\Run, which lives in NTUSER.DAT for the user in question. Persistence may be in either or both. On user-context malware, it is almost always in the user's NTUSER.

What lives in NTUSER:

Software\Microsoft\Windows\CurrentVersion\Run and RunOnce: per-user autoruns.
Software\Microsoft\Windows NT\CurrentVersion\Windows\Load and Run: per-user load values. Rare in legitimate use.
Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\: the ROT13-encoded program launch history. Best per-user execution artifact on the system.
Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs: files the user opened, by extension.
Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths: every path typed into Explorer.
Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU: every Win+R command. Goldmine.
Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU: file picker history across native apps.
Software\Microsoft\Office\<version>\<app>\User MRU\: Office's recent files, per app. The version subkeys keep history through Office upgrades.
Software\Microsoft\Terminal Server Client\Default: RDP target host history.

If the investigation is "what did this user do", you live in NTUSER. If "what was running on this host", SYSTEM and SOFTWARE.

The catch: NTUSER is loaded into the registry under HKEY_USERS\<SID> only while the user is logged in. If the user is not logged in, the hive is on disk but the running kernel has no view of it. Tools that read from the live registry rather than the file will miss everything for non-logged-in users. This is the most common reason for an investigation to silently miss persistence.

UsrClass.dat: the second per-user hive

UsrClass.dat is the per-user counterpart to the machine's class hive. It lives next to NTUSER but you have to know to grab it separately. Most acquisition scripts that say "grab NTUSER" do not grab UsrClass unless explicitly told.

What lives here:

Local Settings\Software\Microsoft\Windows\Shell\BagMRU and Bags: modern ShellBags. On Windows 7 and later this is where the meaningful Bag data lives, not in NTUSER. Tools that look only in NTUSER will give you a fragmentary view.
Local Settings\MuiCache: cached display names for executables the user has interacted with through Explorer.
Various app-specific per-user class registrations.

If ShellBags matter to your case, you need UsrClass. The investigation will fall apart without it.

SAM and SECURITY: the credentials hives

SAM holds local account information. SECURITY holds local policy and cached domain credentials. Both are encrypted with keys derived from SYSTEM's LSA\ subtree, which means decryption requires SYSTEM. Always acquire all three together. Splitting them is a workflow trap that catches new investigators.

Useful keys:

SAM\Domains\Account\Users\: local accounts, with last-logon, password-change timestamps, and account flags.
SAM\Domains\Account\Aliases\Members\: local group memberships.
SECURITY\Cache\: cached domain credentials (MSCASH/DCC2).
SECURITY\Policy\Secrets\: LSA secrets, including service account passwords stored in cleartext.

Common confusions

Three of these come up on almost every case:

The Run keys exist in both HKLM and HKCU. When you triage Run, you triage both. SOFTWARE has the machine-wide value; the per-user NTUSER.DAT files have the per-user values. Persistence may live in either, sometimes both, sometimes only the latter on a user-context infection that never got admin.

ShellBags moved. On Windows 7+ the meaningful bag data is in UsrClass.dat. Tools written against XP-era hives look in NTUSER and miss everything.

ControlSet versus CurrentControlSet. HKLM\SYSTEM\CurrentControlSet\ is a symlink. The actual data is in ControlSet001 (usually). When you parse the SYSTEM hive offline, you have to read Select\Current to know which ControlSet is live, then read that one. Reading CurrentControlSet directly will fail because the symlink does not exist on disk.

A triage order that works

Acquire SYSTEM, SOFTWARE, SECURITY, SAM, every NTUSER.DAT, every UsrClass.dat, plus all their .LOG1/.LOG2.
Resolve the timezone (SYSTEM Control\TimeZoneInformation) before reading any timestamp.
Enumerate users (SOFTWARE Microsoft\Windows NT\CurrentVersion\ProfileList) so you know which NTUSER files map to which accounts.
Triage machine-wide persistence in SOFTWARE and SYSTEM. Cross-correlate with Prefetch, AmCache, and Shimcache.
Triage per-user activity in each NTUSER. Look at UserAssist, RecentDocs, TypedPaths, RunMRU. Pivot to LNK files and jump lists for file access.
ShellBags from UsrClass for navigation history.

Doing this in the wrong order works fine. Skipping any of the six bites you on the third call when the question comes up and you have to go back to the host.