The Windows Registry remains one of the most information-dense repositories for reconstructing system activity and user behavior. Far more than a configuration database, it serves as a critical historical record of execution, data access, and persistence mechanisms across Windows 10 and 11. While automated forensic tools are essential for extracting and parsing this data, the correct interpretation of the results remains the responsibility of the investigator. This article focuses on the Registry keys that possess distinct forensic significance. We will move beyond the standard enumeration found in legacy guides to establish the specific links between technical artifacts and their value in an investigation, distinguishing between actionable evidence and system noise.

Note: This analysis assumes a working familiarity with Windows internals, hive structures, and standard forensic acquisition methodologies. It is not intended as an introductory primer, but rather as a technical reference for experienced examiners and security researchers tasked with deep-dive analysis.

A primary challenge in Registry forensics – and a significant hurdle for automated analysis software – lies in the fragmentation of related data. Critical indicators are rarely stored sequentially. Often, a specific artifact (such as a device connection or a system event) is recorded only as an opaque Identifier (ID) or GUID in one hive, while the translation of that ID into a human-readable name or context resides in a completely different, unrelated key. The software must bridge these gaps to present a coherent picture.

The second layer of complexity involves high-level cross-reference analysis. True forensic insight requires elevating the focus from isolated data points to correlated chains of events. For instance, proving data exfiltration requires synchronizing artifacts from disparate sources: a USB device insertion event, simultaneous browser history accessing a specific file-sharing URL, subsequent network traffic spikes, and finally, the device removal. Similarly, establishing malicious intent often requires linking a program’s execution timestamp in one key with specific file read/write operations recorded elsewhere. This article aims to map these connections.

Architectural foundations: hives, transaction logs, and attribution

Successful Registry analysis requires navigating the Registry’s architecture as a transactional database rather than a static file system. Understanding how Windows commits data to disk via hives and transaction logs is essential for recovering deleted keys and accurately interpreting timestamps that might otherwise mislead an investigator.

The Windows Registry is composed of “hives,” which are binary files stored on the disk. When a user interacts with the system, changes are not immediately flushed to the primary hive file (e.g., NTUSER.DAT). Instead, Windows utilizes a transaction logging system to ensure data integrity.

In Windows 10 and 11, this system typically involves a primary hive file and associated transaction logs, often named .LOG1 and .LOG2.

• The Primary Hive: This contains the stable, committed registry data.
• The Transaction Logs (.LOG): These files contain distinct “dirty pages” – changes that have been made in memory but not yet fully synchronized to the primary hive.

Forensic Implication: The existence of transaction logs is critical for recovering “deleted” evidence. If a threat actor deletes a persistence key (e.g., a malicious Run entry) and the system is immediately seized or crashes, the record of that key’s creation and subsequent deletion can, in some cases, be recoverable only from the NTUSER.DAT.LOG* or SOFTWARE.LOG* files. Investigators typically use tools that parse both the hive and its logs to reconstruct the most current state of the registry, often recovering data that appears “gone” from the active view. These logs are a consistency mechanism, not a historical journal, so recoverability is not guaranteed.

Caution: Note that log replay success varies by tool, system state, and timing.

Attributing activities to a specific user

Attribution – linking an action to a specific human user – relies on distinguishing between machine-wide and user-specific hives. Knowing which hive stores a particular artifact allows an examiner to determine if an action was performed by a specific logged-in user or by a system-level process.

• SYSTEM (All Users/Machine)
  • %SystemRoot%\System32\config\SYSTEM Hardware config, USB history, Timezone, Mounted Devices. Essential for establishing the “scene” of the digital crime.
• SOFTWARE (All Users/Machine)
  • %SystemRoot%\System32\config\SOFTWARE Installed software, global settings, network profiles.
• SAM (All Users/Machine)
  • %SystemRoot%\System32\config\SAM User account metadata (login counts, password reset times, group membership).
• SECURITY (All Users/Machine)
  • %SystemRoot%\System32\config\SECURITY Local security policies and rights allocation.
• NTUSER.DAT (Local User)
  • C:\Users<User>\NTUSER.DAT Primary attribution source. Tracks user-specific execution, file access, and settings.
• UsrClass.dat (Local User)
  • C:\Users<User>\AppData\Local\Microsoft\Windows\UsrClass.dat Stores ShellBags and MUICache for the user. Often overlooked but vital for Windows 10/11 artifacts.
• Amcache.hve (All Users/Machine)
  • C:\Windows\AppCompat\Programs\Amcache.hve Application compatibility data. Stores SHA-1 hashes of executed binaries.

The “LastWrite” timestamp

Every Registry key functions like a folder with a “LastWrite” timestamp, similar to a file’s “Last Modified” time. However, individual values (the data inside the key) do not have timestamps. This structural limitation creates a “timestamp paradox” where an investigator knows something changed within a key at a specific time, but not necessarily which value was affected.

If, for example, a registry key Run has a timestamp of 2025-10-27 14:00:00, and it contains three values (Malware, GoogleUpdate, OneDrive), the timestamp only tells the investigator that one of those three values was added or modified at that time. It does not explicitly state which one.

To resolve this, one can attempt correlating the Registry timestamp with file system timestamps by checking the creation time of the executable referenced in the value (e.g., does malware.exe creation time match the Registry key update?)

Evidence of program execution: the “Who” and “What”

In almost every digital investigation – whether it involves malware infection, insider data theft, or unauthorized usage – the primary question is: “Did the specific user run this specific program?” Windows 10 and 11 utilize a suite of compatibility and tracking features that inadvertently create a robust history of program execution. By parsing these artifacts, forensic examiners can reconstruct a granular history of execution, distinguishing between the mere presence of a malicious file on a disk and its active utilization by a user or script.

UserAssist: records GUI interactions

UserAssist is a user-specific artifact located in the NTUSER.DAT hive that tracks programs launched via the Graphical User Interface (GUI). It is primarily used to populate the “Frequently Used Programs” list in the Start Menu, making it a high-fidelity source for supporting the conclusion that a user actively clicked on or launched an application.

Note: In modern Windows shell workflows, this artifact doesn’t guarantee accurate execution. If one uses the “jump to file location” from the Windows Startup/search menu, then a UserAssist entry will be created; run count and last run time will be updated even though the actual execution does not occur.

Location:
NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist{GUID}\Count

Forensic Meaning:
UserAssist is designed to populate the “Frequently Used Programs” list in the Start Menu. Because of this, it tracks programs launched via the Graphical User Interface (GUI), such as double-clicking an icon on the desktop or selecting an item from the Start Menu. It generally does not track command-line execution (e.g., running cmd.exe and typing whoami).

Structure and Decoding:
The subkeys under UserAssist are named using GUIDs. Two common GUIDs in Windows 10/11 are:

• {CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}: Executable File Execution.
• {F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}: Shortcut (.LNK) Execution.

The values inside these keys are ROT-13 encoded. For example, an entry for msedge.exe would appear in the registry as zfrqtr.rkr. Forensic tools automatically apply the ROT-13 cipher to decode these names.

Data Points:

• Run Count: How many times the user launched the application. A high run count (e.g., 50+) indicates habitual use, whereas a count of 1 might indicate a single compromised session.
• Focus Time: Windows tracks the duration the application was the “active” window in the foreground. This is a critical metric for intent. If a Remote Access Tool (RAT) has a high run count but zero focus time, it suggests it was running in the background without the user’s active engagement. Conversely, active focus time suggests the user was interacting with the tool.
• Last Execution Timestamp: A 64-bit FILETIME value indicating the last launch.

Windows 10/11 Nuance: In modern Windows, UserAssist also tracks Universal Windows Platform (UWP) apps (also known as Metro or Store apps). The entries for these may look different, often referencing the AppUserModelID (e.g., Microsoft.WindowsCalculator_8wekyb3d8bbwe!App) rather than a simple file path.

AppCompatCache (ShimCache): historical execution records and evidence of existence

The Application Compatibility Cache (ShimCache) is a system-wide artifact in the SYSTEM hive used to identify applications requiring compatibility “shims.” For investigators, it provides a valuable historical record of files that were executed or even just browsed via Explorer, often supporting the conclusion that a file existed on a system long after it has been deleted.

Caution: Note that ShimCache does not reliably prove execution, even with newer flags. Research is still evolving, and behavior differs by build. While ShimCache proves presence and interaction, execution flags are supportive, not definitive, and corroboration is required (BAM, Prefetch, AmCache, UserAssist).

Location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache

Forensic Meaning:
The Application Compatibility Cache, commonly known as ShimCache, is used by Windows to identify if an application requires specific “shims” (compatibility fixes) to run correctly.

• Evidence of Existence: ShimCache tracks files that were executed or browsed via Explorer. It supports that a specific file existed at a specific path on a specific volume (timestamp interpretation varies by build and parser).
• Volatility and Shutdown: The ShimCache data is maintained in RAM and is only written to the Registry hive (SYSTEM) when the computer shuts down or restarts.
• Investigative Tip: On a live system that has been running for weeks, the Registry key will be stale. Memory forensics (RAM capture) is required to get the current ShimCache. Depending on system state, remnants may also exist in hiberfile.sys and pagefile.sys. On a dead box (seized hard drive), the Registry holds the state as of the last shutdown.
• Execution Flag: In Windows 10 and 11, recent research has identified flags within the ShimCache data structure (often parsed as “Insert Flags” or “Execution Flags”) that can help distinguish between an executable that was simply visible in a folder window versus one that was actually run.

Forensic Utility: ShimCache is invaluable for identifying “dropped” malware that has since been deleted. Even if the file malware.exe is wiped from the disk, its entry in ShimCache persists, supporting that it was present on the system before the deletion.

AmCache: the hash repository

While artifacts like UserAssist rely primarily on file names and paths, AmCache introduces a higher level of fidelity by linking execution directly to the file’s content via hashing. This standalone hive is essential for identifying renamed malware – where a threat actor disguises a tool like Mimikatz as a harmless system process – and verifying the exact version of an executable used during an incident.

Location: C:\Windows\AppCompat\Programs\Amcache.hve (Note: This is a standalone hive file, not part of the standard Registry hives).

Forensic Meaning: AmCache.hve is one of the most powerful execution artifacts in modern Windows forensics because it links execution to the file’s content (hash) rather than just its name.

• SHA-1 Hash: AmCache stores the SHA-1 hash of executables and drivers. This is critical for attribution. If a suspect renames mimikatz.exe to svchost.exe to hide it, UserAssist will show svchost.exe was run (which looks legitimate). However, AmCache will record the SHA-1 hash of that svchost.exe. A quick lookup of that hash will reveal it is actually Mimikatz.
• Volume GUID: AmCache links the execution to a specific Volume GUID. This helps investigators determine if a program was run from the C: drive or from a removable USB drive.
• Installation Data: It also tracks the installation date and uninstallation events for software, providing a timeline of when tools were introduced to the system.

BAM and DAM: tracking background activity

Modern Windows power management strategies require the operating system to monitor resource consumption closely. The Background Activity Moderator (BAM) and Desktop Activity Moderator (DAM) serve this purpose, creating a side-channel of forensic evidence that captures the execution of background tasks and command-line tools often missed by GUI-centric artifacts like UserAssist.

Location:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\bam\State\UserSettings{SID}
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dam\State\UserSettings{SID}

Forensic Meaning: While their primary function is to optimize battery life by throttling resource-heavy background processes, BAM and DAM inadvertently create a high-fidelity execution log for processes that operate without a user interface. This makes them indispensable for identifying “silent” malware execution, background scripts, and lateral movement tools that never appear in the Start Menu or on the Desktop.

Critical Limitations:

• 7-Day Retention: Unlike Prefetch or UserAssist, BAM entries are often limited to roughly the last week on many systems; older entries may be purged on boot depending on OS behavior and state.
• Local Files Only: BAM may not reliably record executables launched from removable media (USB) or network shares. It strictly tracks local execution.
• Device Support: DAM is specific to devices supporting “Modern Standby” (tablets/laptops). On standard desktops, the DAM key is usually empty; focus on BAM instead.

Investigative Value: Despite these limitations, BAM remains a primary source for supporting the execution of background processes that do not have a GUI.

• Bridging the “GUI Gap”: Most execution artifacts (like UserAssist) focus on what the user explicitly “clicked”. BAM/DAM focuses on what actually “ran”. If a threat actor executes a command-line tool via a reverse shell or a scheduled task, UserAssist will likely miss it, but BAM can record it once the process consumes system resources.
• Proof of Successful Payload Detonation: In malware investigations, finding a malicious file on disk only proves presence. A corresponding entry in the BAM key strongly supports that execution occurred.
• Attribution to a Compromised Account: Because these keys are organized by User SID, they strongly support attribution stating that “The account with SID ending in -1001 was responsible for executing crypto_miner.exe,” distinguishing user-driven compromise from system-level service exploitation.

Evidence of file access and user navigation

While execution artifacts prove a tool was run, file access artifacts answer the critical question: “Which files or folders did the suspect browse, view or access?” These artifacts, often referred to as “Shell” artifacts, are generated by the Windows Explorer interface. They are essential for reconstructing the user’s navigation through the file system, proving access to specific files, and establishing the timeline of data exfiltration.

ShellBags: evidence of folder access

ShellBags are widely considered the most comprehensive artifact for mapping user navigation. Unlike other artifacts that track specific files, ShellBags track folders. Their primary forensic value lies in their persistence: they remain in the Registry even after the target folder or the entire external drive has been removed.

Locations:

• NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU (and \Bags)
• UsrClass.dat\Local Settings\Software\Microsoft\Windows\Shell\BagMRU (and \Bags)

Forensic Meaning: ShellBags are registry keys used to persist the view settings (e.g., icon size, window position, sort order) of folders viewed in Windows Explorer. Windows creates these entries so that when a user returns to a folder, it looks the same as when they left it.

Investigative Value:

• Historical Map: ShellBags create a persistent map of directories a user has visited, even if those directories no longer exist.
• External Paths (The Drive Letter Problem): ShellBags track folders on removable drives (e.g., E:\Stolen_Docs). However, caution is required: the artifact records the logical path (E:), not the physical device serial number. To prove that “E:” was a specific Kingston USB drive and not a local partition, investigators must correlate the ShellBag access timestamp with the drive letter mappings in the MountedDevices key.
• MTP Devices (Phones/Tablets): For modern devices like smartphones that connect via MTP (Media Transfer Protocol), ShellBags are highly specific. Instead of a generic drive letter, these entries often reference the device’s specific Registry path or GUID, making it significantly easier to distinguish between a “Samsung Galaxy S24” and a generic USB stick.
• Structure:
  • BagMRU: This key maintains a hierarchical tree structure that mirrors the folder structure navigated by the user. It uses a “Slot” numbering system to link folders to their settings.
  • Bags: This key stores the actual view settings (e.g., “Details View”, “Large Icons”) for the slots defined in BagMRU.

RecentDocs and OpenSaveMRU: identifying files of interest

While ShellBags prove a user entered a folder, RecentDocs and OpenSaveMRU prove they interacted with specific files. These artifacts are high-fidelity indicators of “intent.” The OpenSaveMRU, in particular, is generated only when a user actively interacts with the common Windows dialog box to open or save a file. In data theft investigations, this is the kind of evidence that differentiates passive browsing from active exfiltration, such as saving a corporate document to an external device.

Locations:

• RecentDocs: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
• OpenSaveMRU: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU

Forensic Meaning:

• RecentDocs: Tracks the last ~150 files accessed by the user, grouped by file extension (e.g., .jpg, .docx, .pdf). The MRUListEx value tracks the order of access, allowing investigators to reconstruct the sequence of file openings.
• OpenSavePidlMRU: This key specifically tracks files that were interacted with via the Windows common “Open” or “Save As” dialog boxes.
• Intent: This is a high-intent artifact. It implies the user actively navigated to a file and selected it to open or save. It is often used to prove that a user manually saved a file to an external device (e.g., “Save As” -> F:).
• PIDL Structure: The data is stored as a PIDL (Pointer to an Item ID List), a binary structure that contains the file name and full path.

TypedPaths: evidence of intentional navigation

TypedPaths distinguishes between casual and intentional browsing. When a user clicks a link, they are following a pre-determined path. When they manually type a path into the address bar, they are demonstrating both intent and specific knowledge of a destination. This artifact is critical in insider threat cases, as it often reveals a suspect’s knowledge of hidden network shares or internal IP addresses that they should not be accessing.

Location: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths

Forensic Meaning: This registry key stores the history of paths that were manually typed (or pasted) into the Windows Explorer address bar.

• Investigative Significance: Typing a path requires specific knowledge and intent. If a user navigates to \\192.168.1.50\C$\Hidden, it suggests they knew the server IP and the hidden share name. This is often used to differentiate between “accidental” browsing (clicking links) and “intentional” reconnaissance or lateral movement.

External devices and USB connections

In cases of data exfiltration or malware introduction via physical media, the Registry provides a detailed log of every USB device ever connected to the system. These artifacts are pivotal when an investigator needs to prove that a specific physical device found in a suspect’s possession was connected to a compromised machine at a specific time.

USBSTOR: the history of connected USB storage devices

The USBSTOR key serves as the primary historical inventory for external storage devices. It allows an investigator to enumerate every USB thumb drive, external hard disk, or smartphone that has been connected as a mass storage device. This registry key is the first step in linking a physical object to digital activity on the endpoint.

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR

Forensic Meaning: This key acts as a historical inventory of all USB mass storage devices connected to the machine.

• Subkey Structure: Devices are organized by Device Class ID, Vendor, Product, and Version.
• Serial Numbers: The subkey name typically represents the device’s Unique Serial Number (e.g., 001122334455).
• Generated IDs: If the serial number contains an ampersand (&) in the second position (e.g., 100&234...), it indicates the device lacks a unique hardware serial number, and Windows generated a temporary ID based on the port and device characteristics. This is a critical distinction, as a generated ID is not unique to the device and cannot be definitively linked to a specific physical USB stick found in a suspect’s possession.

Timestamps and connection history

Simply knowing a device was connected is often insufficient; investigators need to know when and for how long. Windows 10 and 11 store precise timestamps for device installation, arrival, and removal within specific property keys. These timestamps allow for the reconstruction of a timeline, proving, for example, that a backup drive was connected immediately before a massive file deletion event.

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_...\PID_...\Properties{83da6326-97a6-4088-9453-a1923f573b29}

Forensic Meaning: For each connected device, Windows 10 and 11 store detailed timestamps in subkeys named with specific property GUIDs. Within the GUID key {83da6326-97a6-4088-9453-a1923f573b29}, there are subkeys named with hexadecimal identifiers that correspond to specific timestamp events 15:

• 0064 (Decimal 100) – InstallDate: The timestamp of when the device was first installed (often used as a proxy for “first connection” for that device instance).
• 0065 (Decimal 101) – FirstInstallDate: Technically the “First Install Date.” For USB storage, this is almost always identical to 0064.
• 0066 (Decimal 102) – LastArrivalDate: The timestamp of the most recent connection (insertion).
• 0067 (Decimal 103) – LastRemovalDate: The timestamp of the most recent disconnection (removal).

Strategic Analysis: By comparing LastArrivalDate (0066) and LastRemovalDate (0067), an investigator can determine the duration of the last session. If the LastArrivalDate is later than the LastRemovalDate, it indicates the device is currently connected (or the system crashed/lost power while the device was attached).

MountedDevices: mapping hardware to drive letters

To fully reconstruct user activity, an investigator must bridge the gap between hardware identifiers (like a USB serial number) and the logical drive letters (like F:) referenced in other artifacts such as ShellBags or LNK files. The MountedDevices key helps establish this connection, enabling the correlation of file system activity on a specific drive letter back to the physical device responsible for it.

Note: MountedDevices only maintains information about the last mapping for each drive letter. If, for example, the user connected a SanDisk Cruzer (mapped as F:), and then connected a Kingston Data Traveler, that was also mapped as F:, only the last mapping will be preserved.

Location: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

Forensic Meaning: This key can help establish mappings that link a physical device/volume to a logical drive letter (e.g., F:).

• Mechanism: The key contains values like \DosDevices\F:. The binary data inside these values can be correlated to specific volumes and device instances, but formats vary; corroboration with additional artifacts is recommended.
• Investigative Workflow:
  1. Identify a suspicious USB device in USBSTOR (e.g., “SanDisk Cruzer”).
  2. Extract its identifying attributes (e.g., serial number/device instance details).
  3. Correlate drive-letter mappings in MountedDevices with other artifacts (ShellBags/LNKs) and device installation evidence.
• Conclusion: “The SanDisk Cruzer was likely associated with drive letter F: during at least one connection.” This allows the investigator to search LNK files and ShellBags specifically for activity on the F: drive.

Network and system configuration

Reconstructing the network environment and system state is crucial for identifying lateral movement and attributing the device to a specific location. By analyzing network profiles and configuration settings, an investigator can map the physical movements of a device – such as a laptop moving between corporate and public Wi-Fi networks – and identify suspicious network configurations that suggest an attacker was manually manipulating connections to bypass security controls.

Network profiles (the “Where” and “When”)

Network profiles provide a historical record of every network a device has connected to, effectively maintaining a list of its locations. This artifact is invaluable for proving a suspect was at a specific location (e.g., a coffee shop or a competitor’s office) at a specific time. By correlating the network name (SSID) with DateLastConnected timestamps, investigators can reconstruct the device’s physical journey and identify unauthorized connections to rogue or insecure networks.

Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

Forensic Meaning: This key stores a profile for every network (Wi-Fi, Ethernet) the system has connected to.

• ProfileName: The SSID (e.g., “Starbucks_WiFi”, “Corp_Secure”).
• DateCreated: The timestamp of the first connection to this network.
• DateLastConnected: The timestamp of the last connection.
• Geolocation: By correlating the SSID with the Wi-Fi access point’s BSSID (MAC address) when available from companion wireless artifacts (and, in some cases, registry signature data), investigators can use public geolocation databases (like Wigle) to physically locate where the computer was at a specific time.

Network interfaces and TCP/IP

While network profiles show where a device connected, the TCP/IP configuration reveals how it connected. Examining these keys allows an investigator to determine if a machine was using a standard dynamic IP address (DHCP) or if it was manually configured with a static IP. A sudden switch to a static IP on a user workstation can be a strong indicator of an attacker attempting to blend in with server traffic, bypass network access controls, or establish a persistent connection to a command-and-control server.

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

Forensic Meaning: This key contains the configuration for network adapters.

• Static IP vs. DHCP: Investigating the EnableDHCP value reveals if the machine was configured with a static IP address. Static IPs are common in corporate server environments but suspicious on user workstations or in home networks, potentially indicating an attacker manually configuring the network to bypass detection or connect to a rogue device.

TimeZone information

Time is the backbone of every forensic investigation. The TimeZoneInformation key is an important reference point for every timestamp on the system. Misinterpreting this value can lead to critical errors in timeline reconstruction, causing an investigator to align digital events (like a file download) with the wrong physical events (like a suspect entering a building), potentially invalidating the entire case.

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

Forensic Meaning:

• ActiveTimeBias: Stores the current offset from UTC in minutes.
• Importance: Establishing the correct time zone is the first step in any forensic timeline analysis. If the investigator assumes the system is in UTC but it is actually in UTC-5, the entire timeline of user activity will be shifted by 5 hours, potentially invalidating alibis or correlation with physical security logs.

Windows 11 specific artifacts and recent updates

Windows 11, particularly versions 23H2 and 24H2, has introduced new features and changed the behavior of existing artifacts. These updates, driven by the integration of AI and modern app architectures, create novel opportunities for investigators to recover data that was previously volatile or encrypted. Understanding these specific artifacts is essential for analyzing the latest generation of “Copilot+” PCs and ensuring that evidence from modern endpoints is not overlooked.

“Recall” and AI Snapshots

The introduction of the optional “Recall” feature in Windows 11 marks a paradigm shift in forensic visibility. By taking frequent snapshots of the user’s desktop to enable semantic search, the operating system effectively creates a visual log of user activity. For investigators, this is akin to having a surveillance camera pointed at the suspect’s screen, capturing transient data – such as ephemeral chat messages, displayed passwords, or online-only documents – that would never otherwise touch the disk.

Context: Introduced in mid-2024 for “Copilot+” PCs equipped with NPUs, Recall takes frequent screenshots of the user’s desktop to enable semantic search.

Important: At the time of this writing, Recall is an opt-in feature that requires users for explicit manual activation. In addition, Recall is currently only supported on PCs that meet a specific set of requirements: “a Copilot+ PC that meets the Secured-core standard; 40 TOPs NPU (neural processing unit)”. It may be unavailable on older PCs. Since Recall has legal/privacy sensitivity, rapid policy changes by Microsoft may affect possible future encryption or retention. In addition, managed/commercial defaults differ (Microsoft notes Recall is disabled by default for managed commercial devices).

Forensic Artifacts:

• Registry Control: The feature’s state is managed at Software\Policies\Microsoft\Windows\WindowsAI.
• Database: The semantic index is stored in an SQLite database at %AppData%\Local\CoreAIPlatform.00\UKP{GUID}\ukg.db.
• Image Store: Raw JPEG screenshots are stored in %AppData%\Local\CoreAIPlatform.00\UKP{GUID}\ImageStore.

Investigative Value: If enabled, Recall serves as a comprehensive “DVR” of user activity. It can capture sensitive data displayed on screen (passwords, encrypted chat messages) that is not otherwise saved to disk. The ukg.db database contains OCR (Optical Character Recognition) text derived from these screenshots, allowing investigators to search for keywords (e.g., “bomb”, “stolen”, “password”) across the user’s visual history. Access and retention may be constrained by Windows security controls and configuration.

Modern Notepad (TabState)

The modernization of the Notepad application has inadvertently created a useful forensic artifact. Because the new Notepad automatically saves the state of open tabs to prevent data loss, it preserves the content of “unsaved” documents on disk. This allows investigators to recover notes, code snippets, or addresses that a suspect typed into a scratchpad but never formally saved to a file, challenging the traditional assumption that unsaved data exists only in RAM.

Location: %LOCALAPPDATA%\Packages\Microsoft.WindowsNotepad_8wekyb3d8bbwe\LocalState\TabState (Related state metadata may also exist in %LOCALAPPDATA%\Packages\Microsoft.WindowsNotepad_8wekyb3d8bbwe\LocalState\WindowsState.)

Forensic Meaning: The modern Windows 11 Notepad application saves state automatically to allow users to close the app without losing unsaved tabs.

• Unsaved Content Recovery: Binary files (.bin) in the TabState directory contain the actual text content of unsaved tabs. This is a critical discovery for forensics: users often use Notepad as a temporary scratchpad for copying credentials, snippets of code, or illicit data. Previously, if the file wasn’t saved, the data was lost (RAM only). Now, it persists on disk in these binary files.

The triage strategy: artifacts to ignore (noise reduction)

In digital forensics, time is often the scarcest resource. An investigator can easily become overwhelmed by the sheer volume of data within the Registry, chasing down artifacts that look promising but yield no actionable intelligence. To maintain efficiency, it is crucial to know what to ignore. This section highlights “noisy” or redundant artifacts that, while technically valid, offer a low return on investment in modern Windows 10 and 11 investigations.

Redundant application MRUs

Legacy forensic guides often prioritized the manual extraction of Most Recently Used (MRU) lists for individual applications, such as Adobe Reader or Microsoft Word. While this method was necessary in older versions of Windows, modern operating systems have centralized these records. Today, spending hours parsing individual application hives is often a duplication of effort, as the OS itself now aggregates this data more reliably elsewhere.

Legacy Advice: Manually check the MRU keys for every installed application (e.g., Software\Adobe\Acrobat\Recent).

Modern Reality: In Windows 10/11, this is inefficient. The centralized RecentDocs and JumpLists (file system) provide a consolidated view of recent file access across all applications. Specific application MRUs should only be examined if the investigation focuses narrowly on that specific application (e.g., “Did the user open this PDF in Acrobat specifically?”).

Performance Counters (Perflib)

The vast array of performance data stored in the Registry does not mean that more data equals more evidence. These keys are designed for real-time system monitoring, not historical reconstruction. They generate a high volume of changes that clutter timeline analysis without offering any particular insight into user actions, file access, or malicious intent.

Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib

Analysis: These keys contain dynamic performance statistics. They update constantly but provide virtually no insight into user behavior, file access, or malicious activity.

Generic CLSID Keys

The HKEY_CLASSES_ROOT hive is massive, containing millions of GUIDs (Globally Unique Identifiers) that define file associations and COM objects. While it is technically possible for malware to hide here, manually browsing this hive is akin to searching for a needle in a haystack composed entirely of other needles. Unless there is a specific indicator of compromise (IOC) pointing to a hijacked COM object, this area should be deprioritized in favor of higher-fidelity persistence locations.

Context: The HKEY_CLASSES_ROOT hive is largely a derived view of file associations.

Strategic Advice: Unless investigating a specific persistence technique known as “COM Hijacking” (where a CLSID is modified to point to malware), manually browsing the millions of GUIDs in this hive is a waste of investigative resources.

Live system analysis: the friction between forensics and security

Registry forensics faces a harsh reality when transitioning from theory to live systems. While endpoint protection is designed to lock down a system against unauthorized access, forensic utilities require unrestricted access to secure evidence – including locked system files. This conflict creates immediate operational risks. Modern antivirus engines with aggressive heuristics often flag legitimate forensic binaries as malware, potentially terminating the acquisition process or quarantining the tool itself. Even without blocking, active background scanning introduces significant I/O latency and threatens evidence integrity, a challenge we explored in Live System Analysis: Mitigating Interference from Antivirus Tools.

Elcomsoft Quick Triage is engineered to navigate these specific constraints. It allows investigators to acquire and parse critical Registry hives and volatile state data—such as AmCache and ShimCache—from live endpoints while minimizing the risk of triggering heuristic blocks or altering evidence timestamps. By automating the collection of high-value artifacts, investigators can rapidly validate hypotheses and identify compromised systems before committing to the time-intensive process of full disk imaging.

When live acquisition poses too high a risk, an alternative strategy involves booting into a clean forensic environment. As detailed in Choosing the Right Strategy: Cold Boot Forensics vs Live System Analysis, this approach bypasses active defenses entirely, granting unrestricted access to Registry hives and files that would otherwise be locked by the operating system.

Conclusion

The forensic analysis of the Windows Registry in Windows 10 and 11 requires a disciplined, hierarchical approach. By prioritizing artifacts that provide high-fidelity evidence of execution (UserAssist, AmCache), intent (TypedPaths, ShellBags), and data movement (USBSTOR, MountedDevices), investigators can construct a defensible narrative of events.

The shift to Windows 11 introduces new challenges – specifically the AI-driven “Recall” feature and the persistence of “unsaved” data in Notepad – but also offers new opportunities for evidence recovery. The Registry remains a major source of artefacts in the Windows OS; while the content of the file system changes, the Registry continues to record the actions of the user with remarkable precision. Successful investigations depend not on finding every key, but on understanding the mechanics and meaning of the right ones.

Acknowledgments and references

This article builds upon the collective knowledge of the digital forensics community. The detailed analysis of Windows 10 and 11 artifacts presented here would not be possible without the research and documentation provided by the following authors and organizations. We extend our gratitude to them for their contributions to the field.

1. Windows Forensic 101 (Altay)
2. Windows Registry Forensics 2025 (Cyber Triage)
3. Registry Forensic Analysis. WHAT IS REGISTRY (Medium)
4. Digital Forensics: Artifact Profile – USB Devices (Magnet Forensics)
5. Windows forensic keys: essential artifacts for digital investigation (INCIBE-CERT)
6. Uncovering Windows Forensics Artefacts for Digital Forensics Investigators (Medium)
7. Digital Forensics – Relevant artifacts for a forensic analysis (SECUINFRA)
8. Windows Registry Forensics Cheat Sheet 2025 (Cyber Triage)
9. Windows ShellBag Forensics in Depth (GIAC Certifications)
10. NTUSER.DAT Forensics Analysis 2025 (Cyber Triage)
11. Introduction to Windows Artifacts: Your Gateway to Effective Incident Response (Medium)
12. Typed Paths Blog (Forensafe)
13. Windows Forensics: USB Device Profiling (Medium)
14. USB Artifact Analysis Using Windows Event Viewer, Registry and File System Logs (MDPI)
15. A question about arbitrary values in USB registry keys (ThinkDFIR)
16. Registry, Event Logs, and Persistence Indicators (Cursa)
17. Windows Persistence Explained: Techniques, Risks, and What Defenders Should Know (Cofense)
18. Event Triggered Execution: Image File Execution Options Injection (MITRE ATT&CK)
19. 012 Image File Execution Options Injection (CISA)
20. Image File Execution Options Injection (Elastic Security)
21. Windows Wireless Networks Blog (Forensafe)
22. How to Find Evidence of Network Windows Registry (Cyber Triage)
23. Windows Forensics Cheatsheet (TryHackMe)
24. Windows Registry Forensics: Analysis Techniques (Belkasoft)
25. The king is dead, long live the king! Windows 10 EOL and Windows 11 forensic artifacts (Securelist)
26. UserAssist Forensics 2025 (Cyber Triage)