Evidence of Execution: RunMRU Forensics

 

An enduring artifact originating in early Windows versions (pre-dating Windows XP) and persisting with minimal modification through contemporary releases (Windows 10/11) is the Run dialog (commonly invoked via Win + R). Originally integrated prominently within the classic Start Menu, its primary access vector has shifted toward the persistent keyboard shortcut, which remains the predominant method employed by users today.

This facility has consistently appealed to system administrators, power users, digital forensic examiners, and threat actors alike, enabling rapid, direct execution of applications, commands, and resources. Like numerous other Windows shell components, the Run dialog maintains a Most Recently Used (MRU) history of previously entered items. These entries are stored in the user-specific registry hive under the following key:

NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

The RunMRU key embodies a canonical string-based MRUList artifact, wherein discrete command executions are persisted as REG_SZ values under single lowercase alphabetic identifiers (a–z), accommodating a maximum of 26 entries. The value data (as opposed to the value name) encapsulates the raw command string suffixed by the delimiter \1 (e.g., notepad.exe\1). A dedicated MRUList REG_SZ value maintains the recency ordering as a contiguous string of these alphabetic designators, with the leftmost character representing the most recently utilized entry (position 0 in the MRU sequence). The LastWrite timestamp of the RunMRU key itself serves as a high-fidelity temporal anchor, directly correlating with the execution time of the foremost entry in the MRUList. Notably, only successfully resolved commands are recorded; failed executions are omitted. Re-execution of a prior command updates its position within the MRUList and refreshes the key’s LastWrite timestamp without allocating a new alphabetic slot, while new entries beyond the 26-slot capacity overwrite the least recently used value. This structure affords digital investigators a precise, user-specific chronology of Run dialog activity within the NTUSER.dat hive.

Retention of this artifact is subject to user-specific Start menu personalization settings. Disabling the privacy setting “Let Windows improve Start and search results by tracking app launches” directly suppresses the population of Run dialog history. The history is stored in plaintext and is limited to approximately 26 entries before older items are overwritten.

RunMRU constitutes one of the most elementary and transparent forensic artifacts encountered during Windows registry analysis. At a high level, its operational mechanics are as follows:

• Command Ingestion and Storage: The key is updated upon each successful execution of a command via the Run dialog. Individual commands are mapped to single-letter value names (a through z).
  • Novel commands are allocated a unique alphabetic value.
  • Re-execution of an existing command reassigns it to its prior letter and elevates it to the foremost position in the recency order.
  • Upon saturation of all 26 lettered values, subsequent commands overwrite the least recently utilized entry in a classic FIFO (first-in, first-out) manner.
• Ordering Mechanism: The MRUList value maintains the precise sequence of execution as a concatenated string, wherein the leftmost (index-0) position denotes the most recent entry.
• Temporal Correlation: The most recent command (position 0 within the MRU ordering) is intrinsically linked to the LastWrite timestamp of the RunMRU key, affording examiners a precise temporal marker for the final command invocation through this interface.

Solely valid and successfully processed commands are persisted; invalid inputs (such as references to non-existent files or malformed syntax) are generally excluded from recording.

Invocation Methods for the Run Dialog

The Run dialog is implemented via an exported function within shell32.dll and can be instantiated through multiple vectors, all of which ultimately invoke the same underlying API. The principal methods include:

1. Direct Keyboard Invocation: Win + R
2. Start Menu Integration: Search for “Run” within the Windows Start Menu.
3. Task Manager Utility: Navigate to File → Run new task in Task Manager.
4. Shell Protocol URI: Shell:::{2559a1f3-21d7-11d4-bdaf-00c04f60b9f0}
5. Direct DLL Invocation: rundll32.exe shell32.dll,#61
6. Programmatic Access: Invocation through Shell.FileRun() or the IShellDispatch.FileRun() interface.

Regardless of the invocation method used, all pathways converge on the same underlying shell32.dll functionality and use the same RunMRU registry key to populate the command history dropdown (provided the actions occur under the same user context).

Additional Technical Details

• Methods #4 and #5 can be executed directly from the Run dialog or Explorer’s search bar. When launched from a command prompt or script, prefixing with explorer.exe may be required for the shell protocol variant.
• Method #5 executes the Run dialog by directly calling the exported ordinal 61 within shell32.dll.

This uniformity in backend behavior ensures consistent forensic artifacts across invocation techniques, with all activity traceable to the same RunMRU structure.

Run Dialog Interaction with the RunMRU Artifact

Upon instantiation of the Run dialog, the process queries the MRUList value within the RunMRU key associated with the security context of the current user. Once retrieved, the dialog enumerates the referenced lettered values (a–z) to reconstruct the command history in the correct recency order for display. When a command is executed via the Run dialog, the following updates occur atomically:

• The new (or re-executed) command is written to an appropriate lettered value.
• The MRUList string is rewritten to reflect the updated execution sequence, promoting the entry to the most recent position.

Forensic Observations

• Although the Run dialog re-queries all values under the key during initialization, these reads do not appear to influence core functionality beyond history population.
• Empirical testing confirms that alterations, deletions, or discrepancies in non-active values do not trigger updates to the displayed history. The only persistent modification written back to the registry is the latest successfully executed command, along with the revised MRUList.

This behavior underscores the deterministic and narrowly scoped nature of the artifact, rendering it highly reliable for timeline reconstruction of Run dialog activity while limiting the potential for extraneous or noisy data.

Forensic Significance of the RunMRU Artifact

The RunMRU key yields several high-fidelity data points of investigative value:

• User Context: Attribution to the specific user account under whose security context the command was executed.
• Command Fidelity: The exact string as typed by the user, preserving full syntax, parameters, and paths.
• Execution Sequence: The relative order of commands via the MRUList structure.

Notwithstanding these attributes, RunMRU generally offers limited overall forensic utility for the following reasons:

• Constrained History: Retains only the most recent 26 commands per user.
• Narrow Scope: Records activity exclusively from the Run dialog interface; commands executed via other vectors (e.g., Command Prompt, PowerShell, scripts, or Explorer) are not captured.
• Temporal Limitations: While the sequence of execution can be reconstructed, precise timestamps are available solely for the most recent command, derived from the registry key’s LastWrite time. Earlier entries lack individual temporal metadata.

Despite its constraints, RunMRU can prove particularly probative in targeted investigations, such as:

• Insider Threat Cases: Where privileged users (e.g., system administrators) exhibit anomalous or excessive use of the Run dialog, potentially indicating reconnaissance, privilege escalation, or data exfiltration attempts.
• Social Engineering Attacks: Instances in which adversaries manipulate victims into executing commands via the Run dialog, including:
  • Technical support scams that instruct users to launch URLs or tools facilitating the deployment of remote monitoring and management (RMM) software.
  • Malware campaigns leveraging fake CAPTCHA prompts or similar lures to induce victims to paste and execute malicious payloads directly into the Run box.

In such contexts, even this modest artifact can serve as a critical corroborative element, linking user behavior, social engineering tactics, and post-compromise activity.

Limitations of the RunMRU Artifact: When Data Is Absent

A comprehensive forensic examination of the RunMRU key requires not only an understanding of the data it contains but also a clear recognition of the circumstances under which relevant activity will be absent from the artifact. Several conditions result in the non-population or absence of entries within the RunMRU key:

• RunMRU History Disabled: Disabling the privacy setting “Let Windows improve Start and search results by tracking app launches” directly suppresses the population of Run dialog history. Once deactivated, the registry value Start_TrackProgs (located under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced) is set to 0, signaling that tracking is disabled. In addition to halting future logging, this change typically triggers the immediate deletion of the existing RunMRU key, thereby purging all prior command history. The presence of a zeroed or absent Start_TrackProgs value, coupled with a missing or newly recreated RunMRU key, serves as a strong indicator of intentional privacy configuration changes. Examiners should correlate this with the timing of the setting modification to differentiate between routine user preference adjustments and potential anti-forensic activity. 
  
  An alternative anti-forensic technique involves applying a Deny-All Access Control List (ACL) to the RunMRU registry key. This modification produces an effect functionally equivalent to disabling the tracking privacy setting. From a technical perspective, explorer.exe continues to attempt read and write operations against the RunMRU key during Run dialog usage. However, these operations fail silently due to explicit access-denied errors imposed by the restrictive ACL, preventing any updates to command history while leaving the key structurally intact. The presence of a Deny-All ACL on the RunMRU key—without a corresponding change to Start_TrackProgs—can serve as a subtle indicator of deliberate tampering. Investigators should examine the key’s security descriptor and modification timestamps, as this method leaves a distinct forensic footprint compared to standard privacy setting toggles. This technique allows the Run dialog to remain operational while effectively neutralizing artifact generation.
• Execution Outside the Run Dialog: Commands launched through alternative interfaces—such as Command Prompt, PowerShell, Windows Explorer context menus, scripts, scheduled tasks, or direct API calls—do not interact with the RunMRU subsystem and therefore generate no corresponding entries.
• History Cleared or Purged: The RunMRU key may have been manually deleted, programmatically cleared (e.g., via CCleaner or custom scripts), or reset through system maintenance routines. Even after clearing, new activity will resume recording only from that point forward.

The RunMRU artifact aligns most directly with MITRE ATT&CK technique T1059 (Command and Scripting Interpreter). The Run dialog frequently serves as a launch vector for interpreters such as cmd.exe, powershell.exe, and rundll32.exe, with the precise sub-technique determined by the invoked binary (e.g., T1059.001 for PowerShell or T1059.003 for Windows Command Shell).

In scenarios involving social engineering—such as fake CAPTCHA lures or technical support scams that induce victims to paste and execute malicious commands—the artifact further supports T1204.004 (User Execution: Malicious File Execution via Copy and Paste), providing clear evidence of the victim-initiated execution phase leading to payload activation or remote monitoring and management (RMM) tool deployment.

Regarding anti-forensic activity targeting the artifact itself (via privacy setting suppression, Deny-All ACL application, or direct key/value deletion), the activity maps to T1112 (Modify Registry). Secondary consideration may be given to T1070.004 (Indicator Removal: File Deletion) when external tools are used to remove the key, though native registry manipulation remains the primary classification.

The absence of expected RunMRU entries should not be interpreted as evidence of inactivity. Instead, it necessitates cross-correlation with complementary artifacts (e.g., UserAssist, Amcache, Prefetch, ShimCache, SRUM, or event logs) to build a more complete picture of program execution and user activity.