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.

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.

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:

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:

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.

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.

Are you an IT pro? Apply for membership!

Your question was not answered? Ask in the forum!

2+

Users who have LIKED this post:

  • avatar
Share
2 Comments
  1. Mike Kanakos 2 weeks ago

    Nice write up!

     

    0

  2. Wolfgang Sommergut 2 weeks ago

    Mike, thanks for your kind words 🙂

    0

Leave a reply

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

*

© 4sysops 2006 - 2020

CONTACT US

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

Sending

Log in with your credentials

or    

Forgot your details?

Create Account