Detecting Persistence via Windows Registry RunKey Monitoring

In the post-exploitation lifecycle, the transition from initial access to established presence is defined by a single, critical objective: persistence. An attacker who gains access via a transient exploit or a single stolen session cannot afford to lose access upon a system reboot or user logout. To ensure longevity, they must implement mechanisms that allow their malicious code to re-execute automatically.

While modern adversaries are increasingly adopting sophisticated techniques like DLL side-loading or WMI event subscriptions, the Windows Registry "Run" keys remains a foundational, highly reliable, and frequently abused method for achieving persistence. For the threat hunter and the SOC analyst, monitoring these keys is not merely a "check-the-box" task; it is a high-signal opportunity to intercept an adversary before they move laterally through the environment.

The Anatomy of Registry Persistence

The Windows Registry serves as the central hierarchical database for system configuration. Within this database, several specific keys are designed to trigger the execution of programs during the boot process or user logon. The most prominent targets are the `Run` and `RunOnce` keys.

The Key Locations

Persistence can be established at two primary levels of privilege:

1. System-Wide Persistence (`HKEY_LOCAL_MACHINE` - HKLM):

• `HKLM\Software\Microsoft\Windows\CurrentVersion\Run`
• `HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce`
• Changes here affect every user who logs into the machine. Modifying these keys typically requires administrative privileges, making them a target for attackers who have already achieved privilege escalation.

1. User-Specific Persistence (`HKEY_CURRENT_USER` - HKCU):

• `HKCU\Software\Microsoft\Windows\CurrentVersion\Run`
• `HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce`
• These keys affect only the current user. Crucially, an attacker does not need administrative rights to modify `HKCU`. This makes it a primary target for initial-access payloads (e.g., via phishing) to ensure they remain active even after the initial exploit process terminates.

The Mechanism of Execution

The "value" within these registry keys is essentially a command-line string. When the Windows Shell (typically `explorer.exe`) initializes the user session, it parses these keys and executes the command associated with each value.

An attacker's payload might be a simple path to a malicious `.exe`, but modern "Living off the Land" (LotL) techniques allow for much more stealthy execution. Instead of a standalone binary, the registry value might contain a call to `powershell.exe`, `mshta.exe`, `regsvr32.exe`, or `rundll32.exe`, passing encoded commands or remote URLs as arguments.

Detection Engineering: Moving Beyond the Path

Detecting persistence via RunKeys requires more than just monitoring for "new" entries. A naive approach-alerting on every modification to these keys-will result in an unmanageable volume of false positives caused by legitimate software updates, browser installers, and driver configurations.

Effective detection requires a multi-layered telemetry approach, focusing on the content of the registry value and the context of the modification.

1. Telemetry Source: Sysmon is Essential

While Windows Event Logs provide some visibility, Microsoft Sysmon (System Monitor) is the gold standard for this type of detection. Specifically, Sysmon Event ID 13 (Registry Value Set) provides the granular detail needed. It captures the target object (the key), the details (the value being set), and the process that performed the modification.

2. Analyzing the Payload (The "What")

The most significant indicator of compromise (IoC) is not the presence of a new key, but the suspicious nature of the command string. Detection logic should look for:

• LOLBin Execution: Look for `Run` key values that invoke binaries like `powershell.exe`, `cmd.exe`, `mshta.exe`, `regsvr32.exe`, `certutil.exe`, or `scrcons.exe`.
• Encoded Commands: A high-entropy or Base64-encoded string within a registry value is a massive red flag. Attackors use `-EncodedCommand` in PowerShell to obfuscate their intent.
• Network Indicators: Look for strings containing `http://`, `https://`, or IP addresses within the registry value, suggesting a "downloader" pattern.
• Suspicious File Paths: Monitor for execution from highly unusual directories like `\Temp\`, `\AppData\Local\Temp\`, or `\Users\Public\`.

3. Analyzing the Process Context (The "How")

The process that modifies the registry key is just as important as the key itself.

• Parent Process Analysis: If `msiexec.exe` (a legitimate installer) modifies a RunKey, it is likely a standard software installation. If `cmd.exe`, `powershell.exe`, or a web browser process modifies a RunKey, the probability of malicious intent increases exponentially.
• Unsigned Binaries: Correlate the process responsible for the registry change with its digital signature. An unsigned binary modifying `HKLM\...\Run`

Conclusion

As shown across "The Anatomy of Registry Persistence", "Detection Engineering: Moving Beyond the Path", a secure implementation for detecting persistence via windows registry runkey monitoring depends on execution discipline as much as design.

The practical hardening path is to enforce strict token/claim validation and replay resistance, host hardening baselines with tamper-resistant telemetry, and behavior-chain detection across process, memory, identity, and network telemetry. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track detection precision under peak traffic and adversarial packet patterns and mean time to detect, triage, and contain high-risk events, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.