Windows Registry Forensics for DFIR

Windows Registry Forensics for DFIR - article cover image Tools & Defense
2026.07.13
Time it takes to read this article 5 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

The Windows Registry is a hierarchical database that stores nearly everything about a system’s configuration and, critically for investigators, a surprising amount of user and program *activity* history that was never intended as an audit trail. Which programs a user ran and when, which files and folders they browsed, which USB devices were plugged in, and which services and scheduled tasks were installed for persistence are all recoverable from a handful of registry hives — often long after the activity itself, and sometimes even after the responsible malware has been deleted.

Registry forensics is foundational to nearly every Windows DFIR engagement because the registry is where the bulk of documented persistence techniques (MITRE ATT&CK’s entire Boot or Logon Autostart Execution tactic, T1547) actually live. Knowing the handful of key paths that matter, and the tools to parse them at scale, turns a multi-hive, multi-gigabyte artifact set into an actionable timeline of what an attacker configured to survive reboot and what a user actually did.

Attack Prerequisites

This is an analysis technique; using it productively requires:

  • Access to the relevant hive files — SYSTEM, SOFTWARE, SAM, SECURITY (in C:\Windows\System32\config), and per-user NTUSER.DAT and UsrClass.dat (under each user’s profile and AppData\Local\Microsoft\Windows\), collected live or from an offline image.
  • Parsing tooling — RegRipper for plugin-based automated extraction, Eric Zimmerman’s Registry Explorer/RECmd for interactive and batch parsing, or plaso for timeline integration.
  • Awareness that hives are locked while Windows is running, requiring either an offline image, Volume Shadow Copies, or a live-response tool that can read locked files (e.g. via raw volume access).
  • Knowledge of transaction logs and backups — .LOG1/.LOG2 files next to each hive, and C:\Windows\System32\config\RegBack\, which can hold recoverable history the live hive no longer shows.

How It Works

Each hive is a B-tree-like binary structure of nested keys (folders) and values (typed data leaves), each key carrying a single LastWriteTime — the timestamp of the most recent modification to *any* value under that key, which is the closest the registry gets to a native audit timestamp. Because only the key, not each individual value, is timestamped, an investigator often has to infer which specific value change caused a given LastWriteTime update, which is one reason corroborating with other artifacts (event logs, MFT) matters.

Registry evidence falls into two broad categories that DFIR analysts handle differently: persistence artifacts (Run keys, services, scheduled task registrations, Image File Execution Options) that reveal how an attacker maintains access, and user-activity artifacts (UserAssist, ShellBags, RecentDocs, MRU lists) that reveal what a human operator — legitimate user or attacker with interactive access — actually did. UserAssist is a good example of the latter’s quirks: Windows stores the executed program’s path ROT13-encoded under a GUID-named subkey, purely as a historical obfuscation left over from early Windows XP-era code, and every modern parser transparently decodes it.

Windows also keeps hive-level transactional durability via .LOG1/.LOG2 files, which record recent uncommitted or recently-committed changes and can, when replayed by tools like Registry Explorer, recover registry state or deleted key/value history slightly ahead of or different from what the primary hive file alone shows — a detail most registry viewers that only open the primary hive file will silently miss.

Practical Example / Configuration

A registry key path table covering the persistence and user-activity locations examined in nearly every Windows DFIR case:

  • Run / RunOnce — HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and the matching HKCU path — the single most common autostart persistence location.
  • Services — HKLM\SYSTEM\CurrentControlSet\Services\<name>, ImagePath value — service-based persistence and driver loading.
  • Image File Execution Options — HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<binary>.exe, Debugger value — a classic ‘debugger hijack’ persistence/privesc technique (T1546.012).
  • Winlogon — HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, Shell and Userinit values — logon-triggered persistence.
  • UserAssist — HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{GUID}\Count — ROT13-encoded GUI program execution history with run count and last-run time.
  • ShimCache / AppCompatCache — HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache — see execution-artifact analysis.
  • ShellBags — NTUSER.DAT/UsrClass.dat, ...\Shell\BagMRU and ...\Shell\Bags — folder-browsing history, including folders that no longer exist or were on removable media.
  • RecentDocs — HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs — recently opened files by extension.
  • ComDlg32 MRU — HKCU\...\Explorer\ComDlg32\OpenSavePidlMRU — files recently opened/saved via common dialogs.
  • NetworkList Profiles — HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles — networks the host has joined, useful for placing a laptop at a specific location/time.
# Batch-parse key persistence and user-activity locations with RECmd
RECmd.exe --bn BatchExamples\RegistryPersistence.reb --f C:\cases\SYSTEM --csv C:\out
RECmd.exe --bn BatchExamples\RegistryPersistence.reb --f C:\cases\SOFTWARE --csv C:\out
RECmd.exe --bn BatchExamples\RegistryPersistence.reb --f C:\cases\NTUSER.DAT --csv C:\out
TEXT

Walkthrough / Exploitation

A typical persistence-hunting pass loads the SYSTEM and SOFTWARE hives and pulls every autostart location at once with RegRipper’s autoruns-style plugins, then narrows to a specific user’s activity:

# RegRipper -- run the full autostart-focused plugin set against SOFTWARE/SYSTEM
rip.exe -r C:\cases\SOFTWARE -p run > run_software.txt
rip.exe -r C:\cases\SYSTEM -p services > services.txt

# Registry Explorer / RECmd -- pull UserAssist for a specific user profile
RECmd.exe -f C:\cases\Users\jdoe\NTUSER.DAT --kn "UserAssist" --recover true --csv C:\out
TEXT

For a suspicious service, correlate the ImagePath under CurrentControlSet\Services with the corresponding Security 4697/7045 install event and the binary’s own MFT timestamps to build a full picture: when it was installed, what it points to, and whether that matches the claimed install time.

Note: Do not overlook RegBack (C:\Windows\System32\config\RegBack\) and Volume Shadow Copies — both can hold an earlier snapshot of a hive that shows a persistence key an attacker has since removed to cover their tracks. Comparing the live hive against a shadow-copy hive is a standard technique for spotting ‘clean-up’ activity.

Opsec / Analyst tip: CurrentControlSet is a symlink-like pointer, not a real key — always confirm whether you are looking at ControlSet001 or ControlSet002 when parsing an offline SYSTEM hive, since CurrentControlSet does not exist as a physical key outside a live, mounted registry.

Detection and Defense

Registry evidence review pairs naturally with proactive monitoring of the same locations:

  • Monitor Run-key and service-registration changes via Sysmon Event ID 13 (RegistryEvent — value set) and 12/14 (key create/delete/rename) scoped to the persistence paths above.
  • Baseline autostart locations across the fleet (Autoruns, or a custom osquery/EDR query) so new, unexpected entries stand out quickly.
  • Preserve RegBack and Volume Shadow Copies during acquisition — they are frequently the only surviving copy of a since-removed persistence key.
  • Alert on writes to Image File Execution Options Debugger values, a technique with almost no legitimate day-to-day use.
  • Retain transaction logs (.LOG1/.LOG2) alongside primary hives in every collection — they can recover recently deleted registry history.

Real-World Impact

Registry-based persistence (Run keys, services, IFEO Debugger hijacking, Winlogon Shell/Userinit abuse) is among the most common persistence mechanisms observed across commodity malware, ransomware precursors, and targeted intrusions, precisely because it is simple, well-documented, and reliably survives reboot. UserAssist and ShellBags evidence, meanwhile, routinely resolve insider-threat and post-compromise ‘what did the attacker actually browse/run interactively’ questions that no log source would otherwise answer.

Conclusion

The registry’s dual role — system configuration store and inadvertent activity log — makes it one of the highest-value artifact sets in Windows forensics. A short, well-understood list of key paths, combined with tooling that can parse live hives, offline images, transaction logs, and shadow copies alike, consistently surfaces both how an attacker persisted and what happened on the keyboard.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL