H3AD-REF / REFERENCES / REGISTRY KEY QUICK REFERENCE
The Registry Remembers
Even What You Deleted.
Seventeen keys that carry most of a Windows DFIR case: where malware persists, what ran, what a user touched, which devices connected, and where creds can leak. Static lookup data, no live hive parsing, just the paths worth memorizing before you open a copy of NTUSER.DAT at 2 AM. For the full 134-artifact catalog with ATT&CK mapping across registry, execution, browser, and network evidence, see ARTIFEKTX.
Persistence
Where a foothold gets rebuilt after every reboot. Eight keys, from the one everyone checks first to the ones that only show up once you've been burned by missing them.
| Registry Key Path | What It Shows | Why It Matters For DFIR |
|---|---|---|
| HKLM/HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run ...\RunOnce |
Programs launched automatically at logon or startup, per machine or per user | The single most-checked persistence location in any triage. RunOnce entries delete themselves after firing once, so a stale one is worth asking why it never ran. |
| HKLM\SYSTEM\CurrentControlSet\Services | Every installed Windows service, its binary path, and its start type | A new service you don't recognize, especially one pointing at a binary in a temp folder or user profile, is a classic persistence mechanism. Cross-check ImagePath against known-good software. |
| HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon | The Userinit and Shell values that fire at every interactive logon | Startup process hijacking. Malware rarely replaces these values outright since that breaks the desktop; instead it appends itself after a comma, so a legitimate value with an extra binary tacked on is the tell. |
| HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options | Per-binary debugger hooks that Windows honors at launch | Debugger-hijack persistence. A "Debugger" value under a subkey named for a legitimate binary, like sethc.exe or utilman.exe, silently redirects execution to the attacker's binary instead. |
| HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs | DLLs forced to load into any process that loads user32.dll | A broad DLL injection technique. Since almost every GUI process loads user32.dll, a DLL listed here rides into nearly the whole desktop session unnoticed. |
| HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors | Print monitor DLLs loaded by the print spooler service | Print-spooler-based persistence. A malicious monitor DLL added here loads with spoolsv.exe, a process most defenders never think to question. |
| HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages ...\Security Packages |
DLLs registered as LSA notification or security packages | LSA credential-provider hijacking. A rogue entry here loads inside lsass.exe itself, giving both persistence and a front-row seat to every credential that authenticates on the box. |
| HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache | A cached record of every scheduled task the host has known about | Useful even after the task itself is deleted from Task Scheduler. The cache entry can outlive the task, giving you a name, path, and trigger to work backward from. |
| HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom | Custom Shim Database (.sdb) entries applied to specific executables | Application shimming (T1546.011). A malicious shim can redirect or inject code into a legitimate binary's execution path without touching the binary itself, and most defenders never think to check the compatibility layer. |
Defense Evasion
One key, and it doesn't hide a foothold, it blinds the thing that was supposed to find one.
| Registry Key Path | What It Shows | Why It Matters For DFIR |
|---|---|---|
| HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths ...\Processes / ...\Extensions |
Paths, processes, and file extensions Windows Defender is told to skip | Defense evasion (T1562.001). A staging folder or a renamed binary added here runs invisibly to the built-in AV. Any exclusion the deployed software baseline doesn't account for is worth a direct answer as to why it exists. |
Execution Evidence
Proof something ran, or at least existed on disk. None of these three agree perfectly on timestamps, which is exactly why you check more than one.
| Registry Key Path | What It Shows | Why It Matters For DFIR |
|---|---|---|
| HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache | Shimcache: a record that a binary existed and, in most cases, was executed | Good for proving presence on disk at some point, weak for pinning down when. The timestamp it carries is unreliable enough that you should never build a timeline on it alone. |
| HKLM\SYSTEM\CurrentControlSet\Services\bam\State\UserSettings | BAM: per-user record of executed binaries with last-run timestamps | Generally more timestamp-reliable than Shimcache and tied to a specific user SID, which makes it useful for answering "who ran this" as well as "when." |
| NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist | GUI-launched program history per user, including run count and last-run time | Values are ROT13-encoded and easy to misread without decoding them first. Run count over time can show whether a tool was used once or became part of a routine. |
User & File Activity
What a user opened, typed, or browsed to. This is where you rebuild intent, not just execution.
| Registry Key Path | What It Shows | Why It Matters For DFIR |
|---|---|---|
| NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU | Commands typed into the Win+R Run dialog, most-recent-first | One of the first things any triage checks. A typed cmd, powershell, or full path to an unusual binary here is a direct record of user-driven execution, not something a GUI click could produce. |
| HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList | Every user profile ever created on the host, mapped from SID to username and profile path | Survives account deletion. When an account is removed but its profile directory or SID reference lingers here, this is how you recover who it was and when the profile was created. |
| NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs | Recently opened files, tracked per file type and overall | Evidence of file access that survives even if the file itself was deleted afterward. Useful for showing a user opened a specific attachment or document before an incident. |
| NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths | Paths manually typed into the Explorer address bar | Shows deliberate navigation, as opposed to clicking through folders. A typed UNC path to a rarely-used share is a different story than one reached by browsing. |
| ShellBags (USRCLASS.DAT\...\Shell\BagMRU, NTUSER.DAT equivalent) |
Folder-view metadata: size, position, and view settings for folders the user opened | Survives even after the folder itself is deleted, so it can prove a folder existed and was browsed long after the folder and its contents are gone. |
Device & Connection History
What plugged in, what mapped where, and what the box talked to over RDP or joined on the network.
| Registry Key Path | What It Shows | Why It Matters For DFIR |
|---|---|---|
| HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR | USB mass storage device history, including vendor, product, and device serial | The go-to key for proving a specific USB drive touched a host. Serial numbers here can be matched directly against a physical device in hand. |
| HKLM\SYSTEM\MountedDevices | A map of drive letters to the physical or USB volumes that have used them over time | Ties a drive letter seen in other artifacts, like RecentDocs or ShellBags, back to the actual device that letter pointed to at the time. |
| NTUSER.DAT\Software\Microsoft\Terminal Server Client\Servers | Outbound RDP connection history, an MRU list of servers the user connected to | Answers "where did this account RDP to" from the client side, which matters when the target's own logs have already rolled over or were never centrally collected. |
| HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles | Every network profile the host has joined, with first-connected and last-connected timestamps | Useful for placing a laptop on a specific network, wired or wireless, at a specific time, including networks outside the corporate environment. |
Credentials
One key, but a high-value one, and it takes SYSTEM to even open it.
| Registry Key Path | What It Shows | Why It Matters For DFIR |
|---|---|---|
| HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest | The UseLogonCredential value controlling whether WDigest caches reversible cleartext credentials in memory | Set to 1, this is the setting Mimikatz-style credential dumping (T1003.001) depends on to pull plaintext passwords straight out of LSASS. Disabled by default on current Windows, so finding it enabled is itself a signal someone changed it. |
| HKLM\SECURITY\Policy\Secrets | LSA secrets, encrypted blobs the OS uses to store sensitive values like service account passwords | Can contain cached service account credentials in recoverable form. Reading it requires SYSTEM-level access, which is itself worth noting if you find a tool that managed to dump it. |
TIMELINE PITFALL
LastWrite Time Is Per Key, Not Per Value
The most common way this data gets misread in a timeline
A registry key carries exactly one LastWrite timestamp, and that timestamp belongs to the key as a whole, not to any single value inside it. If three different values under
Run were added on three different days, the key's LastWrite only reflects the most recent of those writes. Everything else under that key looks like it changed at the same moment, because as far as the registry is concerned, it did. Treat a key's LastWrite as "something here changed on this date," never as proof of when a specific value was added, or you'll build a timeline around a coincidence.