A Sigma rule for registry Run-key persistence catches the most-taught autostart technique on Windows: an attacker writing a value under a Run key so their payload launches at every logon. Sysmon records the write as Event ID 13, and because the malicious value looks nothing like a legitimate autostart entry once you read what it points at, this is a tractable detection. This post writes that logic as Sigma so it converts to KQL or SPL, and covers the autostart locations beyond Run that attackers reach for next.

Key Takeaways

• Run-key persistence (MITRE ATT&CK T1547.001) is captured by Sysmon Event ID 13 (registry value set), which records the key, the value data, and the process that wrote it.
• A Sigma rule for registry Run-key persistence keys on the value data — a Run entry pointing at a script host, an encoded command, or a temp path is the signal, not the write itself.
• The same pattern extends to Winlogon Shell/Userinit and Image File Execution Options, which are higher-severity because legitimate software almost never touches them.
• Sysmon registry auditing is off in many minimal configs, so the rule depends on a config that actually includes RegistryEvent.
• The rule converts cleanly to KQL; Sysmon 13 arrives via DeviceRegistryEvents in Defender XDR or the Sysmon table in Sentinel.

Environment

• sigma-cli 1.0+ with a backend installed (kusto for Microsoft Sentinel here).
• Sysmon deployed with a configuration that includes registry events — many baseline configs trim RegistryEvent for volume, and without it Event ID 13 never appears.
• Windows endpoints forwarding the Microsoft-Windows-Sysmon/Operational channel to your SIEM.
• A SIEM workspace to validate the converted query before promoting it to an analytics rule.

The Problem

Run keys are the first autostart location every attacker learns and the first defenders learn to watch, which has not made them go away. The reason is the same as for scheduled tasks and services: the mechanism is entirely legitimate. Plenty of real software adds a Run value to launch at logon, so the volume of benign writes is high, and a single malicious entry hides comfortably among them unless you inspect the value data.

The discriminator is what the value points at. A legitimate Run entry references a signed executable in Program Files. A malicious one references powershell.exe -enc, a script in \AppData\ or \Temp\, a rundll32 call, or an LOLBin. Sysmon Event ID 13 gives me the registry path, the value data, and the writing process in one event, which is everything the rule needs. The raw-key side of this is something I covered in registry forensics; here I turn it into a portable detection. The technique reference is MITRE ATT&CK T1547.001.

The Solution — Writing a Sigma Rule for Registry Run-Key Persistence

Step 1 — Confirm Sysmon is actually logging registry events

Before writing the rule, confirm the Sysmon config includes registry value-set events. Minimal configs often drop them because the volume is high:

<RuleGroup name="" groupRelation="or">
  <RegistryEvent onmatch="include">
    <TargetObject condition="contains">\CurrentVersion\Run</TargetObject>
    <TargetObject condition="contains">\Winlogon\Shell</TargetObject>
    <TargetObject condition="contains">\Winlogon\Userinit</TargetObject>
    <TargetObject condition="contains">\Image File Execution Options\</TargetObject>
  </RegistryEvent>
</RuleGroup>

Scoping the Sysmon config to the autostart paths you care about keeps the event volume sane while still capturing the persistence writes. My Sysmon configuration walkthrough covers the wider config; the snippet above is the registry-specific part this rule needs.

Step 2 — Match suspicious Run-key writes in Event ID 13

The rule pins the autostart location with TargetObject and the suspicious payload with Details — the value data Sysmon records. Keeping them in separate blocks combined with and means the rule fires only on a Run write that also carries a staging indicator:

title: Suspicious Run-Key Persistence via Sysmon Event ID 13
id: 5e2a9c41-7f63-4b08-a1d5-3c8e0f6b2d97
status: experimental
description: Detects a registry Run-key value pointing at a script host, encoded command, or user-writable path
references:
  - https://attack.mitre.org/techniques/T1547/001/
author: SecurityScriptographer
date: 2026-05-30
tags:
  - attack.persistence
  - attack.t1547.001
logsource:
  product: windows
  category: registry_set
detection:
  selection_runkey:
    TargetObject|contains:
      - '\CurrentVersion\Run\'
      - '\CurrentVersion\RunOnce\'
      - '\CurrentVersion\Policies\Explorer\Run\'
  suspicious_value:
    Details|contains:
      - 'powershell'
      - 'pwsh'
      - 'cmd.exe /c'
      - 'mshta'
      - 'rundll32'
      - 'regsvr32'
      - '-enc'
      - '-EncodedCommand'
      - '\AppData\'
      - '\Temp\'
      - '\Users\Public\'
  condition: selection_runkey and suspicious_value
falsepositives:
  - Some legitimate installers stage a launcher in AppData; verify the writing process signer
level: high

The category: registry_set log source is the abstract Sigma taxonomy that maps to Sysmon Event ID 13 through the pipeline, so the same rule works against other registry-monitoring sources without rewriting it.

Step 3 — Flag the higher-severity autostart locations

Beyond Run, a handful of registry locations are abused for persistence that legitimate software essentially never modifies. A write to any of them is worth a higher-severity alert with no payload filter at all:

title: Modification of High-Risk Logon Autostart Keys
id: a7c3f180-4e92-4d65-b8a0-1f6d9e2c5b43
status: experimental
description: Detects changes to Winlogon Shell/Userinit or Image File Execution Options debugger values
references:
  - https://attack.mitre.org/techniques/T1547/001/
author: SecurityScriptographer
date: 2026-05-30
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1547.001
logsource:
  product: windows
  category: registry_set
detection:
  selection:
    TargetObject|contains:
      - '\Winlogon\Shell'
      - '\Winlogon\Userinit'
  selection_ifeo:
    TargetObject|contains: '\Image File Execution Options\'
    TargetObject|endswith: '\Debugger'
  condition: 1 of selection*
falsepositives:
  - Rare: some debugging tools legitimately set an IFEO debugger value
level: high

The Image File Execution Options Debugger value is a particular favourite — it lets an attacker hijack the launch of a legitimate program, and it doubles as a privilege-escalation primitive. A write here is almost always worth investigating.

Step 4 — Convert and route to the right table

Conversion is the same single command. Sysmon Event ID 13 maps onto DeviceRegistryEvents in Defender XDR, or the Sysmon-sourced table in Sentinel:

sigma convert -t kusto -p sysmon runkey_persistence.yml

The converted query is the one I would write by hand against Defender, close in shape to the logic in my SIEM correlation rules walkthrough:

DeviceRegistryEvents
| where ActionType == "RegistryValueSet"
| where RegistryKey has_any (@"\CurrentVersion\Run", @"\CurrentVersion\RunOnce")
| where RegistryValueData has_any ("powershell", "-enc", "mshta", "rundll32", @"\AppData\", @"\Temp\")
| project Timestamp, DeviceName, RegistryKey, RegistryValueName, RegistryValueData, InitiatingProcessFileName

Run the query against a known-good baseline first; the writing process is the field that resolves most false positives, since a Run write by a signed installer is benign even when it stages in AppData.

Step 5 — Exclude by writing process, not by weakening the value list

The predictable noise comes from a few installers and updaters that legitimately write Run values from staging paths. Exclude them by the process that performed the write:

  filter_known_good:
    Image|endswith:
      - '\OneDriveSetup.exe'
      - '\Update.exe'          # Squirrel-based installers
  condition: selection_runkey and suspicious_value and not filter_known_good

As with the other rules in this series, document each exclusion in the falsepositives field. The essential Windows Event IDs reference covers the broader autostart monitoring this rule fits into.

Frequently Asked Questions

Why does my Sigma rule for Sysmon Event ID 13 never fire?

Almost always because the Sysmon configuration excludes registry events. Many baseline configs drop RegistryEvent to reduce volume. Add an include rule for the autostart paths, as in Step 1, so Event ID 13 is generated for the keys that matter.

Can I detect Run-key persistence without Sysmon?

Partially. Security Event ID 4657 records registry value changes but requires a SACL on each key and is rarely deployed at scale. Sysmon Event ID 13 is the practical route because it captures the value data and writing process in one event with a single config change.

What registry locations matter besides the Run keys?

Winlogon Shell and Userinit, Image File Execution Options Debugger values, the Startup approved keys, and various services and shell-extension paths. The second rule above covers the highest-signal ones; legitimate software rarely touches them, so they justify a higher severity.

How do I cut false positives from legitimate installers?

Filter on the writing process — the Image field — for known installers and updaters, combined with and not in the condition. Keep the value-data indicator list intact so you do not go blind to a malicious write using the same staging path.

Does this catch HKCU as well as HKLM Run keys?

Yes. The TargetObject|contains match on \CurrentVersion\Run\ matches the path fragment regardless of the HKLM or HKCU hive prefix, so per-user and machine-wide Run keys are both covered by the same rule.

Conclusion

Run-key persistence endures because it is legitimate, high-volume, and trivial to set, which means the detection has to read the value rather than react to the write. Sysmon Event ID 13 hands you the key, the value data, and the writing process together, and writing the logic as Sigma makes it portable across whatever SIEM you run.

This is the last technique in the series, and it follows the same pattern as the others: one rule on the common location with a payload filter, one broader rule on the high-risk locations legitimate software avoids, and exclusions keyed on the writing process rather than a weakened indicator list. The prerequisite people miss is the Sysmon config — without registry events included, the best rule in the world matches nothing.

Related Posts

• Windows Security: Registry Forensics — Where Attackers Hide — the raw-registry detail behind the autostart keys in this post.
• Sysmon Configuration for Windows Security Monitoring — how to configure the registry events this rule depends on.
• From Logs to Threats: SIEM Correlation Rules for Real Attacks — how to correlate a Run-key write with the activity that placed it.

Authoritative reference: MITRE ATT&CK T1547.001 — Registry Run Keys / Startup Folder and the SigmaHQ rule repository.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.