ES1.3 Windows Registry as an Attack Surface

· Module 1 · Free

Operational Objective

The Windows registry is the operating system's configuration database — and one of the most versatile persistence surfaces available to an attacker. Run keys that execute programs at logon, service entries that start processes at boot, COM object registrations that hijack legitimate application loading, scheduled task configurations, AppInit_DLLs that inject into every user-mode process, Image File Execution Options that redirect process execution — the registry provides dozens of persistence locations, many of which are rarely monitored by default security configurations. Understanding the registry as an attack surface means knowing which keys attackers modify, which modifications are legitimate vs malicious, and which monitoring controls (Sysmon, MDE, ASR) detect each type of modification.

Deliverable: A registry persistence location reference mapping the most commonly abused registry keys to MITRE ATT&CK persistence techniques, with corresponding Sysmon event IDs and MDE table references for detection.

Estimated completion: 30 minutes

Figure ES1.3 — The eight most commonly abused registry persistence locations. Each location has a corresponding MITRE ATT&CK technique ID and detection mechanism. Sysmon Event IDs 12 (RegistryEvent Object created/deleted) and 13 (RegistryEvent Value set) are the primary detection sources for registry-based persistence.

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 (registry hives are stored on disk), it is complex (thousands of keys and values, making manual inspection impractical), and most registry modifications are legitimate (software installation, configuration changes, Windows updates all write to the registry constantly). The attacker’s modification hides in the noise of legitimate registry activity.

The critical distinction for detection: WHICH keys are modified matters more than THAT a modification occurred. 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\Software\Microsoft\Windows\CurrentVersion\Run (executes at user logon) or HKLM\Software\Microsoft\Windows\CurrentVersion\Run (executes at system boot for all users). The value contains the path to the malicious executable or a command line (powershell.exe -enc …). Detection: Sysmon Event ID 13 captures the value set with the full path and data. MDE DeviceRegistryEvents captures the same. The detection query filters on the specific Run key paths and evaluates the value data — encoded PowerShell, paths to unusual locations (%TEMP%, %APPDATA%), or paths containing obfuscated filenames are strong indicators.

Services provide SYSTEM-level persistence. The attacker creates a service (or modifies an existing one) by writing to HKLM\SYSTEM\CurrentControlSet\Services\{ServiceName}. The ImagePath value contains the executable path. The Start value determines when the service starts (2 = automatic at boot, 3 = manual, 4 = disabled). A new service with Start=2 and an ImagePath pointing to an unusual location is a strong persistence indicator. Detection: Windows Event ID 7045 (new service installed) and Sysmon Event ID 12/13 for the registry modification.

Expand for Deeper Context

COM hijacking is a more sophisticated technique. 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 to find the DLL that implements it. The lookup order is: HKCU\Software\Classes\CLSID\{GUID} first, then HKLM\Software\Classes\CLSID\{GUID}. An attacker can create a HKCU entry for a COM object that is normally registered only in HKLM — the HKCU entry takes precedence, and the attacker’s DLL is loaded instead of (or in addition to) the legitimate DLL. The DLL executes within the context of the application that loads the COM object.

This technique is stealthy because: the legitimate COM object still functions (the attacker’s DLL can proxy calls to the legitimate DLL), the persistence is triggered by normal application usage (any application that loads the hijacked COM object), and the registry key name is a GUID that does not obviously indicate malicious intent. Detection requires comparing HKCU COM registrations against HKLM registrations and identifying HKCU entries that shadow HKLM entries — a task that Sysmon Event ID 12/13 combined with baseline analysis can accomplish.

Image File Execution Options (IFEO) provide process-level redirection. The key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\{executable.exe}\Debugger causes Windows to launch the specified “debugger” instead of (or before) the target executable. An attacker who sets Debugger = cmd.exe /c malicious.exe && target.exe causes malicious.exe to execute every time the target executable is launched. This can also be used to set SilentProcessExit monitoring that triggers a payload when a specific process exits. Detection: any modification to IFEO keys should be treated as suspicious outside of legitimate debugging scenarios.

What MDE and Sysmon capture for registry detection

MDE’s DeviceRegistryEvents table captures registry modifications with: the timestamp, the device name, the registry key path, the registry value name, the value data, the action type (RegistryValueSet, RegistryKeyCreated), and the process that made the modification (InitiatingProcessFileName). This provides the “who changed what” context that raw event logs do not.

Sysmon provides more granular registry monitoring through three event types: Event ID 12 (RegistryEvent — Object create or delete), Event ID 13 (RegistryEvent — Value Set), and Event ID 14 (RegistryEvent — Key and Value Rename). Sysmon configurations (like the SwiftOnSecurity baseline) filter these events to capture only modifications to security-relevant keys — reducing the volume from millions of events per day to thousands of actionable events.

The detection strategy: monitor a defined list of persistence-relevant registry keys for modifications by unexpected processes. A modification to a Run key by explorer.exe (user adding a startup program through the UI) is normal. A modification to a Run key by powershell.exe (script adding a startup entry) warrants investigation. A modification to a Run key by mshta.exe (HTA application adding persistence) is almost certainly malicious.

Decision Point

Your Sysmon configuration captures all registry modifications to the Run keys, Services keys, and COM registration keys. The daily event volume is 15,000 events. Most are legitimate software installations and Windows updates. Do you (A) build a detection rule that alerts on every modification to these keys, or (B) build a detection rule that filters to modifications by specific suspicious parent processes? Option B. An unfiltered alert on 15,000 daily events creates immediate alert fatigue and the rule will be ignored or disabled within a week. The effective detection filters on: the modifying process (PowerShell, cmd, mshta, wscript, cscript, rundll32), the value data pattern (encoded commands, paths to temp directories, obfuscated filenames), and the timing (modifications outside business hours, modifications immediately following a process creation from a suspicious parent chain). The goal is 5-15 actionable alerts per day, not 15,000.

Try it: enumerate persistence locations on your endpoint

Run this PowerShell to check the most common persistence locations:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# Run keys (user and machine)
"=== HKCU Run ===" 
Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -ErrorAction SilentlyContinue | Format-List
"=== HKLM Run ==="
Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -ErrorAction SilentlyContinue | Format-List

# Services with unusual ImagePath (non-system32)
"=== Non-standard service paths ==="
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\*" -ErrorAction SilentlyContinue | 
    Where-Object { $_.ImagePath -and $_.ImagePath -notmatch "system32|syswow64|windows" } |
    Select-Object PSChildName, ImagePath, Start | Format-Table -AutoSize

# IFEO entries with Debugger key
"=== IFEO Debugger entries ==="
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" -ErrorAction SilentlyContinue |
    ForEach-Object { Get-ItemProperty $_.PSPath -Name "Debugger" -ErrorAction SilentlyContinue } |
    Where-Object { $_.Debugger } | Select-Object PSChildName, Debugger

Any unexpected entries in Run keys, services with paths outside of system directories, or IFEO Debugger entries warrant investigation. On a clean system, Run keys contain only legitimate startup applications, all services point to system32 or known application directories, and IFEO has no Debugger entries.

Registry persistence: what investigators look for

The registry is the most common persistence mechanism on Windows endpoints because it requires no file drops, no service installation, and no scheduled task creation — just a single registry value that causes code to execute at logon or system startup. The four registry locations that investigators check first during triage:

HKCU and HKLM Run keys (SOFTWARE\Microsoft\Windows\CurrentVersion\Run and RunOnce): values in these keys execute automatically when the user logs in (HKCU) or when any user logs in (HKLM). An attacker who writes a value pointing to their payload ensures execution survives a reboot. MDE captures this through DeviceRegistryEvents, and the custom detection NE-PERS-001 from ES8.6 alerts on run key modifications by unexpected processes.

Services (HKLM\SYSTEM\CurrentControlSet\Services): each Windows service has a registry key with an ImagePath value pointing to the service binary. An attacker who creates a new service (or modifies an existing service’s ImagePath) gains execution as SYSTEM at every boot. Sysmon Event ID 13 captures service-related registry modifications with the process context that DeviceRegistryEvents may not include.

COM object hijacking (HKCU\Software\Classes\CLSID): COM objects are loaded by applications that call CoCreateInstance with a specific CLSID. If an attacker creates a CLSID entry in HKCU that points to their malicious DLL, the DLL is loaded whenever any application creates that COM object. This persistence method is particularly stealthy because HKCU COM entries override HKLM entries — the attacker hijacks an existing COM object without modifying any system-wide configuration.

Image File Execution Options (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options): IFEO entries can specify a debugger for any executable. An attacker who sets the Debugger value for a commonly used application (e.g., notepad.exe) causes their payload to execute every time that application launches. This is a less common persistence method but difficult to detect without specific registry monitoring.

Compliance Myth: "Registry monitoring is too noisy to be useful — it generates too many false positives"

The myth: The registry is modified millions of times per day on an active endpoint. Monitoring it is impractical because the volume drowns out the malicious modifications.

The reality: Monitoring ALL registry modifications is impractical and unnecessary. Monitoring SPECIFIC high-value keys — Run keys, Services, COM registrations, IFEO, LSA authentication packages, WMI subscriptions — is both practical and high-value. The SwiftOnSecurity Sysmon configuration monitors approximately 50 specific registry paths that cover 95% of registry-based persistence techniques. On a typical endpoint, this generates 50-200 events per day — a manageable volume that can be filtered further by process context. The “too noisy” objection applies to unfiltered registry monitoring. Targeted monitoring of persistence-relevant keys is one of the highest-fidelity detection sources available.

Troubleshooting

“Our Sysmon configuration is generating thousands of registry events for Windows Update.” Windows Update modifies many registry keys during the update process. The SwiftOnSecurity Sysmon baseline includes exclusions for known Windows Update processes (wuauclt.exe, TiWorker.exe, TrustedInstaller.exe). If these exclusions are not in your Sysmon config, add them. The goal is to exclude known-good high-volume processes while retaining visibility on all other processes that modify persistence-relevant keys.

“MDE’s DeviceRegistryEvents table shows modifications but does not include the value data for some events.” MDE selectively captures registry value data based on the key’s security relevance and the data size. For high-value keys (Run, Services), value data is typically included. For some keys, only the key path and action type are recorded. If you need guaranteed value data capture, Sysmon Event ID 13 captures the full value data for all configured keys. Use both sources: MDE for broad coverage and Sysmon for detailed forensic evidence.

Operational Artifact — Registry Persistence Detection Reference

Priority 1 (monitor in all environments): HKCU and HKLM Run/RunOnce keys, Services with new ImagePath or ServiceDLL, IFEO Debugger values, LSA Authentication Packages, LSA Security Packages. Priority 2 (monitor in high-security environments): COM CLSID registrations in HKCU that shadow HKLM entries, AppInit_DLLs, WMI event subscription bindings (Sysmon 19/20/21), Scheduled Task registry entries. Detection context: Alert on modifications by: script interpreters (PowerShell, cmd, wscript, cscript, mshta), LOLBins (rundll32, regsvr32, certutil), unsigned executables, or processes spawned from suspicious parent chains. Exclude: known installer processes, Windows Update, Intune management agent. Sysmon events: 12 (key create/delete), 13 (value set), 14 (key/value rename). MDE table: DeviceRegistryEvents — ActionType: RegistryValueSet, RegistryKeyCreated.

Sysmon Event ID 13 shows a new value created at `HKCU\Software\Classes\CLSID\{BDB57FF2-79B9-4205-9447-F5FE85F37312}\InprocServer32` with value data pointing to `C:\Users\j.morrison\AppData\Local\Temp\msedge_update.dll`. What persistence technique is this, and why is the HKCU location significant?

This is a Run key modification — the CLSID path is an alternative location for startup programs. The HKCU location means it affects only this user's logon.

This is COM hijacking (T1546.015). The attacker created a HKCU COM registration that shadows a legitimate COM object in HKLM. When any application loads the COM object with this CLSID, Windows checks HKCU first (per the COM resolution order) and loads the attacker's DLL from the Temp directory instead of the legitimate DLL from system32. The HKCU location is significant because: (1) it does not require administrator privileges to create — any standard user can write to HKCU, (2) it takes precedence over the legitimate HKLM registration, and (3) the DLL name "msedge_update.dll" is designed to appear legitimate while the Temp directory location is the red flag. Detection: compare HKCU CLSID registrations against HKLM to identify shadow entries. Alert on any InprocServer32 pointing to %TEMP% or %APPDATA%.

This is a legitimate Microsoft Edge update component that registers COM objects during the update process. The Temp directory is used for staged updates.

This is an IFEO debugger redirect — the CLSID entry causes the COM object to launch a debugger instead of the intended DLL.

You're reading the free modules of this course

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus

← Previous Next →