Windows Event ID 13 — Registry Value Set

MITRE ATT&CK

Why It Matters

Attackers write to the registry at nearly every stage of an intrusion. Run keys survive reboots and re-execute payloads. Disabling Defender real-time protection via HKLM\SOFTWARE\Policies\Microsoft\Windows Defender creates a detection blind spot. Re-enabling WDigest credential caching forces plaintext passwords back into LSASS. Each of these is a single registry write — and without Sysmon 13, that write is only visible if the exact key has a manually configured SACL. Sysmon 13 monitors all registry writes by default, making it the practical replacement for native registry auditing in most environments.

Key Fields

Normal vs Suspicious

Investigation Tips

1. 1.Run key persistence: alert on any write to HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and their RunOnce equivalents from processes other than known software installers. Often appears with Sysmon 1 (process create) — the process that wrote the Run key will appear in Sysmon 1 when it executes at next logon.
2. 2.Defender disable via registry: writes to HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware = 1, or HKLM\SOFTWARE\Microsoft\Windows Defender\Real-Time Protection\DisableRealtimeMonitoring = 1. Commonly followed by Sysmon 11 (malware dropped) and Sysmon 1 (payload executed) within minutes — the attacker disables AV then immediately deploys.
3. 3.WDigest credential staging: a write of 1 to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential forces plaintext passwords back into LSASS memory. Often appears before Sysmon 10 LSASS access — the attacker enables WDigest, waits for a privileged user to authenticate, then dumps.
4. 4.AppInit_DLLs persistence: writes to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs cause the specified DLL to load into every user-mode process at startup — a rarely-used persistence mechanism that is almost always malicious in modern environments.
5. 5.Correlate TargetObject path with the writing Image: legitimate software installers writing Run keys during installation are expected, but the same operation from powershell.exe at 2am from a temp directory is not. The combination of path + process + time of day is the triage signal.
6. 6.Watch for deletion of security tool registry entries: EventType = DeleteValue on keys belonging to antivirus, EDR agents, or firewall products. Attackers remove these to prevent tools from restarting after a manual kill.

How Attackers Evade This Event

• →Alternate persistence locations — attackers use less-monitored autostart keys: HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit, or scheduled task registry entries under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache
• →Direct registry writes via NT APIs — bypassing reg.exe and using low-level NtSetValueKey calls directly from a payload; Image will be the payload process rather than a registry tool, which may not match alert rules targeting reg.exe or regedit.exe
• →Writing via WMI — using StdRegProv WMI class to write registry values remotely; the writing process appears as WmiPrvSE.exe rather than the attacker's tool
• →Encoding the payload in the value data — storing a Base64 or hex-encoded payload in an innocuous-looking string value, decoded and executed by a persistence mechanism (scheduled task, run key) that calls powershell -EncodedCommand
• →Disabling Sysmon registry monitoring — removing registry monitoring rules from the Sysmon configuration via the Sysmon driver, eliminating Event 13 without stopping other Sysmon events

Related Event IDs

Frequently Asked Questions

How is Sysmon Event 13 different from Windows Event ID 4657?

Event 4657 (registry value modified) only fires for registry keys that have been explicitly configured with a System Access Control List (SACL) via Group Policy or manual configuration. In practice, this means 4657 only covers the specific keys you anticipated monitoring — attackers using alternative persistence paths will generate no 4657 events. Sysmon Event 13 monitors all registry writes by default and can be configured to include or exclude specific paths, making it a global registry audit source rather than a per-key opt-in. Sysmon 13 also includes the writing process's full Image path, making correlation with Sysmon 1 straightforward.

Why do attackers enable WDigest authentication via Sysmon 13-visible registry writes?

WDigest is a legacy authentication protocol that, when enabled, causes Windows to cache plaintext passwords in LSASS memory alongside NTLM hashes. Modern Windows versions disable WDigest by default (UseLogonCredential = 0). Attackers re-enable it by writing 1 to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential — a single registry write captured by Sysmon 13. They then wait for a privileged user to authenticate (generating a 4624 event), at which point the plaintext password is available in LSASS. This technique is used when the target environment has Credential Guard disabled and the attacker wants plaintext rather than just NTLM hashes.

What registry paths should I prioritize monitoring with Sysmon Event 13?

In priority order: (1) Run/RunOnce keys (HKCU and HKLM) — persistence; (2) HKLM\SOFTWARE\Policies\Microsoft\Windows Defender — AV policy disable; (3) HKLM\SOFTWARE\Microsoft\Windows Defender\Real-Time Protection — AV disable; (4) HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential — credential staging; (5) HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs — DLL injection persistence; (6) HKLM\SYSTEM\CurrentControlSet\Services — service installation and modification. Add these paths to your Sysmon configuration's include rules and alert on writes from unexpected processes (anything other than known management tools and signed software installers).

Can Sysmon Event 13 detect ransomware disabling Windows Defender?

Yes — ransomware consistently disables Defender before deploying encryption. The write to HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware = 1 (or equivalent real-time protection keys) appears as a Sysmon 13 event. The writing process is typically powershell.exe, cmd.exe, or the ransomware binary itself. This Sysmon 13 event typically appears within minutes of the mass file creation spike in Sysmon 11 — making it a reliable pre-encryption indicator. Alert on any write to Defender policy keys from a non-management process as a high-priority ransomware pre-cursor signal.