UAC Bypass via Auto-Elevated Binaries: How Attackers Skip the Consent Prompt

User Account Consent (UAC) is the most misunderstood security boundary in Windows. Most admins treat that yellow shield prompt as a wall between a standard-token process and full administrator rights. Microsoft has been explicit for over a decade that it is not a security boundary in its default configuration — and the gap between how UAC is perceived and how it actually behaves is exactly where attackers live. If your operators are already local admins (as most developers and IT staff are), a UAC bypass turns a click-to-run payload into a fully elevated one with no prompt at all.

Why UAC bypasses exist: the auto-elevate list

When a member of the Administrators group logs in, they get two tokens: a filtered standard-user token for everyday work, and a full admin token that is only unsealed when something elevates. To keep the OS usable, Microsoft ships a set of trusted, Microsoft-signed system binaries that auto-elevate — they jump straight to the full token without a prompt — as long as two conditions hold:

• The binary is Authenticode-signed by Microsoft and marked autoElevate=true in its embedded manifest.
• It runs from a trusted directory, primarily C:\Windows\System32.

Examples include fodhelper.exe, computerdefaults.exe, sdclt.exe, eventvwr.exe, and slui.exe. Each was designed to elevate silently for legitimate reasons. The problem: several of them read attacker-controllable inputs — a registry key, an environment variable, or a search path — after they have already elevated. Redirect that input and you inherit the elevation.

The fodhelper pattern

The canonical example is fodhelper.exe. It launches a settings pane by resolving a protocol handler through the current user's registry hive (HKCU), which a standard token can write. An attacker plants a fake handler, then launches the auto-elevating binary, which dutifully executes the planted command as administrator:

reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /d "cmd.exe /c payload.exe" /f
reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /v DelegateExecute /f
start fodhelper.exe

No prompt, no dropped file in a protected path, no admin password. The same class of trick drives eventvwr.exe (mscfile handler), sdclt.exe, and computerdefaults.exe. Because the launching process is a legitimate signed Microsoft binary, naive allowlists and signature-only EDR rules wave it right through.

Mock trusted directories

The second technique attacks the trusted directory check. Some elevation logic compares the path case-insensitively but sloppily, so a directory like C:\Windows \System32\ (note the trailing space after Windows) can masquerade as the real System32. An attacker creates that pseudo-directory via the native NT path API (Explorer refuses trailing spaces, but CreateDirectory with a \\?\ prefix does not), copies a legitimate auto-elevating binary plus a malicious DLL beside it, and lets DLL search-order hijacking load the payload into an elevated process. It is a UAC bypass and a DLL-hijack rolled into one.

What to audit and harden

You cannot patch UAC into a real boundary, but you can raise the cost dramatically:

1. Set UAC to "Always notify." The registry value ConsentPromptBehaviorAdmin under HKLM\...\Policies\System should be 2, and PromptOnSecureDesktop should be 1. Always-notify neuters the auto-elevate list because every elevation prompts on the secure desktop.
2. Hunt for HKCU handler hijacks. Watch HKCU\Software\Classes\ms-settings, mscfile, exefile, and Folder\shell\open\command for writes — a standard user has no legitimate reason to define these.
3. Flag suspicious parent-child lineage. fodhelper.exe or computerdefaults.exe spawning cmd.exe, powershell.exe, or rundll32.exe is a near-certain bypass.
4. Detect mock directories. Any path with a trailing space or a Unicode look-alike near System32 is malicious by construction.
5. Reduce standing admin. If day-to-day accounts are standard users, a UAC bypass has nothing to inherit.

Where WinSentinel fits

WinSentinel audits the exact settings this attack depends on. On any single machine — free, with all modules and no limits — it checks your UAC consent policy, secure-desktop enforcement, and standing local-admin membership, and flags HKCU handler hijacks and mock-trusted-directory artifacts as findings mapped to MITRE ATT&CK T1548.002 (Bypass User Account Control). Instead of a raw event stream you have to interpret, you get a scored finding that tells you the machine trusts ConsentPromptBehaviorAdmin=5 when it should be 2, and the one-line fix.

For organizations, WinSentinel Pro rolls those per-machine findings up across the fleet: a central node shows which endpoints still run in the weakened "elevate without prompting" mode, alerts on configuration drift when someone loosens UAC, and turns "are we exposed to auto-elevate bypasses?" from a per-box investigation into a single compliance view.

UAC was never the wall. Treat every local admin as a click away from full elevation, and audit the settings that decide whether that click is silent.

Auto-elevated binaries are a feature, not a bug — which is why they will keep shipping. The defensible posture is to assume the bypass exists, remove the standing privilege it feeds on, and continuously verify that the handful of registry values standing between a prompt and silent SYSTEM are set the way you think they are.