Registry write to a known UAC bypass hijack key

Siemphony@siemphonyhighT1548+1verified in lab

Matches registry writes to the per-user keys an auto-elevating binary reads when it is hijacked: the shell-open command classes used by the fodhelper, eventvwr, sdclt and computerdefaults family (ms-settings, mscfile, exefile runas, Folder and the AppX class the store handler uses), plus the Environment windir value that the SilentCleanup scheduled task expands. AN0975's other half — "unusual parent-child process relationships" — has no concrete value list at parent-technique level and would be arbitrary, so the rule is built on the registry evidence, which is bounded and specific. Two things a reader has to be told. First, every key here is T1548.002 Bypass User Account Control; the rule is filed under the parent because that is the brief it was authored from, but nothing it matches touches .001 setuid, .003 sudo, .004 elevated prompts, .005 cloud access or .006 TCC, and the tags name .002 for that reason. Second, the class list is illustrative rather than closed — new auto-elevating binaries and their handler classes are found regularly, and a COM elevation-moniker bypass such as ICMLuaUtil writes no registry value at all. The three UAC policy values (EnableLUA, ConsentPromptBehaviorAdmin, LocalAccountTokenFilterPolicy) are deliberately not in the selection. They are applied as Security Settings, which the policy client re-applies on its own refresh interval — 16 hours by default — on every managed host whether or not anything changed, so a UAC baseline GPO produces them per host per cycle forever. ORing that volume into these near-zero-noise keys would make the whole rule unshippable at this level; they belong in a separate low-severity hunt. The correlation MITRE describes, a write followed by an elevated spawn inside a time window, is not expressible in Sigma either way. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0345, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceRegistryEvents| where (RegistryKey contains "\\Software\\Classes\\ms-settings\\shell\\open\\command" or RegistryKey contains "\\Software\\Classes\\mscfile\\shell\\open\\command" or RegistryKey contains "\\Software\\Classes\\Folder\\shell\\open\\command" or RegistryKey contains "\\Software\\Classes\\exefile\\shell\\runas\\command\\isolatedCommand" or RegistryKey contains "\\Software\\Classes\\AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\\Shell\\open\\command" or RegistryKey contains "\\Environment\\windir")

Splunk · SPL

Run this as a search.

index=* (TargetObject="*\\Software\\Classes\\ms-settings\\shell\\open\\command*" OR TargetObject="*\\Software\\Classes\\mscfile\\shell\\open\\command*" OR TargetObject="*\\Software\\Classes\\Folder\\shell\\open\\command*" OR TargetObject="*\\Software\\Classes\\exefile\\shell\\runas\\command\\isolatedCommand*" OR TargetObject="*\\Software\\Classes\\AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\\Shell\\open\\command*" OR TargetObject="*\\Environment\\windir*")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(registry.path) LIKE "*\\\\software\\\\classes\\\\ms-settings\\\\shell\\\\open\\\\command*" OR TO_LOWER(registry.path) LIKE "*\\\\software\\\\classes\\\\mscfile\\\\shell\\\\open\\\\command*" OR TO_LOWER(registry.path) LIKE "*\\\\software\\\\classes\\\\folder\\\\shell\\\\open\\\\command*" OR TO_LOWER(registry.path) LIKE "*\\\\software\\\\classes\\\\exefile\\\\shell\\\\runas\\\\command\\\\isolatedcommand*" OR TO_LOWER(registry.path) LIKE "*\\\\software\\\\classes\\\\appx82a6gwre4fdg3bt635tn5ctqjf8msdd2\\\\shell\\\\open\\\\command*" OR TO_LOWER(registry.path) LIKE "*\\\\environment\\\\windir*")

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,registry_set,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="12">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="TargetObject" type="pcre2">(?i)(\\Software\\Classes\\ms-settings\\shell\\open\\command|\\Software\\Classes\\mscfile\\shell\\open\\command|\\Software\\Classes\\Folder\\shell\\open\\command|\\Software\\Classes\\exefile\\shell\\runas\\command\\isolatedCommand|\\Software\\Classes\\AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\\Shell\\open\\command|\\Environment\\windir)</field>    <description>Registry write to a known UAC bypass hijack key</description>    <mitre>      <id>T1548</id>      <id>T1548.002</id>    </mitre>  </rule></group>

At a glance

Logsource: registry_set / windows
Level: high
Category: privilege_escalation_abuse
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 35087c6f-73b0-4d35-ba7d-45eb9563e746

ATT&CKT1548 +1

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonprivilege escalation abuse

privilege escalation abuse

01 · What this rule detects

Abuse of the mechanisms that legitimately hand out higher privilege, rather than the theft of a more privileged credential. On Windows that is the elevation control itself: auto-elevating binaries coaxed into running attacker-chosen code, and elevated COM objects instantiated to do the same without touching the registry. On Unix it is the setuid bit, the sudoers configuration and the helpers that run as root on request. Exploitation of a kernel or service flaw sits alongside all of it, and is mostly detectable only by its consequences.

02 · Telemetry you need

Sysmon EventID 1 IntegrityLevel, ParentImage and User — the medium-to-high transition inside one process tree is the observable; Security 4688 carries TokenElevationType instead, and needs Audit Process Creation, which is off by default
Sysmon EventID 12 and 13 for writes under HKCU\Software\Classes, including the DelegateExecute value the working bypass variants set — Sysmon records no registry activity at all unless the configuration explicitly includes these paths
Security 4672 (special privileges assigned to new logon) — usually present, but it fires for every service and every administrative logon, so treat it as a correlation input rather than something to alert on
auditd syscall rules for the setuid half: chmod, fchmod and fchmodat setting the setuid or setgid bit, and execution where the effective uid differs from the real uid — none of it is recorded unless the rule is loaded, and audit rules are not persistent unless written into /etc/audit/rules.d
sudo, su, pkexec and polkit logging, which goes to the authpriv syslog facility and lands in /var/log/auth.log or /var/log/secure depending on the distribution — forwarding is a per-distribution rsyslog decision and is frequently not centralised, while sudo's own log_input/log_output are off unless set in sudoers
macOS: process telemetry for /usr/libexec/security_authtrampoline, which is the parent of anything run through the authorisation API, and the unified log entries for the authorisation prompt

03 · How the logic works

The trap that ruins most rules here is generality. 'Any elevation' is unusable: in an estate where users hold local administrator rights, elevation happens many times a day on every host, and a token that goes from medium to high integrity is what installing software looks like. Worse, there is no generic UAC bypass to match — each one is a property of a specific auto-elevating binary or a specific elevated COM object. fodhelper.exe and computerdefaults.exe read a handler under HKCU\Software\Classes\ms-settings, sdclt.exe reads a different handler class, eventvwr.exe reads another again, and the elevated-COM route touches no registry key at all. A rule per mechanism is the only shape that works.

Build each one as two halves. The registry half matches the write to the per-user handler key, ideally including DelegateExecute, and is the more durable of the two because variants reuse the same key. The process half matches the auto-elevating binary spawning any child — for a couple of these binaries the legitimate child list is empty, which makes them near-silent rules and the best in the category. Keep both, because each covers the other's blind spot. Accept that this rule set ages: Microsoft does not treat elevation control as a security boundary, so new usable binaries appear with Windows releases and the list is maintained, not finished.

On Unix, split the setuid work in two as well. Watch the setting of the bit, which is a rare and deliberate act, rather than the existence of setuid binaries, which is a normal system property; then keep the execution-side rule for a binary that already carries the bit. sudo abuse is mostly configuration abuse — a NOPASSWD entry dropped into /etc/sudoers.d, an extended credential cache timeout, or misuse of a command the sudoers file already permits — so the write to the sudoers directory is a far better anchor than any individual sudo invocation, and it does not depend on sudo logging you may not be receiving. Confirm you actually receive that logging before you rely on it: sudo is the classic case where a rule looks quiet because the events never left the host.

Exploitation itself is largely unobservable at the point it happens. Write the consequence instead and label it as inference: a privileged service spawning an unexpected child, a crash in a service immediately followed by a new process from the same tree, an integrity jump with no elevation prompt anywhere near it. One specific case is worth naming — a privileged helper invoked with an empty argument vector is a well-known escalation shape and is cheap to match.

04 · Common false positives

Software installers, updaters and driver packages elevating during installation — every MSI and every browser or vendor updater produces exactly the token transition a broad rule matches
Administrators using 'Run as administrator', runas and elevated consoles, which are indistinguishable from a bypass at the token level and are the bulk of legitimate elevation
Applications registering their own file and protocol handlers under HKCU\Software\Classes\...\shell\open\command — portable applications and 'set as default' flows write the same key shape the bypass rules match
The auto-elevating binaries doing their own job: eventvwr.exe launching mmc.exe and the backup and control-panel binaries launching their own panels are legitimate parent-child pairs that a naive child rule will flag
Linux package installation and upgrade re-applying setuid bits — dpkg and rpm set them on sudo, su, passwd, mount and ping on every relevant update
Configuration management and CI agents running everything through sudo: Ansible's privilege escalation, Puppet, Chef and build runners generate almost the entire sudo volume in most estates

05 · Detection maturity

Tier 1 — starting point: Matches a process running at high integrity, or the name of a known bypass binary, without further conditions.
Tier 2 — tuned: Matches per-mechanism logic — the specific handler key write, or the specific auto-elevating parent with an unexpected child — with installers and administrative tooling excluded by signed path.
Tier 3 — correlated: Correlates the handler write with the elevation that follows it, scores on whether the elevated process was signed and previously seen, and treats the Unix and Windows halves as one behaviour across the estate.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Never exclude on 'elevated' or on administrative accounts — that removes the whole population the rule exists to look at; exclude on the specific parent, the specific signed path and the specific host role
Split the auto-elevating binaries by whether they legitimately spawn children: the ones that never do become near-zero-volume rules and deserve a higher severity than the ones that do
Anchor registry-side rules on the handler key plus DelegateExecute rather than on the executable named in the value, since the value is chosen by the attacker
Prove the Unix telemetry arrives before writing Unix rules: run a benign sudo and a benign chmod +s on one host of each build in the estate and confirm both events reach the SIEM
Prefer the sudoers-write rule over the sudo-invocation rule; it is quieter, it does not depend on distribution logging configuration, and it catches the change rather than its thousandth use
Re-derive the auto-elevating binary and COM object list after each Windows feature update, and record when you last did it — a stale list is the failure mode here, and it fails silently

Declared by the author

Machine-side class registration during operating-system setup, servicing and feature updates. The rule matches on the class path only and does not pin the hive, so the HKLM\SOFTWARE\Classes copies of ms-settings, mscfile and Folder shell-open commands match exactly as the HKCU ones do.
Setup and sysprep writing the machine environment block at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, which contains a windir value and so matches the last entry on every image build and on some servicing reboots.
Shell tweaks and file-association repair tools — alternative file managers, 'open command window here' utilities and portable applications — which rewrite Folder\shell\open\command or the exefile runas verb for the current user.
Control validation and purple-team tooling (Atomic Red Team and similar harnesses) that creates and deletes these exact keys on a schedule to test endpoint coverage.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification5 runs

Verified in Siemphony lab

Security Datasets — UAC bypassed through the fodhelper auto-elevate path
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.
Security Datasets — UAC bypassed through CMSTP profile installation
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.
Security Datasets — UAC bypass
passed
Siemphony IR · 3 Sept 2026
2 true · 0 false · 0.0% noise
Security Datasets — UAC bypass (auto-elevate)
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.
Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1548, T1548.002, evaluated against their registry_set events.

Share this rule

/u/siemphony/35087c6f-73b0-4d35-ba7d-45eb9563e746

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Registry write to a known UAC bypass hijack key

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it