Module 7 of 22 — The Windows database of secrets, persistence, and forensic gold
🧠 The Core Truth
The Windows Registry is a hierarchical database that stores configuration for the OS, hardware, software, and users. It's not files — it's a memory-mapped database loaded at boot. Every setting, every preference, every autostart program lives here. Every user action leaves a trace. Every malware persistence mechanism touches it.
Why this matters: If it happened on Windows, the registry knows. Deletion ≠ erasure — the hive has transaction logs, backups, and shadow copies. The registry is the single richest source of forensic evidence on a Windows system. Understanding it is understanding Windows itself.
Forensics 101: The registry is a write-once-read-many audit log disguised as a configuration database. Even "deleted" keys leave traces in slack space and transaction logs.
🎯 Layman Translation
The registry is like a building's maintenance log. Every tenant (program) writes what they changed: "I installed a new lock," "I changed the thermostat," "I made a copy of the key." Even if the tenant moves out, the log remains. Forensics is reading that log. But it's more than a log — it's the building's wiring diagram, security camera schedule, and key inventory all in one.
🎙️ Mentor Callout — asi dev [HTB]
"The registry is Windows' memory between reboots. RAM forgets when the power dies; the registry remembers forever."
🎯 What the mentor means
When you turn off a computer, everything in RAM vanishes. But the registry is written to disk, so it survives shutdowns, restarts, and even power failures. It is where Windows stores the state it needs to pick up exactly where it left off: who can log in, what programs start automatically, what hardware is installed, and what the user last did. For an investigator, that means the registry holds a historical record that volatile memory cannot.
🔴 Red: Persistence mechanisms target the registry because changes survive reboots. One well-placed Run key or service configuration keeps access alive across power cycles.
🔵 Blue: Even if malware is removed from disk or memory, registry artifacts often remain. Offline hive analysis can recover deleted keys, transaction logs, and shadow copies that reveal the full timeline.
📚 Prerequisites — What You Need First
This module assumes you understand these concepts from earlier modules:
How EDR monitors registry changes. Understanding detection helps you evade it and verify integrity.
🏛️ Registry Architecture: The Five Hives
The Windows Registry is organized into five root keys called hives. Each hive is a separate file on disk (except HKCR and HKCC, which are merged views). Understanding hive files is critical for offline forensics — you can analyze them without booting the target system.
HKEY_CURRENT_USER (HKCU)
Current user's settings, preferences, and environment. Moves with the user profile across machines.
Forensic value: User activity, recently opened files, installed software per-user, autostart programs.
File: NTUSER.DAT (in user profile) Mount: HKEY_USERS\<SID>
HKEY_LOCAL_MACHINE (HKLM)
System-wide settings. Hardware, software, services, security policies. Applies to all users.
Files: SYSTEM, SOFTWARE, SAM, SECURITY (in %SystemRoot%\System32\config)
HKEY_CLASSES_ROOT (HKCR)
File associations, COM objects, OLE classes, shell commands. Merged view of HKLM\Software\Classes + HKCU\Software\Classes.
Forensic value: Malicious file handlers, COM hijacking persistence, default program associations.
Virtual hive — merged from HKLM + HKCU No standalone file
HKEY_USERS (HKU)
All loaded user profiles. Each user's NTUSER.DAT is mounted here under their SID.
Forensic value: Enumerate all users on the system. Cross-reference SIDs with SAM hive for username mapping.
Files: NTUSER.DAT for each user .DEFAULT for system profile
HKEY_CURRENT_CONFIG (HKCC)
Current hardware profile. Display settings, printer configurations, current hardware state.
Forensic value: Less critical for forensics, but can reveal attached hardware and display configurations.
Virtual hive — derived from HKLM\SYSTEM\CurrentControlSet\Hardware Profiles
Why "Hive"?
The name comes from the original Windows NT developers who saw the registry structure as a beehive — cells (data), bins (containers), and the hive file itself. The metaphor stuck. In forensics, we talk about "hive files" because each root key is literally a separate file that can be extracted, copied, and analyzed offline.
HKLM\SOFTWARE → C:\Windows\System32\config\SOFTWARE
Installed software, Windows settings, third-party application data
HKLM\SAM → C:\Windows\System32\config\SAM
User accounts, password hashes (encrypted with SYSKEY), group memberships
HKLM\SECURITY → C:\Windows\System32\config\SECURITY
LSA secrets, cached credentials, security policy — readable only by SYSTEM
HKCU → C:\Users\<username>\NTUSER.DAT
User preferences, recent documents, environment variables, autostart
HKU\.DEFAULT → C:\Windows\System32\config\DEFAULT
System profile (used before any user logs in)
⚠️ Critical Forensic Note
Hive files are locked by the kernel while Windows is running. You cannot copy them with normal tools. To acquire them live, use:
Raw disk access: FTK Imager, dd via WinPE
Volume Shadow Copy:vssadmin list shadows → copy from snapshot
RegSaveKey API: Requires backup privilege, saves hive to new file
Offline acquisition: Boot from USB/WinPE, copy files directly
The SAM and SECURITY hives are additionally encrypted with SYSKEY (boot key). You need the SYSTEM hive to decrypt them.
🔑 Registry Keys, Values, and Data Types
A registry key is like a folder — it can contain subkeys and values. A value is like a file — it has a name, a data type, and data. Understanding data types is essential for both attack and defense.
Registry Value Types
Type
Constant
Description
Forensic Use
REG_SZ
0x00000001
Fixed-length string (Unicode)
File paths, configuration strings, display names
REG_EXPAND_SZ
0x00000002
Expandable string (%ENVVAR%)
Paths with environment variables — must expand before use
Boolean flags, counters, version numbers, service start types
REG_MULTI_SZ
0x00000007
Multiple null-terminated strings
Lists of values, DNS suffixes, multiple paths
REG_QWORD
0x0000000B
64-bit unsigned integer
Large timestamps, 64-bit counters, file sizes
Why REG_EXPAND_SZ matters for forensics
Malware often uses %APPDATA%, %TEMP%, or %USERPROFILE% in persistence paths. A raw registry read shows %APPDATA%\evil.exe, but the actual path is C:\Users\Alice\AppData\Roaming\evil.exe. If you don't expand environment variables, you'll miss the file or flag it as "orphaned" when it actually exists.
🔧 The Windows Registry API
Every registry operation goes through the Win32 Registry API. Malware uses these same APIs. Forensics tools use these same APIs. Understanding them is understanding both sides of the battle.
Malware needs to survive reboots. The registry offers dozens of persistence locations. A defender who only checks Run keys is missing 90% of the attack surface. This section covers the critical persistence mechanisms every analyst must know.
🎙️ Mentor Callout — asi dev [HTB]
"Persistence lives in the registry. If you want to survive a reboot, you write yourself into the hive."
🎯 What the mentor means
Malware that only runs in memory disappears when the system restarts. To keep coming back, attackers store launch instructions in registry keys that Windows reads at boot or logon: Run keys, services, Winlogon values, scheduled tasks, and more. The registry is the address book Windows consults every time it starts up, so hiding there guarantees the payload is invited back.
🔴 Red: Enumerate every persistence location, not just Run keys. Services, IFEO, Winlogon, Boot Execute, AppInit_DLLs, and COM hijacking all offer reboot-survivable execution.
🔵 Blue: Baseline known-good autostart entries and monitor for changes to high-value keys. Tools like Autoruns and RegRipper's persistence plugins help catch registry-based persistence.
Run / RunOnce Keys CRITICAL
The most common persistence mechanism. Programs listed here execute at user logon (HKCU) or system boot (HKLM).
Forensic note: RunOnce keys are deleted after execution — but the deletion is logged in the hive transaction log. RegRipper's runonce plugin recovers them.
Impact: Shell runs at every logon. Userinit runs once per logon. Both execute with the logged-on user's privileges (or SYSTEM for Winlogon itself).
Detection: Check for comma-separated values. Legitimate Shell is just "explorer.exe". Anything with commas is suspicious.
Image File Execution Options (IFEO) HIGH
IFEO is a debugging feature that lets you attach a debugger to any executable. Malware uses it to hijack legitimate programs — when notepad.exe runs, your payload runs instead.
How it works: When Windows launches notepad.exe, it checks IFEO. If a Debugger value exists, it launches the debugger instead, passing the original executable as an argument. Your "debugger" can ignore the original and do anything.
Windows services run as SYSTEM, start automatically, and have no user interface. The perfect persistence mechanism.
HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>
ImagePath = path to executable
Start = 0 (Boot) | 2 (Auto) | 3 (Manual) | 4 (Disabled)
Type = 16 (Own process) | 32 (Shared process / svchost)
ObjectName = LocalSystem | NT AUTHORITY\LocalService | NT AUTHORITY\NetworkService
Service hijacking: Find a service with a writable ImagePath (weak permissions). Change it to your payload. Service starts as SYSTEM on next boot. See Module 08: Privilege Escalation for live exploitation.
Scheduled Tasks (Task Cache) HIGH
Scheduled tasks are stored in the registry as well as the file system. Even if the XML file is deleted, the registry cache may remain.
Forensic value: The TaskCache\Tree key contains the task name and GUID. TaskCache\Tasks contains the full task configuration including actions, triggers, and principals. Even deleted tasks may leave GUID entries in the Tree.
AppInit_DLLs HIGH
AppInit_DLLs loads specified DLLs into every process that loads user32.dll (which is nearly every GUI process).
Windows 10+ mitigation: Starting Windows 10, AppInit_DLLs requires code signing by default (unless Secure Boot is disabled). But on older systems or with Secure Boot off, this is a powerful injection vector.
COM (Component Object Model) objects are identified by CLSID (Class ID). By registering a malicious DLL under a legitimate CLSID, malware hijacks calls to that COM object.
HKCR\CLSID\{GUID}\InprocServer32
Default = path to malicious DLL
HKCU\SOFTWARE\Classes\CLSID\{GUID}\InprocServer32
Per-user COM hijacking — no admin required
Why this is stealthy: COM objects are loaded on-demand. The malicious DLL only runs when a program requests that specific COM object. No autostart. No service. Just a hijacked library call.
Boot Execute / BootVerification HIGH
Programs that run during system boot, before the logon screen.
Impact: Runs before Windows fully initializes. Even Safe Mode executes BootExecute. Chkdsk (autochk) is the legitimate entry. Anything else is highly suspicious.
Persistence Summary Matrix
Mechanism
Privilege Required
Execution Trigger
Stealth Level
Detection Difficulty
Run / RunOnce
User / Admin
Logon / Boot
Low
Easy (Autoruns)
Winlogon Shell
Admin
Logon
Medium
Medium (check Shell value)
IFEO Debugger
Admin
Target process launch
High
Hard (requires checking every IFEO key)
Services
Admin
Boot / Trigger
Medium
Medium (service enumeration)
Scheduled Tasks
User / Admin
Scheduled trigger
Medium
Medium (task scheduler)
AppInit_DLLs
Admin
Process creation
High
Hard (loaded into every GUI process)
COM Hijacking
User
COM object request
Very High
Very Hard (requires CLSID knowledge)
Boot Execute
Admin
System boot
High
Hard (runs before security tools)
🔬 Live Evidence: .42 Registry Analysis
📊 Real Data: WUPC Registry Forensics
Target: .42 (WUPC) | Tool: PowerShell + C Reg API | Date: 2026-06-29
PS>Get-ItemProperty "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
# Clean system — no unauthorized Run keys found
# During testing, SWTest_22DIV was written, survived 15s, then removed
# System Watcher did NOT roll back (detection-coupled behavior confirmed)
PS>Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
SecurityHealthSystray : C:\Windows\System32\SecurityHealthSystray.exe
# Standard Windows Security Health tray icon — legitimate
PS>Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" | Select Shell, Userinit
Shell : explorer.exe
Userinit : C:\Windows\system32\userinit.exe,
# Both values clean — no hijacking detected
PS>Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" | Select Name
# Only legitimate debug entries (VS JIT debugger)
# No suspicious IFEO debugger redirections
Finding: Run keys are the #1 persistence mechanism. Clean systems have only legitimate entries. Our test confirmed System Watcher doesn't rollback benign keys — detection is required. Winlogon and IFEO are clean on .42, but these are critical checks on any compromised system.
PS>Get-ItemProperty "HKLM:\SOFTWARE\KasperskyLab\protected\AVP21.25"
ProductName : Kaspersky Premium
ProductVersion : 21.25.7.504
InstallDir : C:\Program Files (x86)\Kaspersky Lab\Kaspersky 21.25
bRollbackAllowed : 1
bSelfProtection : 1
# System Watcher rollback ENABLED
# Self-protection ENABLED (registry keys protected from modification)
PS>Get-ChildItem "HKLM:\SOFTWARE\KasperskyLab\protected\AVP21.25\Data" | Select-Object Name
# Contains encrypted threat intelligence, update timestamps, scan statistics
# Binary format — requires Kaspersky's own tools to decode
PS>Get-ItemProperty "HKLM:\SOFTWARE\KasperskyLab\protected\AVP21.25\environment" | Select ProductStatus, LicenseKeyType
ProductStatus : 1 # Active
LicenseKeyType : 1 # Commercial (not trial)
# Full protection active, not expired
Finding: KAV configuration reveals product version, protection status, and data paths. The bRollbackAllowed=1 flag is the key System Watcher control. The bSelfProtection=1 flag means KAV registry keys are protected from tampering — even SYSTEM cannot modify them without disabling self-protection first.
PS>Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\AVP21.25"
Start : 2 # Auto-start (SERVICE_AUTO_START)
Type : 16 # SERVICE_WIN32_OWN_PROCESS
ImagePath : "C:\Program Files (x86)\Kaspersky Lab\Kaspersky 21.25\avp.exe"
DisplayName : Kaspersky Anti-Virus Service 21.25
ObjectName : LocalSystem
# Runs as SYSTEM — highest privilege level
PS>Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\HealthSecurityHost"
Start : 2 # Auto-start
Type : 16 # Own process
ImagePath : C:\Windows\System32\SecurityHealthService.exe
# Writable by admin — potential service hijack vector (tested, confirmed)
PS>Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\RpcSs" | Select Start, Type, ImagePath, ObjectName
Start : 2
Type : 20 # SERVICE_WIN32_SHARE_PROCESS (svchost)
ImagePath : C:\Windows\system32\svchost.exe -k rpcss
ObjectName : NT AUTHORITY\NetworkService
# Shared process — multiple services in one svchost.exe
Finding: Service registry keys define how processes start, what privileges they have, and where their binaries live. Writable service paths = privilege escalation vectors. The Type field distinguishes own-process (16) from shared-process (20) services. Shared services run inside svchost.exe — hijacking one affects all in the group.
Finding: OS version and user SIDs reveal the attack surface. Windows 10 22H2 with Kaspersky 21.25 is our tested environment. The ProfileList key maps SIDs to usernames and profile paths. ProfileLoadTime is a 64-bit Win32 FILETIME — convert to human-readable for timeline analysis.
🕵️ Registry Forensics: The Analyst's Playbook
Registry forensics is the art of extracting evidence from hive files. Unlike live analysis (which sees only the current state), offline forensics reveals historical data, deleted keys, and transaction logs that the running system hides.
🎙️ Mentor Callout — asi dev [HTB]
"If you want to know what happened, read the registry. Users lie. Logs lie. The registry forgets slowly."
🎯 What the mentor means
Attackers can delete files, clear event logs, and wipe browser history, but the registry keeps backup copies, transaction logs, and shadow copies of itself. It records program execution, USB connections, folder access, user logons, and autostart changes. When other evidence sources have been cleaned, the registry often still tells the story.
🔴 Red: Understand that registry artifacts outlive your payload. Clean your tracks by considering transaction logs, USN journals, shadow copies, and backup hives — not just the live keys.
🔵 Blue: Make registry hive acquisition a priority in incident response. UserAssist, ShimCache, USBSTOR, Shellbags, and service configurations routinely answer "what happened" when everything else has been erased.
UserAssist is one of the most valuable forensic artifacts. It records every GUI program executed by the user, including the execution count and last execution timestamp (as a ROT13-encoded, encrypted value).
PS>Get-ItemProperty "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}\Count"
# {CEBFF5CD-ACE2-4F4F-9178-9926F41749EA} = GUID for executable files (.exe)
# Values are ROT13-encoded program paths
# Example: "Uebzr\qbphzragf\evkpr.rkr" = "Home\documents\rixce.exe" (ROT13)
# Each value contains: Execution count (4 bytes) + Last run timestamp (8 bytes FILETIME)
# Decoding UserAssist with Python:
import codecs
import struct
from datetime import datetime, timezone
def decode_userassist(name, data):
# Name is ROT13 encoded
path = codecs.decode(name, 'rot_13')
# Data structure: [padding][count][timestamp]
# Timestamp is at offset 4 (after count), 8 bytes, little-endian FILETIME
if len(data) >= 16:
count = struct.unpack('
Why UserAssist matters
UserAssist is enabled by default on all Windows versions. It records execution even if the user clears their Run history, deletes Prefetch files, or wipes event logs. The only way to stop it is to disable the feature entirely (which itself leaves a registry trace). For incident response, UserAssist is a goldmine of user activity.
Shellbags: Evidence of Folder Access
Shellbags store Windows Explorer folder view settings (window size, column layout, icon arrangement). But they also prove the folder existed and was accessed — even if the folder was later deleted.
Forensic value: BagMRU is a tree structure tracking folder navigation. Each node contains a folder path hash. Even if the folder is deleted, the shellbag remains. Tools like ShellBags Explorer parse these into a folder tree showing what the user browsed — including external drives, network shares, and hidden directories.
USB Device History (USBSTOR)
Every USB storage device connected to Windows leaves a permanent record in the registry. This includes the vendor, product, serial number, and first/last connection times.
PS>Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR" | Select Name
# Each subkey is a USB device: Vendor&Product&SerialNumber
# Example: Disk&Ven_SanDisk&Prod_Cruzer_Blade&Rev_1.00\4C530001230407109182&0
PS>Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR\...\4C530001230407109182&0"
FriendlyName : SanDisk Cruzer Blade USB Device
DeviceDesc : @usbstor.inf,%genericbulkonly.devicedesc%;USB Mass Storage Device
Mfg : @usbstor.inf,%generic.mfg%;Compatible USB storage device
DeviceInstance : USBSTOR\DISK&VEN_SANDISK&PROD_CRUZER_BLADE&REV_1.00\4C530001230407109182&0
# Serial number: 4C530001230407109182 — can be traced to physical device
# First connection time is in the device's Properties subkey:
# HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR\...\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0066
# Data: 64-bit FILETIME of first connection
# Last connection: ...\0067
⚠️ USBSTOR is persistent across formats
Even if the user formats the USB drive, the registry entry remains. Even if the user reinstalls Windows, the USBSTOR entries in the old SYSTEM hive are preserved. The only way to remove them is to manually delete the registry keys (which itself is logged) or use a registry cleaner (which leaves its own traces). USB device history is one of the most reliable forensic artifacts.
💾 Offline Hive Analysis
Live registry analysis is limited — the kernel locks hive files, transaction logs are active, and you only see the current state. Offline analysis lets you examine hive files from a disk image, shadow copy, or forensic acquisition without the running system's interference.
Step 1: Acquire Hive Files
# Method A: Volume Shadow Copy (live acquisition)
CMD>vssadmin list shadows
Shadow Copy ID: {c8c5c3a0-...}
Original Volume: (C:)\\?\Volume{...}
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4
CMD>mkdir C:\forensics\shadowCMD>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\Windows\System32\config\SYSTEM C:\forensics\shadow\CMD>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\Windows\System32\config\SOFTWARE C:\forensics\shadow\CMD>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\Users\SWu\NTUSER.DAT C:\forensics\shadow\
# Method B: Raw disk access (offline boot)
# Boot from WinPE / forensic Linux (SIFT)
# Mount the target disk read-only
# Copy hive files directly — no locks, no kernel interference
Step 2: Mount Hives in RegEdit (Live Analysis)
# On a clean analysis machine:
CMD>reg load HKLM\FORENSIC_SYSTEM C:\forensics\shadow\SYSTEMThe operation completed successfully.CMD>reg load HKLM\FORENSIC_SOFTWARE C:\forensics\shadow\SOFTWARECMD>reg load HKU\FORENSIC_USER C:\forensics\shadow\NTUSER.DAT
# Now browse in regedit.exe:
# HKLM\FORENSIC_SYSTEM → offline SYSTEM hive
# HKLM\FORENSIC_SOFTWARE → offline SOFTWARE hive
# HKU\FORENSIC_USER → offline NTUSER.DAT
# When done:
CMD>reg unload HKLM\FORENSIC_SYSTEM
Step 3: Parse with Python (Programmatic Analysis)
# Install python-registry: pip install python-registry
from Registry import Registry
# Open offline hive file
reg = Registry.Registry("C:\\forensics\\shadow\\SYSTEM")
# Navigate to a key
key = reg.open("ControlSet001\\Control\\TimeZoneInformation")
# Read values
for value in key.values():
print(f"Name: {value.name()}, Type: {value.value_type_str()}")
print(f"Data: {value.value()}")
# Enumerate subkeys
for subkey in key.subkeys():
print(f"Subkey: {subkey.name()}")
# Find USB devices
usbstor = reg.open("ControlSet001\\Enum\\USBSTOR")
for device in usbstor.subkeys():
print(f"Device: {device.name()}")
for serial in device.subkeys():
print(f" Serial: {serial.name()}")
friendly = serial.value("FriendlyName")
if friendly:
print(f" Name: {friendly.value()}")
Step 4: Extract Password Hashes from SAM
# Requires both SAM and SYSTEM hives (SYSTEM contains the SYSKEY)
# Tool: impacket-secretsdump (Kali Linux)
KALI>impacket-secretsdump -system SYSTEM -sam SAM LOCAL
Impacket v0.11.0 - Copyright 2023 Fortra
[*] Target system bootKey: 0x8f3c2a00b1e4d5f6...
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
SWu:1001:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b:::
# NTHash can be cracked with hashcat:
# hashcat -m 1000 -a 0 hashes.txt wordlist.txt
# Or use Python with pypykatz (pure Python, no dependencies):
KALI>pypykatz registry --sam SAM --system SYSTEM
🛠️ RegRipper: Automated Registry Analysis
RegRipper is the industry-standard tool for automated registry forensics. Written by Harlan Carvey, it parses hive files with hundreds of plugins, each targeting a specific forensic artifact. It's fast, thorough, and produces investigator-friendly output.
What RegRipper Does
Parses hive files offline — no Windows required
Runs plugins (Perl scripts) that extract specific artifacts
Outputs timeline-friendly text reports
Handles deleted keys via transaction log parsing
Extracts timestamps, user activity, and persistence indicators
# RegRipper Installation (Windows or Linux with Perl)
CMD>git clone https://github.com/keydet89/RegRipper3.0.gitCMD>cd RegRipper3.0
# List all available plugins
CMD>rip.exe -l
Plugin Hive Description
------ ---- -----------
amcache Amcache Amcache.hve entries
appcompatcache System ShimCache/AppCompatCache
auditpolicy Security Audit policy settings
bam System Background Activity Moderator (Win10+)
cmd_shell Software Command shell history
compname System Computer name
devclass System Device classes
env System Environment variables
usbstor System USB storage devices
userassist NTUSER UserAssist entries
recentdocs NTUSER Recent documents
run NTUSER Run keys
runmru NTUSER Run MRU
shellbags NTUSER Shellbags / folder access
shimcache System ShimCache (program execution)
services System Services
soft_run Software Software\Run keys
soft_runonce Software Software\RunOnce keys
winlogon Software Winlogon settings
# Run a single plugin against a hive
CMD>rip.exe -r C:\forensics\shadow\SYSTEM -p usbstor
USBStor
-------
Device: Disk&Ven_SanDisk&Prod_Cruzer_Blade&Rev_1.00
Serial: 4C530001230407109182&0
FriendlyName: SanDisk Cruzer Blade USB Device
First Connect: 2024-03-15 14:32:18 UTC
Last Connect: 2026-06-28 09:15:42 UTC
# Run all plugins for a hive type
CMD>rip.exe -r C:\forensics\shadow\NTUSER.DAT -f ntuser
# Runs all NTUSER-specific plugins: userassist, recentdocs, shellbags, run, runmru, etc.
# Output is a comprehensive user activity report
# Run all plugins for SYSTEM hive
CMD>rip.exe -r C:\forensics\shadow\SYSTEM -f system
# Generate a timeline (-t option)
CMD>rip.exe -r C:\forensics\shadow\NTUSER.DAT -p userassist -t
Thu Jun 26 2026 14:23:17Z,userassist,REG_BINARY,UserAssist\{CEBFF5CD-...}\Count\HRZR_EHACVQY:%PROGRAMFILES%\Microsoft Office\root\Office16\WINWORD.EXE,Count: 42
Why RegRipper is essential
A single NTUSER.DAT hive can contain thousands of forensic artifacts. Manual analysis would take days. RegRipper's plugins automate the extraction of the most valuable evidence — UserAssist, shellbags, recent documents, typed URLs, mounted devices, and more. In incident response, RegRipper is the first tool you run after acquiring hives. It gives you the "what happened" before you dive into the "how."
Critical RegRipper Plugins for Incident Response
Plugin
Hive
What It Finds
IR Priority
userassist
NTUSER.DAT
Program execution count & timestamps
CRITICAL
shimcache
SYSTEM
AppCompatCache — program execution evidence
CRITICAL
usbstor
SYSTEM
USB device connections & serial numbers
HIGH
shellbags
NTUSER.DAT / USRCLASS.DAT
Folder access evidence (deleted folders too)
HIGH
recentdocs
NTUSER.DAT
Recently opened documents by file extension
MEDIUM
run
NTUSER.DAT / SOFTWARE
Run key persistence
CRITICAL
services
SYSTEM
Service configurations & ImagePath
HIGH
winlogon
SOFTWARE
Shell/Userinit hijacking
CRITICAL
bam
SYSTEM
Background Activity Moderator (Win10+ execution evidence)
HIGH
amcache
Amcache.hve
Program execution & installation evidence
HIGH
🧪 Lab Exercise: Registry Persistence Scanner
Write a C program that:
Enumerates all Run keys (HKCU and HKLM)
Checks if each value points to an existing file
Flags non-existent paths (orphaned persistence)
Checks file signatures on existing binaries
Outputs: [Hive] [KeyName] [Path] [Status]
Challenge: Handle REG_EXPAND_SZ (environment variables like %APPDATA%). Recurse into RunOnce and RunOnceEx keys. Detect suspicious paths (temp folders, appdata, unusual extensions). Check Winlogon Shell and Userinit for hijacking. Scan IFEO for debugger redirections.
Question 1: Which hive file contains user password hashes, and what additional file is needed to decrypt them?
A) The SOFTWARE hive contains password hashes, and no additional file is needed
B) The SAM hive contains password hashes, and the SYSTEM hive is needed for the SYSKEY decryption
C) The SECURITY hive contains password hashes, and the NTUSER.DAT is needed for decryption
D) The SYSTEM hive contains password hashes, and the SAM hive is needed for the boot key
Question 2: Why does IFEO (Image File Execution Options) with a Debugger value represent a powerful persistence mechanism?
A) It modifies the original executable file on disk
B) It redirects execution whenever the target program is launched, without modifying the original binary, and requires no code in the target process
C) It only works for system processes running as SYSTEM
D) It permanently disables Windows Defender for the target process
Question 3: In offline registry forensics, why is analyzing a Volume Shadow Copy hive often better than analyzing the live registry?
A) Shadow copies contain encrypted data that reveals hidden malware
B) The live registry is always corrupted and unreliable
C) Shadow copies capture historical states, may contain deleted keys, and are not locked by the running kernel
D) Shadow copies are automatically decrypted by the VSS service
📚 Key Takeaways
Registry is the OS diary: Everything leaves a trace. Configuration, execution, persistence, and user activity are all recorded.
Hive files are forensic gold: SYSTEM, SOFTWARE, SAM, SECURITY, and NTUSER.DAT can be extracted and analyzed offline. Each contains different evidence types.
Persistence lives in many places: Run keys, Winlogon, IFEO, Services, Scheduled Tasks, AppInit_DLLs, COM hijacking, and Boot Execute. Check them all.
System Watcher is detection-coupled: No detection = no rollback. Understanding this from Module 12 is critical for both attack and defense.
Service keys = privilege: ImagePath hijacking is SYSTEM escalation. Writable service paths are a privilege escalation vector per Module 08.
UserAssist is execution evidence: Even if the user deletes Prefetch, clears event logs, and wipes history, UserAssist remains.
USBSTOR never forgets: Every USB device connected leaves a permanent record with vendor, product, serial number, and connection times.
Shellbags prove folder access: Even deleted folders leave shellbag evidence. The user browsed it; the registry remembers.
RegRipper automates analysis: Hundreds of plugins extract the most valuable artifacts from offline hives. It's the first tool to run in incident response.
Forensics is reading: The same APIs malware uses (RegOpenKeyEx, RegQueryValueEx) are used for defense. The registry doesn't care who's reading — it just tells the truth.
🔬 Verification Status
KAV config enumeration
✅ LIVE .42
Run key persistence test
✅ LIVE .42
System Watcher rollback behavior
✅ LIVE .42
Service enumeration
✅ LIVE .42
Winlogon / IFEO enumeration
✅ LIVE .42
UserAssist / Shellbags theory
✅ DEMONSTRATED
USBSTOR device history
✅ DEMONSTRATED
Offline hive acquisition (VSS)
✅ DEMONSTRATED
RegRipper automated analysis
✅ DEMONSTRATED
SAM hash extraction (theory)
✅ DEMONSTRATED
🧠 The Mentor's Lesson
"The registry is the one place on Windows that never lies. Users can delete files, clear logs, wipe history — but the registry remembers. Every USB device, every program run, every folder opened, every persistence attempt. Learn to read the registry and you learn to read the soul of the machine."