Sysmon · Event 13

Sysmon Event 13: A registry value was set

Something wrote a value into the registry. Filtered to the keys that cause code to run at startup, it is one of the most direct persistence detections available — and unlike file-based persistence, there is nothing on disk to notice.

Also written as Sysmon 13Sysmon Event ID 13RegistryEvent value setSysmon registry value set

How oftenFires constantly
Vendor calls itInformation
LogMicrosoft-Windows-Sysmon/Operational
SourceMicrosoft-Windows-Sysmon

What it means for you

On a personal computer

Only present if you installed Sysmon. Windows writes registry values constantly as part of normal operation.

For an analyst

Sysmon splits registry activity across events 12, 13, and 14 — key creation and deletion, value set, and rename. Event 13 is where persistence is written. Filter the configuration to Run keys, service configuration, Winlogon, image file execution options, and security product settings. Note that Sysmon abbreviates hive names, writing HKLM rather than HKEY_LOCAL_MACHINE, which breaks naive string matching.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample

Registry value set:
  RuleName: T1547.001
  EventType: SetValue
  UtcTime: 2026-08-28 09:14:11.552
  ProcessGuid: {a1b2c3d4-0000-0000-0000-00000000abcd}
  ProcessId: 7412
  Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  TargetObject: HKU\S-1-5-21-0000000000-0000000000-0000000000-1001\Software\Microsoft\Windows\CurrentVersion\Run\Updater
  Details: "C:\Users\jbrooks\AppData\Local\Temp\wh.exe"
  User: CORP\jbrooks

The fields that decide it

Everything else in the log line is context.

TargetObject: The registry path and value name that was written. The key is what carries the meaning.
Details: The value that was written. For a Run key this is the command line that will execute.
Image: The process that made the change. Installers writing Run keys is ordinary; a shell doing it is not.
EventType: SetValue for this event. Events 12 and 14 cover creation, deletion, and rename separately.

Ordinary reasons this happens

Most of the time it is one of these.

Software installers registering themselves to start at sign-in.
Windows writing configuration and state constantly as part of normal operation.
Group Policy applying settings at refresh.
Applications saving their own preferences.
Driver and update installations modifying service configuration.

When it is not ordinary

Persistence through a Run key.

What gives it awayA value written to a Run or RunOnce key by a shell, a scripting engine, or a process in a temp directory rather than by an installer.

ATT&CK T1547.001

Hijacking the sign-in process.

What gives it awayModification of the Winlogon Shell or Userinit values, which are rarely changed legitimately.

ATT&CK T1547.004

Image file execution options hijack.

What gives it awayA Debugger value set for another program, which causes that program's launch to run something else instead.

ATT&CK T1546.012

Disabling security protection.

What gives it awayValues written under Windows Defender policy keys, or to security product configuration, by anything other than management tooling.

ATT&CK T1562.001

Changing what an existing service runs.

What gives it awayModification of a service ImagePath value outside a software installation.

ATT&CK T1543.003

What to do next

Read the key path first. It determines whether the write matters at all.
Read the Details value — for a Run key that is the command that will execute.
Check which process made the change. An installer is ordinary; a shell is not.
Join on ProcessGuid to Sysmon Event 1 for the command line behind the write.
Check whether the same value appears across many machines, which usually means it is your own software.
For autostart keys, check whether the referenced file exists and where it lives.

Queries to run

kql The autostart keys that matter. Low volume once you exclude your deployment tooling.

Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 13 | where TargetObject has_any ('\\CurrentVersion\\Run','\\CurrentVersion\\RunOnce','\\Winlogon\\Shell','\\Winlogon\\Userinit','Image File Execution Options') | project TimeGenerated, Computer, Image, TargetObject, Details

kql Attempts to disable built-in protection.

Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 13 | where TargetObject contains 'Windows Defender' or TargetObject contains 'DisableAntiSpyware' | project TimeGenerated, Computer, Image, TargetObject, Details

sigma Run key writes from outside normal software directories. Tune the filter to your own installers.

detection:
  selection:
    EventID: 13
    TargetObject|contains:
      - '\\CurrentVersion\\Run\\'
      - '\\CurrentVersion\\RunOnce\\'
  filter:
    Image|startswith: 'C:\\Program Files'
  condition: selection and not filter

Common questions

What is the difference between Sysmon Events 12, 13, and 14?

They split registry activity by operation. Event 12 covers key creation and deletion, Event 13 covers a value being set, and Event 14 covers a key or value being renamed. Persistence is almost always written as a value, which is why Event 13 is the one most detection rules target.

Why does Sysmon write HKLM instead of HKEY_LOCAL_MACHINE?

Sysmon abbreviates hive names in its output, using HKLM, HKU, and similar. This trips up rules that match on the full hive name, so write your detection logic against the abbreviated form or match on the part of the path after the hive.

Which registry keys should I monitor for persistence?

The Run and RunOnce keys in both HKLM and HKU, the Winlogon Shell and Userinit values, Image File Execution Options Debugger values, service ImagePath values, and your security product's configuration keys. Those cover the large majority of registry-based persistence at manageable volume.

Mentioned by

Vendor documentation

Last reviewed 28 August 2026