Catching Fodhelper UAC Bypasses: Mechanics and Telemetry Engineering

Windows User Account Control was never engineered as a hard security boundary, yet security operations teams routinely treat a UAC prompt as if it were an immutable wall. When an administrative user logs into an interactive session, Windows issues two tokens: a filtered Medium Integrity Level (MIL) token for standard tasks and an unfiltered High Integrity Level (HIL) token held in reserve. The entire UAC bypass landscape exists because Microsoft built mechanisms into the OS to elevate privileges seamlessly without spamming the user with consent prompts for routine system administration.

The fodhelper.exe (Features on Demand Helper) technique remains a classic example of this design trade-off. While Endpoint Detection and Response (EDR) platforms frequently catch generic implementations using static signature matches on command lines, the underlying mechanism—a registry hijack on an auto-elevating binary—succeeds because the underlying operating system behavior is fundamentally working as designed.

The Auto-Elevation Architecture and HKCU Trust Abuse

To understand why fodhelper.exe elevates without prompting, you have to look at its application manifest. Embedded inside binaries located in C:\Windows\System32\, the application manifest specifies execution requirements. Binaries configured with <autoElevate>true</autoElevate> that are digitally signed by the Windows Publisher Certificate will automatically acquire the user’s High Integrity token upon launch, provided the local UAC setting is set to the default level or lower.

When fodhelper.exe executes at High Integrity, it attempts to launch the Windows 10/11 Settings application to manage optional system features. Rather than directly calling a hardcoded executable path like SystemSettings.exe, fodhelper delegates the invocation to the Windows Shell via a Uniform Resource Identifier (URI) scheme: ms-settings:.

The vulnerability lies in how the Windows Shell resolves URI scheme handlers. When an application queries the registry for protocol association, Windows searches two primary hives in a specific order:

1. HKEY_CURRENT_USER\Software\Classes\ (HKCU)
2. HKEY_LOCAL_MACHINE\Software\Classes\ (HKLM)

Because HKEY_CURRENT_USER is fully writable by the current user’s Medium Integrity process, a low-privileged context can inject arbitrary protocol handlers into HKCU. When fodhelper.exe launches at High Integrity and executes the ms-settings protocol, Windows checks HKCU first, finds the modified user-defined handler, and executes the specified command inside the High Integrity context inherited from fodhelper.exe.

Deconstructing the Fodhelper Registry Query Path

The mechanics of this hijack depend on two specific registry values under the protocol’s shell command structure. Under normal operating conditions, the ms-settings protocol is defined exclusively in HKLM\Software\Classes\ms-settings.

When an attacker redirects this control flow, they create the following key path inside the user’s hive:

HKCU\Software\Classes\ms-settings\Shell\open\command

Two distinct registry values within this key control the execution path:

• Default Value (Default): Holds the string containing the command to execute (e.g., cmd.exe /c start ... or a path to a payload).
• DelegateExecute: A string value used by Component Object Model (COM) class objects to handle shell execution.

If DelegateExecute is absent, Windows attempts to instantiate a COM object defined by the system defaults, which breaks the custom command redirection. By simply creating an empty DelegateExecute string value in HKCU, the execution handler bypasses the COM lookup entirely and forces the shell to execute whatever string is placed inside the (Default) key.

Because fodhelper.exe was launched by an administrative account (operating under the filtered Medium Integrity token), the spawned process inside the hijacked (Default) key inherits High Integrity execution rights. The process elevated from Medium to High Integrity without triggering a Consent UI prompt (consent.exe).

Constructing Robust Telemetry for Custom Protocol Hijacks

Relying solely on process creation telemetry (Event ID 4688 or Sysmon Event ID 1) creates a massive blind spot. An attacker can obfuscate the binary spawned by fodhelper.exe, call indirect execution commands, or clear the registry keys immediately after execution to prevent forensic recovery.

To reliably catch this technique, detection engineering must focus on the state change in the registry prior to the invocation of fodhelper.exe.

Standard Windows Event Logs do not monitor HKCU write operations by default. To capture these modifications, you must enforce explicit Registry Auditing via System Access Control Lists (SACLs) or deploy Sysmon registry monitoring rules.

In Sysmon, catching protocol hijacks requires monitoring both key creation (Event ID 12 / Event ID 14) and value setting (Event ID 13). The telemetry must explicitly target custom protocol additions under Software\Classes\.

Here is a focused Sysmon configuration snippet designed to capture ms-settings modifications and similar auto-elevation protocol hijacks:

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <RuleGroup level="include" operator="or">
      <RegistryEvent onmatch="include">
        <!-- Detect modification to ms-settings protocol handler -->
        <TargetObject condition="contains">\Software\Classes\ms-settings\shell\open\command</TargetObject>
        <!-- Detect modification to similar auto-elevating URI handlers -->
        <TargetObject condition="contains">\Software\Classes\ms-shellautolist\shell\open\command</TargetObject>
        <TargetObject condition="contains">\Software\Classes\ms-appinstaller\shell\open\command</TargetObject>
      </RegistryEvent>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

When this telemetry is ingested into a SIEM or EDR pipeline, an alert should trigger whenever a non-elevated process writes to \Software\Classes\*\shell\open\command, particularly when setting the DelegateExecute value.

Bypassing EDR Silence with Behavioral Registry Rules

Commercial EDR signatures often trigger on known process trees, such as fodhelper.exe spawning cmd.exe or powershell.exe. Adversaries circumvent these naive parent-child signatures by spawning secondary, benign binaries that host unmanaged code or by using alternative auto-elevating binaries such as computerdefaults.exe or slui.exe.

A resilient behavioral rule ignores the child process completely and focuses on three deterministic conditions:

1. Registry Write Event: A process running at Medium Integrity writes a value to HKCU\Software\Classes\ms-settings\shell\open\command.
2. Process Launch Event: fodhelper.exe is executed within a tight temporal window (e.g., less than 5 seconds) following the registry write.
3. Integrity Level Mismatch: The process spawned by fodhelper.exe does not match the standard Windows binary C:\Windows\ImmersiveControlPanel\SystemSettings.exe.

To implement this in Sigma format for broad SIEM deployment:

title: UAC Bypass Via Fodhelper Registry Hijack
id: a0187621-1337-4110-8910-123456789abc
status: stable
description: Detects registry modifications to the ms-settings protocol handler followed by auto-elevation binary execution.
logsource:
  category: registry_set
  product: windows
detection:
  selection_key:
    TargetObject|contains: '\Software\Classes\ms-settings\shell\open\command'
  selection_value:
    TargetObject|endswith: '\DelegateExecute'
  condition: selection_key or selection_value
falsepositives:
  - Rare custom management software modifying user protocol associations (requires verification).
level: high

If your threat model demands total mitigation rather than passive detection, consider setting the UAC policy User Account Control: Behavior of the elevation prompt for administrators in Auto Approve mode to Prompt for credentials or Prompt for consent on the secure desktop. This disables binary auto-elevation across the entire OS, effectively neutralizing fodhelper and all related manifest-based UAC bypass vectors in one stroke.