Windows Registry Forensics

Introduction

30 Second Summary

Every program you launch, every USB drive you plug in, and every folder you browse leaves a trace in the Windows Registry. When a security team investigates a compromised machine, the Registry is often the first place they look to reconstruct what happened.

In this project, you will investigate your own Windows 11 machine using the same professional forensic tools and methodology that incident responders use on real engagements. You will acquire evidence, decode hidden artifacts, hunt for unauthorized persistence, and correlate findings across multiple data sources.

What You'll Build

You will treat your own system as if you were responding to a potential compromise, producing a documented forensic analysis that reveals exactly which programs ran, what survived reboots, and what the user accessed.

By the end of this project, you'll have:

• A professional DFIR forensic workstation with Registry Explorer and RECmd installed, ready to analyze any Windows system's registry hives offline.
• A decoded UserAssist analysis showing every GUI program a user launched, how many times it ran, and exactly when it last executed.
• A complete audit of persistence mechanisms (Run keys, services, startup entries) distinguishing legitimate programs from anything that should not survive a reboot.
• A reconstructed history of USB device connections, file access, and folder browsing pulled entirely from registry artifacts.
• Secret Mission: Batch-process all acquired hives with RECmd and build a cross-correlated timeline in Timeline Explorer, identifying coherent event chains across multiple data sources.

Are there any prerequisites?

This project requires a Windows 11 machine. You should be comfortable with the basics of the Windows Registry (keys, values, hives) and have basic PowerShell command-line comfort.

You should also understand what persistence means in a security context. No prior forensic tool experience is needed.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to investigate and why. You're going to treat your own Windows 11 machine as if it were a system handed to you during an incident response engagement.

Install .NET 9 and Eric Zimmerman's Tools

Registry Explorer and RECmd are the tools that DFIR professionals use to decode and analyze registry hives offline. They are free, actively maintained, and built specifically for forensic work.

Both tools require the .NET 9 Desktop Runtime to run. Without it installed, the applications will not launch. In this step, you will install that runtime and download the full Eric Zimmerman toolkit so your forensic workstation is ready.

In this step, get ready to:

• Install the .NET 9 Desktop Runtime.
• Download Eric Zimmerman's forensic tools using the official PowerShell script.
• Launch Registry Explorer and confirm it opens correctly.

Install the .NET 9 Desktop Runtime

Eric Zimmerman's GUI tools (Registry Explorer, Timeline Explorer) require the .NET 9 Desktop Runtime specifically. The regular .NET runtime is not enough.

• Open your browser and navigate to the .NET 9 download page: https://dotnet.microsoft.com/en-us/download/dotnet/9.0
• Scroll to the .NET Desktop Runtime 9.0.x section.
• Click the Windows x64 installer link to download it.
• Run the downloaded installer and accept the default options.
• Click Install when prompted, then click Close when the installation completes.

Now verify the installation succeeded by running a check command in PowerShell.

• Press the Windows key to open your search bar.
• Type PowerShell and select Run as administrator.
• Check your installed runtimes by running:

dotnet --list-runtimes

What do you expect to see in the output?

✔️ I see Microsoft.WindowsDesktop.App 9.0.x

Your .NET 9 Desktop Runtime is installed and ready. Move on to the next substep.

ⓧ I see runtimes listed but no WindowsDesktop.App 9.0.x

You may have installed the ASP.NET Core runtime or the base runtime instead of the Desktop runtime. Go back to the download page and look specifically for the section labeled .NET Desktop Runtime.

• Download and run the Windows x64 installer under the Desktop Runtime heading.
• After installation, run dotnet --list-runtimes again and confirm Microsoft.WindowsDesktop.App 9.0.x now appears.

ⓧ 'dotnet' is not recognized

The installer may not have added dotnet to your system PATH, or you opened PowerShell before the install finished.

• Close your PowerShell window completely.
• Reopen PowerShell as Administrator (search for PowerShell, right-click, Run as administrator).
• Run dotnet --list-runtimes again.
• If it still fails, re-run the Desktop Runtime installer from the download page and make sure it completes without errors.

Download Eric Zimmerman's tools using Get-ZimmermanTools

Eric Zimmerman distributes his forensic tools through a PowerShell script called Get-ZimmermanTools.ps1. This script downloads and extracts every tool in the suite to a folder you specify.

• In your Administrator PowerShell window, create a tools directory and download the script by running these commands:

New-Item -ItemType Directory -Path C:\ForensicTools -Force
Invoke-WebRequest -Uri "https://download.ericzimmermanstools.com/Get-ZimmermanTools.zip" -OutFile "C:\ForensicTools\Get-ZimmermanTools.zip"
Expand-Archive -Path "C:\ForensicTools\Get-ZimmermanTools.zip" -DestinationPath "C:\ForensicTools" -Force

What do these commands do?

• New-Item creates the C:\ForensicTools directory. The -Force flag means it will not error if the folder already exists.
• Invoke-WebRequest downloads the zip file containing the download script from Eric Zimmerman's distribution server.
• Expand-Archive unzips the downloaded file, placing Get-ZimmermanTools.ps1 inside C:\ForensicTools.

• Confirm the script was extracted by running:

dir C:\ForensicTools\Get-ZimmermanTools.ps1

You should see the Get-ZimmermanTools.ps1 file listed with its file size.

File not found?

If you see an error saying the path does not exist, check that the Invoke-WebRequest command completed without errors. A common cause is a network firewall blocking the download. Try re-running the download command.

Help me troubleshoot the Get-ZimmermanTools download

Now run the script to download all of Eric Zimmerman's tools. This will take a few minutes as it downloads approximately 200MB of forensic utilities.

• First, allow PowerShell to run downloaded scripts by running:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

Why change the execution policy?

Windows 11 defaults to a Restricted execution policy that blocks all scripts from running. Since Get-ZimmermanTools.ps1 was downloaded from the internet, PowerShell will refuse to execute it unless you allow remote-signed scripts.

The RemoteSigned policy allows locally created scripts to run freely and requires downloaded scripts to be signed by a trusted publisher.

• If PowerShell asks you to confirm the policy change, type Y and press Enter.
• Download all tools by running:

C:\ForensicTools\Get-ZimmermanTools.ps1 -Dest C:\ForensicTools\EZTools -NetVersion 9

What does this command do?

• -Dest C:\ForensicTools\EZTools tells the script where to save all the downloaded tools.
• -NetVersion 9 ensures you get the .NET 9 builds of each tool, matching the runtime you just installed.

The script will display progress as it downloads each tool. Wait until it finishes and returns you to the prompt.

• Confirm the tools were downloaded by running:

dir C:\ForensicTools\EZTools

You should see multiple folders including RegistryExplorer, RECmd, and TimelineExplorer.

Script will not run or downloads fail?

If you see an error about the script not being digitally signed, run Unblock-File -Path C:\ForensicTools\Get-ZimmermanTools.ps1 and then try again.

If downloads fail partway through, re-run the same command. The script will skip tools it already downloaded and pick up where it left off.

Help me troubleshoot the Get-ZimmermanTools script

Launch Registry Explorer and confirm it works

Registry Explorer is the primary tool you will use throughout this project to browse, decode, and search registry hives. Let's confirm it launches correctly.

• Launch Registry Explorer by running:

C:\ForensicTools\EZTools\RegistryExplorer\RegistryExplorer.exe

Before the window appears, do you expect to see any data loaded, or an empty workspace?

The application opens and displays an empty workspace with a menu bar at the top. No hives are loaded yet.

What if Windows SmartScreen appears?

Because the tools were downloaded from the internet, Windows SmartScreen may display a warning on first launch. Click More info, then click Run anyway. The tools are digitally signed by Eric Zimmerman.

Registry Explorer will not launch?

If you see an error about a missing framework or runtime, confirm your .NET 9 Desktop Runtime installation by running dotnet --list-runtimes and checking for Microsoft.WindowsDesktop.App 9.0.x in the list.

If the entry is missing, go back and install the Desktop Runtime (not the regular runtime or ASP.NET runtime).

Help me fix this .NET runtime error

Your forensic workstation is set up. Next up, you will use these tools to acquire registry hives from your live system for offline analysis.

Acquire Registry Hives from Your Live System

Your forensic tools are ready, but they need data to analyze. The registry hive files stored on disk are locked by Windows while the system is running. You cannot simply copy them from their location at C:\Windows\System32\config.

The reg save command creates consistent copies of these locked hives that forensic tools can open offline. This acquisition step mirrors what a DFIR professional does on day one of an incident response engagement: secure the evidence before touching anything.

In this step, get ready to:

• Create an evidence directory to store exported hives.
• Export five registry hives from your live system using reg save.
• Generate SHA-256 hashes for chain-of-custody integrity.

Create an evidence directory and export system hives

Before you can export anything, you need a dedicated folder to hold the evidence. Keeping acquired hives in their own directory mirrors how forensic analysts organize case evidence.

• In your Administrator PowerShell window, create the evidence directory by running this command:

New-Item -ItemType Directory -Path C:\ForensicTools\AcquiredHives -Force

What does this command do?

New-Item -ItemType Directory creates a new folder at the specified path. The -Force flag means the command will not error if the folder already exists.

• Confirm the directory was created. You should see output displaying the new AcquiredHives directory path.

Now you can export the four core system hives into this directory. Each hive stores a different category of system-wide information.

• Export all four system hives by running these commands:

reg save HKLM\SYSTEM C:\ForensicTools\AcquiredHives\SYSTEM /y
reg save HKLM\SOFTWARE C:\ForensicTools\AcquiredHives\SOFTWARE /y
reg save HKLM\SAM C:\ForensicTools\AcquiredHives\SAM /y
reg save HKLM\SECURITY C:\ForensicTools\AcquiredHives\SECURITY /y

What does each hive contain?

• SYSTEM stores hardware configuration, services, and device history (including USB devices).
• SOFTWARE stores system-wide application settings, installed programs, and autostart entries.
• SAM (Security Account Manager) stores local user account data and password hashes.
• SECURITY stores security policies and cached credentials.

• After each command runs, confirm you see the message The operation completed successfully. printed four times (once per hive).

Seeing an access denied error?

• The reg save command requires Administrator privileges. Make sure your PowerShell session title bar shows "Administrator" at the beginning.
• If not, close this window. Press the Windows key, type PowerShell, right-click Windows PowerShell, and select Run as administrator.
• help me fix an access denied error when running reg save

Export the current user's NTUSER.DAT hive

The per-user hive contains the richest forensic artifacts. Program execution history, file access records, and typed paths are all stored under HKCU.

• Export your current user's hive by running this command:

reg save HKCU C:\ForensicTools\AcquiredHives\NTUSER.DAT /y

Why is NTUSER.DAT separate from the system hives?

System hives under HKLM store machine-wide settings shared by all users. The NTUSER.DAT file maps to HKCU and tracks everything specific to one user account: which programs they ran, which files they opened, and which paths they typed.

In an investigation, this is where you find evidence of deliberate user actions versus background system activity.

• Confirm you see The operation completed successfully. in the output.

Hash the acquired hives for integrity verification

In a real investigation, you must prove evidence was not tampered with after acquisition. Generating cryptographic hashes creates a fingerprint that changes if even a single byte is modified.

• Generate SHA-256 hashes for all five acquired hive files by running this command:

Get-ChildItem C:\ForensicTools\AcquiredHives\* | ForEach-Object { Get-FileHash $_.FullName -Algorithm SHA256 } | Format-Table Hash, Path

What does this command do?

• Get-ChildItem lists every file in the AcquiredHives folder.
• ForEach-Object pipes each file into Get-FileHash, which computes its SHA-256 hash.
• Format-Table presents the results in a clean table showing the hash value alongside each file path.

In a real case, you would record these hashes in your chain-of-custody log. If the hashes change later, you know the evidence was altered.

• You should see a table with five rows, one for each hive file, each showing a 64-character hash string and its file path.

Before running your final check, predict what you expect to see. How many files should be in your evidence directory, and should any of them be empty?

• Verify all five hives were exported with non-zero file sizes by running:

dir C:\ForensicTools\AcquiredHives

You should see five files listed: SYSTEM, SOFTWARE, SAM, SECURITY, and NTUSER.DAT. Every file should show a non-zero size in the Length column.

Seeing a file with zero size or a missing file?

• If a file is missing, scroll up to check if the corresponding reg save command printed an error message. Re-run that specific command.
• A zero-size file usually means the command was interrupted. Delete the file and re-run the reg save command for that hive.
• help me troubleshoot missing or empty registry hive exports

Your evidence is secured and verified. Next up, you will crack open the NTUSER.DAT hive in Registry Explorer and decode the hidden program execution history that Windows has been quietly recording.

Decode Program Execution History with UserAssist

Your registry hives are safely acquired with integrity hashes recorded. Now it's time to answer the core forensic question: what programs actually ran on this system, and when?

The UserAssist artifact records every GUI program launched through Windows Explorer, complete with run counts and last execution timestamps. Its entries are ROT13-encoded to hide them from casual inspection, but Registry Explorer's plugins decode them automatically.

In this step, get ready to:

• Load NTUSER.DAT in Registry Explorer and navigate to the UserAssist key to reveal decoded program execution history.
• Identify your most-executed programs and spot any anomalous entries.
• Cross-reference execution data with RunMRU and TypedPaths to build a fuller picture of user activity.

Load NTUSER.DAT and navigate to UserAssist

The NTUSER.DAT hive contains the richest per-user forensic artifacts. Loading it in Registry Explorer gives you access to decoded UserAssist data that would otherwise appear as meaningless text.

• Switch to Registry Explorer from earlier.
• Click File in the menu bar.
• Click Load hive.
• Navigate to C:\ForensicTools\AcquiredHives and select NTUSER.DAT.
• Click Open.

The hive loads in the left-hand tree pane with a root node labeled ROOT.

• In the tree pane, expand ROOT > SOFTWARE > Microsoft > Windows > CurrentVersion > Explorer > UserAssist.

You will see two or more GUID-named subkeys beneath UserAssist. Each GUID represents a different category of tracked execution.

• Expand one of the GUID subkeys.
• Click on the Count subkey inside it.

Before you look at the bottom pane, predict what you expect to see: readable program names, or encoded gibberish?

Look at the values pane (middle area). The value names appear as ROT13-encoded strings. Now look at the bottom pane (the plugin output area). Registry Explorer's UserAssist plugin has automatically decoded every entry into readable data.

What does the decoded output show?

The plugin pane displays a sortable grid with columns for each decoded entry.

• Full program paths decoded from ROT13 into plain text.
• Run count showing how many times each program was executed.
• Last execution timestamp indicating when the program last ran.
• Focus time showing how long the application had user focus.

Why is ROT13 used here?

ROT13 is a trivial substitution cipher that shifts each letter 13 positions in the alphabet. Microsoft applies it to UserAssist entries not for security, but to prevent the values from appearing in casual registry searches.

This means anyone using regedit would see nonsense strings and move on. A forensic analyst with the right tools decodes them instantly.

Don't see the decoded grid in the bottom pane?

Make sure you clicked on the Count subkey specifically, not the parent GUID key. The plugin only activates when you select the key it recognizes.

If the bottom pane shows nothing, try expanding and clicking the other GUID subkey's Count entry instead.

Still stuck? Why isn't Registry Explorer showing decoded UserAssist data in the plugin pane?

Identify your most-executed programs and spot anomalies

Decoded data only becomes forensic evidence when you analyze it for patterns and outliers. In a real investigation, this is where you separate normal system activity from potential compromise indicators.

• In the plugin pane, click the Run Count column header to sort by execution frequency.
• Review the top entries and confirm you recognize each program.
• Click the Last Executed column header to sort by most recent execution.
• Look for entries that match these anomaly indicators:

• Programs with paths you do not recognize.
• Executables that ran from temporary directories such as C:\Users\<you>\AppData\Local\Temp\.
• Programs with a single run count and a timestamp that stands out from your normal usage pattern.
• Entries pointing to unusual locations outside C:\Program Files or C:\Windows.

What would an anomaly look like in a real investigation?

An unknown executable in a temp folder with a single run count and a timestamp matching a suspected compromise window is a critical finding. It suggests something ran once (possibly malware), from a location that legitimate software rarely uses.

On your own machine, you may find entries for installers or updaters that ran from temp folders. That is normal. The key skill is recognizing which entries you can explain and which you cannot.

Cross-reference with RunMRU and TypedPaths

UserAssist shows what Explorer launched, but users also execute commands and navigate to paths manually. Two additional artifacts capture this intentional activity.

• In the tree pane, navigate to ROOT > SOFTWARE > Microsoft > Windows > CurrentVersion > Explorer > RunMRU.
• Review the values in the right pane. Each entry is a command typed into the Windows Run dialog (Win+R).

What does RunMRU tell you?

RunMRU provides evidence of execution for the last 26 commands typed by a user in the Windows Run dialog box. In an investigation, a command like \\fileserver\share here would suggest the user manually connected to a network resource.

• Now navigate to ROOT > SOFTWARE > Microsoft > Windows > CurrentVersion > Explorer > TypedPaths.
• Review the values. Each entry is a path typed directly into File Explorer's address bar.

What does TypedPaths reveal?

TypedPaths provides an ordered list of the last 26 paths typed into File Explorer's address bar. A path pointing to a network share followed by UserAssist showing execution of a binary from that share would indicate lateral movement or data staging.

Compare what you find in RunMRU and TypedPaths against your UserAssist data. Do any Run commands correlate with programs that later appear in UserAssist execution history?

RunMRU or TypedPaths key is empty?

If you have never used the Win+R Run dialog, RunMRU will have no entries. That is expected. Similarly, TypedPaths is only populated when you manually type paths into Explorer's address bar rather than clicking through folders.

Empty keys are a valid forensic finding. They tell you the user did not use these manual input methods. Why are my RunMRU and TypedPaths keys empty?

You now have a complete picture of program execution on this system: what ran through Explorer (UserAssist), what the user deliberately typed to execute (RunMRU), and where they manually navigated (TypedPaths). Next, you will hunt for anything configured to run automatically after a reboot.

Hunt for Persistence Mechanisms

Your UserAssist analysis revealed exactly which programs ran on your system and when they last executed. That answers "what happened?" but leaves a critical forensic question open: what is configured to run again automatically after a reboot?

Persistence is how attackers maintain access to a compromised system even after it restarts. Registry Run keys and Windows services are among the most common persistence mechanisms. In this step, you will audit every autostart location across multiple hives to determine whether anything on your system should not survive a reboot.

In this step, get ready to:

• Load the SOFTWARE hive and examine system-wide Run keys.
• Examine per-user persistence entries in NTUSER.DAT.
• Audit installed services in the SYSTEM hive for suspicious entries.

Load the SOFTWARE hive and examine system-wide Run keys

The SOFTWARE hive holds system-wide autostart entries that apply to every user who logs in. Programs registered here execute at boot regardless of which account signs in.

• In Registry Explorer, click File in the menu bar.
• Click Load hive.
• Navigate to C:\ForensicTools\AcquiredHives and open the SOFTWARE file.

The SOFTWARE hive loads alongside your already-open NTUSER.DAT. Registry Explorer supports multiple hives simultaneously.

• In the tree pane on the left, expand the SOFTWARE hive.
• Navigate to ROOT\Microsoft\Windows\CurrentVersion\Run.

The values pane on the right now shows every program configured to autostart at boot for all users. Each entry has a value name (usually the application name) and value data (the full command line that executes).

• Review each entry and note whether you recognize the program and its path.
• Also navigate to ROOT\Microsoft\Windows\CurrentVersion\RunOnce to check for one-time autostart entries.
• Navigate to ROOT\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run to see which autostart entries Windows has enabled or disabled.

What do these three keys tell you?

The Run key lists programs that execute every time the system starts. RunOnce lists programs that execute once and then get removed from the key automatically.

StartupApproved\Run is Windows' record of which Run entries are actually enabled. An entry disabled here will not execute even if it appears in the Run key.

Why focus on Run keys and services?

MITRE ATT&CK catalogs registry-based persistence as technique T1547.001. It is one of the most frequently observed persistence methods in real-world malware.

Attackers prefer Run keys because they require no admin privileges for per-user entries, survive reboots, and blend in with legitimate software autostart entries.

Not seeing any entries under Run?

Some systems have a minimal number of Run entries. If your Run key is empty, that is a valid finding. Check RunOnce and StartupApproved\Run as well. If no keys appear at all, confirm you expanded the correct hive (SOFTWARE, not NTUSER.DAT) and navigated to the full path ROOT\Microsoft\Windows\CurrentVersion\Run.

help me find the Run key in Registry Explorer

Examine per-user persistence in NTUSER.DAT

System-wide Run keys require admin privileges to modify. Per-user Run keys in NTUSER.DAT do not. An attacker with standard user access often adds persistence here because it flies under the radar.

• Switch to the loaded NTUSER.DAT hive in Registry Explorer's tree pane.
• Navigate to ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
• Review the entries listed in the values pane.

These are programs that autostart only when your specific user account logs in.

• Also navigate to ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce in the NTUSER.DAT hive.
• For each entry, check whether the executable path points to a known application's install directory or somewhere unexpected (such as AppData\Local\Temp or a randomly named folder).

Compare system-wide vs. per-user entries

In a real investigation, compare entries across both hives. A program in the per-user Run key that does not exist in the system-wide Run key could be legitimate (user-installed software like Spotify or Discord) or suspicious (malware that only needs user-level access).

The key question for each entry: can you explain why it exists?

Audit installed services in the SYSTEM hive

Services run as background processes with elevated privileges. A malicious service can execute code at boot before any user logs in. The SYSTEM hive's Services key contains every installed service on your machine.

• In Registry Explorer, click File then Load hive.
• Navigate to C:\ForensicTools\AcquiredHives and open the SYSTEM file.
• In the tree pane, expand the SYSTEM hive and navigate to ROOT\ControlSet001\Services.

You will see hundreds of subkeys. Each subkey is an installed Windows service. Most are legitimate system services, so you need to focus your audit.

What should you look for in the Services key?

• Services with an ImagePath value pointing to unusual locations (not C:\Windows\System32 or C:\Program Files).
• Services with a Start value of 2 (automatic) or 0 (boot) that you do not recognize.
• Recently created services, identifiable by their key's LastWriteTime timestamp being recent.

• Click on several service subkeys and examine their ImagePath and Start values in the values pane on the right.
• Use Registry Explorer's search feature (Ctrl+F) to search for keywords like temp, appdata, or any terms that seem unusual across the loaded hive.
• Note any services you cannot identify or that have paths pointing outside standard system directories.

Use LastWriteTime to narrow your search

Registry Explorer shows the LastWriteTime for each key. If you have a suspected compromise window, sort or filter by timestamp to find services installed during that period. A brand-new service created at an unexpected time is a strong indicator of malicious persistence.

Overwhelmed by the number of services?

A typical Windows 11 system has 300+ services. Do not try to review them all individually. Focus on services with Start values of 0 or 2 (these run automatically), and use the search feature to look for paths outside C:\Windows and C:\Program Files.

help me identify suspicious services in the SYSTEM registry hive

Think about how many total autostart entries you found across all three hives. How many can you confidently explain?

Switch between your loaded hives in the tree pane. You should now have NTUSER.DAT, SOFTWARE, and SYSTEM all loaded simultaneously. With all three visible, you can see every program configured to survive a reboot on your system, from per-user Run keys to system-wide autostart entries to background services.

You have now mapped what runs, what persists, and where it hides. Next up, you will reconstruct user activity and device history to understand what was actually accessed on the system.

Reconstruct User Activity and Device History

Your persistence audit answered a critical question: what is configured to run again after a reboot. Now you need to answer the next one: what did the user actually access?

Registry artifacts can reconstruct which files were opened, which folders were browsed, which USB devices were connected, and which network shares were mapped. In data exfiltration investigations, USBSTOR entries combined with MountPoints2 and RecentDocs can prove that a specific device was connected and used to access files at a specific time.

In this step, get ready to:

• Examine USB device connection history and map devices to drive letters in the SYSTEM hive.
• Map user-level device access and recently opened files in the NTUSER.DAT hive.
• Review folder browsing history and Explorer search queries to complete the user activity picture.

Examine USB device connection history

Every USB storage device that has ever been connected to a Windows system leaves a trace in the SYSTEM hive. The USBSTOR key records the device manufacturer, product name, serial number, and when it was last connected.

• In Registry Explorer, switch to the loaded SYSTEM hive in the hive selector at the top of the tree pane.
• Navigate to ROOT\ControlSet001\Enum\USBSTOR in the tree.
• Expand the subkeys. Each one represents a USB storage device class (a combination of manufacturer and product name).
• Expand a device class subkey to see individual device entries, each identified by serial number.
• Click on a device entry and check the key's LastWriteTime in the details pane. This indicates when the device was last connected.

You should see one or more device subkeys with names containing manufacturer and product identifiers like Disk&Ven_SanDisk&Prod_Ultra or similar entries for USB drives you have connected to this machine.

What does USBSTOR tell an investigator?

In a real investigation, USBSTOR proves a specific physical device was connected to the system. The serial number is unique to each device, so you can tie it to a specific USB drive recovered from a suspect.

The LastWriteTime tells you when the connection happened. Combined with other artifacts, this can establish a timeline of data exfiltration.

• Now navigate to ROOT\MountedDevices in the same SYSTEM hive.
• Look at the value names in the right pane. You will see entries starting with \DosDevices\ followed by drive letters (like D:, E:).
• The binary value data for each entry contains device identifiers that you can cross-reference against the serial numbers you found in USBSTOR.

This mapping tells you which drive letter was assigned to a specific USB device. In an investigation, this is crucial for connecting file access logs to a physical device.

Not seeing any USBSTOR entries?

If you have never connected a USB storage device to this machine, the USBSTOR key may be empty or have very few entries. This is a valid finding in itself. In an investigation, an empty USBSTOR on a machine suspected of data exfiltration via USB would be noteworthy.

Make sure you are looking at ControlSet001 (the active control set), not ControlSet002.

Still having trouble? Help me find USB device artifacts in my SYSTEM hive

Map user-level device access and recent documents

The SYSTEM hive proves a device was physically connected. The NTUSER.DAT hive proves the user accessed it. These are different questions with different evidentiary weight.

• Switch to the loaded NTUSER.DAT hive in Registry Explorer.
• Navigate to ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2.
• Examine the subkeys. Each GUID or letter corresponds to a mounted volume or network share the user interacted with.

You should see subkeys representing drive letters and GUIDs. The key's LastWriteTime shows when the user last accessed that volume.

What is the difference between USBSTOR and MountPoints2?

USBSTOR (SYSTEM hive) records that a device was plugged in at the hardware level. MountPoints2 (NTUSER.DAT) records that a specific user account accessed the mounted volume. A USB drive could be connected without the user ever opening it in Explorer.

In a shared computer scenario, MountPoints2 ties device access to a specific user account, not just the machine.

• Now navigate to ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs.
• Click on the RecentDocs key itself. In the bottom pane, Registry Explorer's plugin decodes the binary value data into readable filenames.
• Expand the subkeys organized by file extension (.docx, .pdf, .xlsx, etc.) to see which specific files were accessed most recently for each type.

You should see decoded filenames in the plugin output pane. These are files you opened through Explorer, regardless of which application handled them.

• Review the decoded entries and ask yourself: do you recognize every file listed?
• Note any files accessed from unusual locations (network paths, external drives, temp folders).

Why does RecentDocs matter in a forensic investigation?

RecentDocs tracks recently accessed files. In an investigation, this can prove a user opened a sensitive document before exfiltrating it. Combined with USBSTOR timestamps, you can establish a sequence: device connected, file accessed, device removed.

RecentDocs showing binary gibberish instead of filenames?

Make sure you are looking at the bottom plugin output pane, not the raw values pane. Registry Explorer's plugin automatically decodes the binary MRU data into readable filenames. If the plugin pane is not visible, go to View in the menu bar and ensure the plugin area is enabled.

Need more help? Help me see decoded RecentDocs filenames

Examine folder browsing history and search queries

ShellBags record every folder a user has browsed in Explorer, including folders that have since been deleted. While the primary ShellBag data lives in UsrClass.dat, the NTUSER.DAT hive contains Open/Save dialog history and Explorer search queries.

• In the loaded NTUSER.DAT hive, navigate to ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU.
• Click on the key and examine the plugin output in the bottom pane. Registry Explorer decodes the binary shell item data into readable file paths.
• Expand the subkeys organized by extension (* for all types, or specific extensions). These reveal files the user accessed through any application's Open or Save dialog.

You should see decoded file paths showing files you opened or saved through dialog boxes. This captures access that RecentDocs might miss.

Why check both RecentDocs and OpenSavePidlMRU?

RecentDocs tracks files opened through Explorer (double-clicking). OpenSavePidlMRU tracks files accessed through application dialogs (File > Open, File > Save As). Together they give a more complete picture of file access than either one alone.

• Now navigate to ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery.
• This key stores searches performed in Explorer's search bar. Examine the values to see what you (or anyone using this account) searched for.

You should see search terms that match things you have searched for in File Explorer. In an investigation, search queries can reveal intent. A search for "confidential" or "password" followed by file access and a USB connection tells a clear story.

Connect the dots across artifacts

The real power of registry forensics is correlation. A single artifact proves one thing. Multiple artifacts from the same time window prove a sequence of events. Try matching timestamps across what you found: USBSTOR connection time, RecentDocs file access, OpenSavePidlMRU saves, and WordWheelQuery searches.

WordWheelQuery key is empty or missing?

If you rarely use Explorer's search bar (perhaps you use the Start menu search or a third-party tool instead), this key may have few or no entries. That is a valid finding. Not all artifacts exist on every system.

Still stuck? Help me find search history artifacts in NTUSER.DAT

Before you confirm your end-of-step check, think about this: how many USB devices do you expect to see recorded in your USBSTOR key? Consider every flash drive, external hard drive, or USB-connected phone you have ever plugged into this machine.

• Switch back to the SYSTEM hive and navigate to ROOT\ControlSet001\Enum\USBSTOR.
• Expand the device class subkeys and confirm you can see USB device entries showing manufacturer, product name, and serial number for devices you have previously connected.

You should see device subkeys with identifiable names and at least one device entry with a serial number and a LastWriteTime timestamp. If you also see decoded entries in MountPoints2 and RecentDocs from the NTUSER.DAT hive, your user activity reconstruction is complete.

Secret mission

Batch-Process All Hives with RECmd and Build a Unified Timeline

Use RECmd's batch processing to generate a full artifact dump across all acquired hives, then use Timeline Explorer to filter and cross-correlate timestamps, identifying a complete chain of events for a specific time window on your system.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally, so there are no ongoing costs or cloud resources to worry about. Decide whether to keep your resources for future investigations, clean up sensitive data, or delete everything entirely.

Resources you used:

• C:\ForensicTools\EZTools - Eric Zimmerman's forensic tools (~200MB, free, no ongoing cost).
• C:\ForensicTools\AcquiredHives - Registry hive exports from your own system.
• C:\ForensicTools\RECmdOutput - CSV analysis output from RECmd batch processing.

Keep everything running

No action needed. Choose this if you plan to use the forensic tools for future investigations or want to keep the acquired hives as a baseline snapshot of your system.

• The EZ Tools folder stays ready for future forensic work on your system or on acquired images from other machines.
• Your acquired hives serve as a known-good baseline. If you suspect a future compromise, you can compare fresh hive exports against these originals.
• The .NET 9 Desktop Runtime remains installed. Other applications on your system may also depend on it.

Pause - I'll come back to this later

Clean up sensitive data while keeping the forensic tools installed. The acquired hives contain sensitive information about your system, including installed software, user activity, account data, and USB device history.

• Delete the acquired hives and analysis output by running this command in PowerShell:
• Keep the tools in C:\ForensicTools\EZTools for future use.

Remove-Item -Path "C:\ForensicTools\AcquiredHives" -Recurse -Force
Remove-Item -Path "C:\ForensicTools\RECmdOutput" -Recurse -Force

• Confirm the folders are gone by running:

Get-ChildItem C:\ForensicTools

You should only see the EZTools folder and the Get-ZimmermanTools.zip file remaining.

Delete - I don't want to use this again

Remove all project resources and start fresh. This deletes the forensic tools, acquired hives, and all analysis output.

• Delete the entire project directory by running this command in PowerShell as Administrator:

Remove-Item -Path "C:\ForensicTools" -Recurse -Force

• Confirm the directory is gone by running:

Test-Path C:\ForensicTools

This should return False.

What about .NET 9?

The .NET 9 Desktop Runtime remains installed on your system. Other applications may depend on it, so only uninstall it if you are certain nothing else needs it.

To remove it, open Settings, go to Apps, then Installed apps. Search for Microsoft Windows Desktop Runtime - 9.0 and click Uninstall.

That's a Wrap!

That's a Wrap!

Nice work. You just conducted a real forensic investigation of your own Windows 11 machine using the same tools and methodology that DFIR professionals use in actual incident response engagements.

You've learned how to:

• Acquire registry hives from a live Windows system using reg save and verify their integrity with SHA-256 hashing, following proper forensic evidence-handling methodology.
• Decode ROT13-encoded UserAssist entries in Registry Explorer to reveal exactly which programs ran on a system, how many times they executed, and when.
• Hunt for persistence mechanisms across Run keys, services, and startup entries, and reconstruct user activity from USBSTOR device history, RecentDocs, and ShellBag artifacts.
• (Secret Mission) Batch-processed all acquired hives with RECmd and built a cross-correlated timeline in Timeline Explorer, identifying coherent event chains across multiple data sources within a specific time window.

Ready to quiz yourself?