UAC bypass shell open hijack
A per-user registry hijack of a shell "open" handler that an auto-elevating Windows binary consults.
What it detects
A per-user registry hijack of a shell "open" handler that an auto-elevating Windows binary consults. The user hive is writable without elevation, but the binary that reads it runs elevated and does not prompt — so whatever command is planted here executes with high integrity. This is the mechanism behind most UAC bypasses in the wild (fodhelper, eventvwr, sdclt, computerdefaults, WSReset).
The handlers below have no legitimate reason to carry a per-user open command: ms-settings and mscfile are consulted only by auto-elevating system tools, and an empty DelegateExecute value exists specifically to force the shell down the hijacked path rather than the COM one.
Detected on the registry write itself, so it fires on the setup step — before the elevated child process exists. It matches Sysmon key-create/delete (12) and value-set (13) alike, because the cleanup deletion is as good evidence as the write.
MITRE ATT&CK mapping
- T1548.002Abuse Elevation Control Mechanism: Bypass User Account Control· Privilege Escalation
False positives and triage
Very low volume on a normal endpoint. The legitimate near-miss is an installer registering a per-user file association, but those write an extension or ProgID key, not ms-settings, mscfile, or a bare DelegateExecute.
To confirm: read the Details= value in the event — it is the command that would have run elevated. A path under \Users\, \Temp\, or \ProgramData\, or a bare cmd.exe/powershell.exe, is the finding. Then look for a process created within seconds whose parent is the matching auto-elevating binary; that pair is the bypass completing. A write with no such child may be a tool that was blocked.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 85%. Source: rules/windows/uac_bypass_shell_open_hijack.yaml, licensed under the Apache License 2.0.
id: windows.privilege_escalation.uac_bypass_shell_open_hijack
version: 1.0.0
status: stable
severity: high
confidence: 0.85
platforms: [windows]
mitre_techniques: [T1548.002]
description: |
A per-user registry hijack of a shell "open" handler that an auto-elevating
Windows binary consults. The user hive is writable without elevation, but the
binary that reads it runs elevated and does not prompt — so whatever command is
planted here executes with high integrity. This is the mechanism behind most
UAC bypasses in the wild (fodhelper, eventvwr, sdclt, computerdefaults, WSReset).
The handlers below have no legitimate reason to carry a per-user open command:
`ms-settings` and `mscfile` are consulted only by auto-elevating system tools,
and an empty `DelegateExecute` value exists specifically to force the shell down
the hijacked path rather than the COM one.
Detected on the registry write itself, so it fires on the setup step — before the
elevated child process exists. It matches Sysmon key-create/delete (12) and
value-set (13) alike, because the cleanup deletion is as good evidence as the
write.
match:
registry_path_contains_any:
- 'ms-settings\shell\open\command'
- 'mscfile\shell\open\command'
- 'Folder\shell\open\command'
- 'AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\shell\open\command'
- '\shell\open\command\DelegateExecute'
correlation_keys: [hostname, user_name]
false_positive_guidance: |
Very low volume on a normal endpoint. The legitimate near-miss is an installer
registering a per-user file association, but those write an extension or ProgID
key, not `ms-settings`, `mscfile`, or a bare `DelegateExecute`.
To confirm: read the `Details=` value in the event — it is the command that would
have run elevated. A path under `\Users\`, `\Temp\`, or `\ProgramData\`, or a
bare `cmd.exe`/`powershell.exe`, is the finding. Then look for a process created
within seconds whose parent is the matching auto-elevating binary; that pair is
the bypass completing. A write with no such child may be a tool that was blocked.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.