Windows Security Log · Event 4657
Event 4657: A registry value was changed
Someone or something changed a value in the registry, and Windows recorded the old value alongside the new one. It only fires on keys you have specifically marked for auditing — which is the catch, because by default that is none of them.
Also written as Event ID 4657A registry value was modified4657 registry auditingregistry change event log windows
- How oftenUncommon
- Vendor calls itAudit Success
- LogSecurity
- SourceMicrosoft-Windows-Security-Auditing
What it means for you
For an analyst
The before-and-after values are what make this event worth the setup effort — almost nothing else in the Security log tells you what a setting used to be. Two practical notes. First, it needs both the Audit Registry subcategory enabled and a SACL placed on each key you care about; enabling the subcategory alone produces nothing, which is the usual reason people conclude registry auditing does not work. Second, it records value changes only — creating or deleting a key is Event 4663 with the relevant access mask, so watching 4657 alone leaves a gap exactly where persistence tends to be created.
The fields that decide it
Everything else in the log line is context.
- Object Name
- The registry key path. This is what you set the SACL on, and what tells you the significance of the change.
- Object Value Name
- The specific value within the key that changed.
- Old Value and New Value
- What it was and what it became. Rare and valuable — most audit events tell you something changed without telling you from what.
- Operation Type
- What kind of change occurred.
-
%%1904 (New registry value created)A value that did not exist before. This is the shape of a new autorun entry. -
%%1905 (Existing registry value modified)An existing value was changed. Compare old and new. -
%%1906 (Registry value deleted)A value was removed, which is how settings get quietly reverted. - Subject Account Name
- Who made the change. SYSTEM covers most legitimate configuration; a user account changing a machine-wide key is more interesting.
- Process Name
- What made the change. reg.exe and powershell.exe are worth distinguishing from an installer writing its own settings.
Common questions
I enabled registry auditing but get no Event 4657. Why?
Because enabling the audit subcategory is only half of it. Windows also needs a system access control list on each key you want watched — set it in regedit through Permissions, Advanced, Auditing, adding a principal such as Everyone and selecting Set Value. Without a SACL there is nothing to audit, and this catches almost everyone the first time.
Which registry keys are worth auditing?
Start with autorun locations, because that is where persistence is created and the volume is low: the Run and RunOnce keys under both HKLM and HKCU, Winlogon's Shell and Userinit values, and the Image File Execution Options key. Add the Services key if you can tolerate the extra volume. Auditing broadly across HKLM produces enormous noise for very little gain.
What is the difference between Event 4657 and Sysmon Event 13?
They record the same kind of change, but 4657 requires you to place a SACL on every key you care about and gives you the old value as well as the new one. Sysmon Event 13 is configured centrally in one XML file, needs no per-key setup, and is far easier to deploy — but it reports the new value only. Where the previous value matters, 4657 is the one that answers the question.
Does Event 4657 catch a key being created or deleted?
No, and it is an easy gap to miss. 4657 covers value operations within a key. Creating or deleting a key itself is recorded as Event 4663 with the corresponding access, so a rule built only on 4657 will not see a whole new autorun key appear.
Read next
- Read alongside Event 4663: Something accessed a file, folder, or registry key Object access, which covers registry key creation and deletion that 4657 does not.
- The equivalent of Sysmon Event 13: A registry value was set Sysmon's registry value set event, which needs no SACL and is configured in one file rather than per key.
- Usually comes before Event 4688: A new process has been created Process creation, giving the command line of whatever made the change.
- The equivalent of Event 7040: A service's start type was changed Service start type changes, which are registry changes Windows reports directly without any auditing setup.
- Read alongside Event 4719: The audit policy itself was changed Audit policy changes, including someone turning off the very auditing that produces this event.
Mentioned by
Vendor documentation
Last reviewed 6 September 2026