Autoelevate parent spawned shell
An auto-elevating Windows binary is the PARENT of an interpreter or proxy-execution host.
What it detects
An auto-elevating Windows binary is the PARENT of an interpreter or proxy-execution host. These binaries are manifested autoElevate=true, so they reach high integrity without a consent prompt; none of them has any business launching a shell. When one does, it is because its handler lookup was hijacked and the shell inherited the elevated token.
This is the completion half of the UAC bypass that windows.privilege_escalation.uac_bypass_shell_open_hijack catches at setup. Either can fire alone — the registry write may predate log collection, and Sysmon registry events are frequently not collected at all — so both exist deliberately.
MITRE ATT&CK mapping
- T1548.002Abuse Elevation Control Mechanism: Bypass User Account Control· Privilege Escalation
False positives and triage
control.exe and cliconfg.exe are the two entries with plausible benign paths — an administrator opening a Control Panel applet that shells out, or legacy SQL client configuration. Both are rare and interactive.
To confirm: check the child's command line. A bypass child is usually a bare cmd.exe/powershell.exe with no arguments (the operator wanted a shell) or one pointing at a payload under a user-writable directory. Then check whether the parent itself was started by something unusual — a bypass tool launches the auto-elevating binary programmatically, so its own parent is often a script host or a binary in \Users\, not explorer.exe.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/windows/autoelevate_parent_spawned_shell.yaml, licensed under the Apache License 2.0.
id: windows.privilege_escalation.autoelevate_parent_spawned_shell
version: 1.0.0
status: stable
severity: high
confidence: 0.75
platforms: [windows]
mitre_techniques: [T1548.002]
description: |
An auto-elevating Windows binary is the PARENT of an interpreter or proxy-execution
host. These binaries are manifested `autoElevate=true`, so they reach high integrity
without a consent prompt; none of them has any business launching a shell. When one
does, it is because its handler lookup was hijacked and the shell inherited the
elevated token.
This is the completion half of the UAC bypass that
`windows.privilege_escalation.uac_bypass_shell_open_hijack` catches at setup. Either
can fire alone — the registry write may predate log collection, and Sysmon registry
events are frequently not collected at all — so both exist deliberately.
match:
event_category: process
parent_process_name_any:
- fodhelper.exe
- computerdefaults.exe
- eventvwr.exe
- sdclt.exe
- wsreset.exe
- slui.exe
- dccw.exe
- cmstp.exe
- cliconfg.exe
- mcx2prov.exe
- migwiz.exe
- sysprep.exe
- changepk.exe
- dcomcnfg.exe
- pkgmgr.exe
- winsat.exe
- easinvoker.exe
- isoburn.exe
- recdisc.exe
- control.exe
process_name_any:
- cmd.exe
- powershell.exe
- pwsh.exe
- wscript.exe
- cscript.exe
- mshta.exe
- rundll32.exe
- regsvr32.exe
correlation_keys: [hostname, user_name]
false_positive_guidance: |
`control.exe` and `cliconfg.exe` are the two entries with plausible benign paths —
an administrator opening a Control Panel applet that shells out, or legacy SQL
client configuration. Both are rare and interactive.
To confirm: check the child's command line. A bypass child is usually a bare
`cmd.exe`/`powershell.exe` with no arguments (the operator wanted a shell) or one
pointing at a payload under a user-writable directory. Then check whether the
parent itself was started by something unusual — a bypass tool launches the
auto-elevating binary programmatically, so its own parent is often a script host
or a binary in `\Users\`, not `explorer.exe`.
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.