Windows Registry as an Attack Surface

Why the registry is the persistence surface of choice

The registry is attractive for persistence because it is ubiquitous — every Windows system has it. It survives reboots because registry hives are stored as files on disk in C:\Windows\System32\config\. It is complex — thousands of keys and values make manual inspection impractical even for experienced investigators. And most registry modifications are legitimate — software installation, configuration changes, and Windows updates write to the registry constantly, generating thousands of events per day on an active endpoint. The attacker's modification hides in the noise of legitimate activity.

The registry also persists without requiring the attacker to drop additional files. A Run key value that contains powershell.exe -enc [base64] achieves persistence using only a registry entry and a built-in system binary. No malicious executable on disk. No DLL to scan. No file hash to match. The persistence mechanism is a single registry value that instructs the OS to execute a living-off-the-land binary with attacker-controlled arguments at every logon. This is why file-based AV scanning alone cannot detect registry-based persistence — the "malware" is a configuration change, not a file.

The critical distinction for detection is not that a modification occurred but which keys are modified. A write to HKCU\Software\Microsoft\Windows\CurrentVersion\Run is a persistence attempt until proven otherwise — this key causes a program to execute every time the user logs in. A write to HKCU\Software\SomeApplication\Settings\WindowSize is a legitimate application saving its configuration. The detection strategy focuses on specific high-value keys, not all registry modifications.

Run and RunOnce keys are the simplest and most common persistence mechanism. The attacker adds a value to HKCU\...\Run (executes at user logon) or HKLM\...\Run (executes at system boot for all users). The value contains the path to the malicious executable or a command line like powershell.exe -enc [base64]. HKCU Run keys require no administrative privileges — any standard user can write to their own HKCU hive, making this the lowest-barrier persistence mechanism available.

Services provide SYSTEM-level persistence. The attacker creates a service by writing to HKLM\SYSTEM\CurrentControlSet\Services\{ServiceName}. The ImagePath value contains the executable path. The Start value determines when the service starts — 2 for automatic at boot, 3 for manual, 4 for disabled. A new service with Start=2 and an ImagePath pointing outside of System32 or Program Files is a strong persistence indicator. Windows Event ID 7045 logs new service installations alongside Sysmon Event ID 12 and 13 for the registry modification.

COM hijacking is more sophisticated. Every COM object is registered in the registry with a CLSID (Class ID). When an application loads a COM object, Windows looks up the CLSID in the registry. The lookup order is HKCU first, then HKLM. An attacker who creates a HKCU entry for a COM object normally registered only in HKLM causes their DLL to load instead of — or in addition to — the legitimate DLL. The DLL executes within the context of the application that loads the COM object, making the persistence nearly invisible. The legitimate COM object still functions because the attacker's DLL proxies calls to the original.

COM hijacking is particularly dangerous because it requires no administrative privileges — any standard user can write to HKCU. The persistence triggers not at logon but whenever an application loads the hijacked COM object, which may happen minutes after boot or on-demand when the user opens a specific application. Detection requires comparing HKCU COM registrations against HKLM to identify shadow entries — HKCU CLSID entries that duplicate existing HKLM CLSIDs. Sysmon Event ID 12 and 13 capture the registry creation, and Event ID 7 (ImageLoaded) captures the DLL load when the hijacked COM object is invoked. A DLL loaded from %TEMP% or %APPDATA% by a legitimate application that normally loads its COM DLLs from System32 is a strong indicator of COM hijacking.

Image File Execution Options (IFEO) provide process-level redirection. The key HKLM\...\Image File Execution Options\{executable.exe}\Debugger causes Windows to launch the specified debugger instead of the target executable. An attacker who sets Debugger = cmd.exe /c malicious.exe && target.exe causes their payload to execute every time the target is launched. Any modification to IFEO keys should be treated as suspicious outside of legitimate debugging scenarios.

What the evidence looks like: Sysmon and Event Log records

Before writing detection queries, you need to understand what the raw evidence looks like. When Sysmon captures a registry persistence event, the Event Log record contains the full context: who modified the key, which process made the modification, and what value was written. This is the record the analyst reads during investigation.

Log Name:      Microsoft-Windows-Sysmon/Operational
Source:        Microsoft-Windows-Sysmon
Event ID:      13
Task Category: Registry value set (rule: RegistryEvent)
Level:         Information
User:          SYSTEM
Computer:      DESKTOP-NGE042.northgate.local
Description:
  RuleName:      technique_id=T1547.001,technique_name=Registry Run Keys
  EventType:     SetValue
  UtcTime:       2026-02-14 09:23:17.441
  ProcessGuid:   {a23f8c41-8b12-67ae-1100-000000004600}
  ProcessId:     7284
  Image:         C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  TargetObject:  HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WindowsUpdate
  Details:       powershell.exe -w hidden -enc JABjAD0ATgBlAHcALQBPAGIAagBl...

This is what the CHAIN-ENDPOINT persistence looks like in the Sysmon log. Three fields tell the story: Image shows PowerShell made the modification — a script interpreter writing to a Run key is suspicious by default. TargetObject identifies the exact registry key — this is a Run key, which means the value executes at every user logon. Details shows the value data — a hidden, encoded PowerShell command is the behavioral signature of malicious persistence. A legitimate application writing to its own Run key would show a direct executable path, not an encoded command.

The analyst who sees this record in the Sysmon log during triage knows immediately: this is persistence by a scripting engine, targeting a logon-triggered Run key, with an obfuscated payload. The CHAIN-ENDPOINT investigation should now focus on what the encoded command does and which parent process launched the PowerShell that created this entry.

Now look at the same persistence through the lens of Windows Security Event ID 7045, which captures new service installations:

Log Name:      System
Source:        Service Control Manager
Event ID:      7045
Level:         Information
Computer:      DESKTOP-NGE042.northgate.local
Description:
  A service was installed in the system.
  Service Name:  WindowsUpdateSvc
  Service File Name: C:\ProgramData\Microsoft\Crypto\RSA\svchost.dll
  Service Type:  user mode service
  Service Start Type: auto start
  Service Account: LocalSystem

Two red flags are visible in the raw evidence before any query runs. The service name "WindowsUpdateSvc" mimics a legitimate Windows service but is not a real Windows component — Windows Update runs through the wuauserv service, not "WindowsUpdateSvc." The Service File Name points to C:\ProgramData\Microsoft\Crypto\RSA\ — a directory that legitimately exists for certificate storage but should not contain service DLLs. The service runs as LocalSystem with auto start, meaning it executes as SYSTEM at every boot. An investigator who recognizes these patterns in the raw Event Log can make a triage decision before running a single query. This is the evidence-first approach — read the record, interpret the anomalies, then query for scope and correlation.

Detecting registry persistence at scale

The raw Event Log records show individual persistence events on individual endpoints. KQL in Advanced Hunting or Sentinel detects these patterns across the entire fleet.

// Registry persistence — Run key modifications by suspicious processes
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has "CurrentVersion\\Run"
| where ActionType == "RegistryValueSet"
| where InitiatingProcessFileName in~ ("powershell.exe", "cmd.exe",
    "mshta.exe", "wscript.exe", "cscript.exe", "rundll32.exe")
| project Timestamp, DeviceName, RegistryKey, RegistryValueName,
    RegistryValueData, InitiatingProcessFileName,
    InitiatingProcessCommandLine
| sort by Timestamp desc

This query implements the detection strategy for the raw evidence you just read: filter for the specific high-value keys (Run), filter for the suspicious modifying processes (scripting engines, LOLBins), and project the fields the analyst needs for triage — the key, the value data, and the process context. On a clean fleet, this query returns zero results. Every result is either a legitimate automation script that should be documented and excluded or an actual persistence attempt that requires investigation.

The detection philosophy applies across all registry persistence locations, not just Run keys. Replace CurrentVersion\\Run with CurrentControlSet\\Services to detect suspicious service creation. Replace it with Image File Execution Options to detect IFEO debugger manipulation. The filter logic is the same: which processes modified which high-value keys. The modifying process is what separates malicious from legitimate — an installer writing to Services is expected. PowerShell writing to Services is suspicious. Mshta writing to Services is almost certainly malicious.

The critical insight is that the KQL query targets the same evidence you read in the Sysmon Event Log — the same registry key, the same process context, the same value data. The difference is scope: the Event Log record shows one event on one endpoint during live triage. The KQL query shows all matching events across all endpoints over seven days. The evidence teaches you what to look for. The query operationalizes that knowledge at fleet scale. Module ES8 builds the complete set of registry persistence detection rules using this same pattern — evidence first, then KQL at scale.

WMI subscriptions and LSA authentication packages

Two registry-adjacent persistence mechanisms deserve specific attention because they are both stealthier and higher-privilege than Run keys.

WMI event subscriptions create a permanent event consumer that executes code when a specified event occurs — typically at system startup or at a scheduled time. The subscription survives reboots and runs in the WMI provider host process (WmiPrvSE.exe), making it harder to attribute to the original attacker process. The WMI subscription consists of three components stored in the WMI repository (not the registry directly, though WMI uses registry-backed storage): an event filter that defines the trigger condition, an event consumer that defines the action (execute a command, run a script), and a binding that connects the filter to the consumer. All three must be present for the subscription to function.

Sysmon Event IDs 19 (WmiEventFilter activity detected), 20 (WmiEventConsumer activity detected), and 21 (WmiEventConsumerToFilter activity detected) capture WMI subscription creation with full detail — the filter query, the consumer command, and the binding. Without Sysmon, WMI subscriptions are nearly invisible to standard Windows logging. The ASR rule "Block persistence through WMI event subscription" blocks this technique directly when enabled in block mode. At NE, neither the Sysmon monitoring nor the ASR rule is configured — WMI persistence is both invisible and unblocked. This is one of the stealthiest persistence mechanisms available because the attacker creates the subscription once, and it triggers independently at every boot without any visible process creation or registry modification in the standard event logs.

LSA authentication packages are the highest-privilege registry persistence mechanism available. The keys HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages and HKLM\...\Lsa\Security Packages specify DLLs that LSASS loads at boot. An attacker who adds a malicious DLL to these keys achieves code execution inside the LSASS process itself — SYSTEM privilege, loaded before any EDR user-mode components initialize, with direct access to credential material in memory. This technique is rare in commodity attacks because it requires administrator access and knowledge of LSASS internals, but it appears in nation-state operations where persistence within the authentication subsystem is specifically targeted. Any modification to LSA authentication package registry keys should trigger a high-severity alert with immediate investigation — there is no legitimate reason for these keys to change outside of operating system updates or security product installations, both of which follow predictable patterns that can be excluded.

=== HKCU Run ===
SecurityHealthSystray : C:\Windows\System32\SecurityHealthSystray.exe
OneDrive              : "C:\Program Files\Microsoft OneDrive\OneDrive.exe" /background
WindowsUpdate         : powershell.exe -w hidden -enc JABjAD0ATgBlAHcALQ...
=== HKLM Run ===
SecurityHealth        : %windir%\system32\SecurityHealthSystray.exe
=== Non-standard service paths ===
PSChildName          ImagePath                                   Start
-----------          ---------                                   -----
WindowsUpdateSvc     C:\ProgramData\Microsoft\Crypto\RSA\svc..      2
=== IFEO Debugger entries ===
(none found)

This is the output the analyst sees when running the persistence enumeration script from the endpoint's PowerShell console during live triage. Two anomalies are immediately visible: the HKCU Run key "WindowsUpdate" contains an encoded PowerShell command instead of a direct executable path, and the service "WindowsUpdateSvc" has an ImagePath outside of standard system directories. On a clean endpoint, Run keys contain only legitimate application paths and no services point to ProgramData directories. The CLI Output gives the analyst the local triage view. The Event Log records give the forensic detail. The KQL query gives the fleet-wide scope. Three views of the same persistence — each at a different operational level.