Audit changes in the Windows registry

• Author
• Recent Posts

Wolfgang Sommergut

Wolfgang Sommergut has over 20 years of experience in IT journalism. He has also worked as a system administrator and as a tech consultant. Today he runs the German publication WindowsPro.de.

Latest posts by Wolfgang Sommergut (see all)

• SystoLOCK in review: Logging in to Active Directory with multi-factor authentication without passwords - Tue, Dec 5 2023
• New Group Policy settings in Windows 11 23H2 - Mon, Nov 20 2023
• Windows Server 2025 will support SMB over QUIC in all editions - Fri, Nov 17 2023

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:

HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription

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

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

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

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

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

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

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.