The registry contains numerous security-critical settings an attacker can manipulate to override important protection mechanisms. For example, an attacker can abuse it to bypass group policies. Auditing the registry helps identify such undesirable activities.

For example, if you want to protect PowerShell against misuse and record all commands executed from the command line in a log file, a hacker probably wants to disable this function to leave no traces. To do this, he could set the value of EnableTranscripting to 0. This key is under:


To find out about such manipulations, you should monitor the relevant keys in the registry. In our example, these would be those set by Group Policy Objects (GPOs) for PowerShell. As with auditing the file system, three measures are required:

  • Enable registry monitoring via GPO
  • Configure the system access control list (SACL) for the resource in question
  • Analyze the event log

Activate registry auditing

The first step is to create a GPO and link it to the organizational unit (OU) whose machines you wish to monitor for changes to the PowerShell keys in the registry.

Next, open the new policy in the GPO editor and navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Object Access. (Microsoft has deprecated the settings under Security Settings > Local Policies > Audit Policy since Windows 7.)

Activate auditing for registration via GPO

Activate auditing for registration via GPO

There you activate the Audit Registry setting, where you see two options: Success and Failure. Deciding whether you want to record failed, successful, or both accesses depends on the type and importance of the resource. However, you should find a balance between the relevance of the recorded events and the amount of data generated.

In our example, we limit ourselves only to Success to find out when the value of a key actually changed. Executing this command on the target computers activates the group policy:

gpupdate /force

And now you can customize the SACL for the registry key.

Setting permissions for registry keys

To do this, navigate in regedit.exe to the described position in the registry hive and execute the Permissions command from the PowerShell key context menu. In the subsequent dialog, click on Advanced and open the Auditing tab in the next dialog.

Editing the SACL for registry keys under PowerShell

Editing the SACL for registry keys under PowerShell

Here you add a new entry. First, choose a security principle for tracking, such as Everyone. In the next step, define which activities to record. For our purpose, we select Query Value, Set Value, and Delete to record that a value for this key has changed.

Select the type of accesses to record in the audit log

Select the type of accesses to record in the audit log

Again, you should keep in mind that monitoring full access may generate too much data, especially if you configure the SACL further up in the registry tree.

Configuring SACL via GPO

When changing the SACL of this key in the registry of many computers, it makes sense to use a GPO. You can configure the necessary setting under Computer Configuration > Policies > Windows Settings > Security Settings > Registry.

There you open the context menu of the container or right-click in the right panel. Then execute the Add Key command. In the following dialog, navigate through the registry until you reach the desired key. If this key does not exist on the local machine, you may also type the path into the input field.

You can also change the SACL of a registry key via a GPO

You can also change the SACL of a registry key via a GPO

After selecting a key, the same security dialog opens as described above for regedit.exe. Therefore, the following procedure is the same as for configuring the SACL in the registry editor.

Evaluating the event log

Finally, you should monitor the entries in the event log to discover suspicious activities. Find these in the Security protocol with the IDs 4656, 4657, 4660, and 4663. As we are only interested in changes in this specific case, the Event IDs 4657 and 4660 are sufficient. ID 4660 represents deletion.

You can retrieve these logs with PowerShell as follows:

Get-EventLog -LogName Security -Source "*auditing*" -InstanceId 4657,4660
Output audit logs for registration via PowerShell

Output audit logs for registration via PowerShell

If you prefer a GUI, you can create a user-defined view in the Event Viewer.

Subscribe to 4sysops newsletter!

Set up a custom view in the Event Viewer to filter out audit logs for registration

Set up a custom view in the Event Viewer to filter out audit logs for registration

As a filter, select Security under Event logs, Microsoft Windows security auditing for By source, and Registry for the Task category. Alternatively, you can of course also filter the view using the event IDs.

  1. Avatar

    Nice write up!


  2. Avatar
    Wolfgang Sommergut 4 years ago

    Mike, thanks for your kind words 🙂

  3. Avatar
    S. 2 years ago

    Thank you for the write up, do you know of how you can HKCU to the list of entries to be auditing via a GPO, for instance Run and RunOnce? Ok HKLM, HKU, and Class Root are options.

  4. Avatar
    Savio 1 year ago

    This was the only resource on the internet that helped us in generating events with an ID of 4657. Thank you for this

  5. Avatar
    DavideDG 1 year ago

    Please notice that using the GPO method configure SACLs will also distribute DACLs!!
    This means that registry permissions will be modified!
    There’s a reference to this problem here:

    -> NOTE: Using Group Policy for configuring registry audit is not recommended, as registry DACL settings may be lost.

    Please mention it in the article, as this can very easily go unnoticed.

  6. Avatar
    Adrian 8 months ago

    I’ve did everything as here written but no events are shown in the Event Log. I wanted to have an Event 4657 if somebody changes the Value “UseLogonCredential” under the path HKLM\System\CurrentControlSet\Control\SecurityProviders\WDigest. Unfortunatelly nothing is shown. Can somebody tell me what can be the reason? Everything is configured correctly and the GPO is applied on the Computer. Thanks in advance!

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account