- Join Windows 11 to an Active Directory domain - Thu, Jun 1 2023
- Change Windows network profiles between public and private - Wed, May 24 2023
- How to map a network drive with PowerShell - Wed, May 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.)
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.
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.
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.
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
If you prefer a GUI, you can create a user-defined view in the Event Viewer.
Subscribe to 4sysops newsletter!
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.
Nice write up!
Mike, thanks for your kind words 🙂
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.
This was the only resource on the internet that helped us in generating events with an ID of 4657. Thank you for this
Hi.
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:
https://helpcenter.netwrix.com/bundle/Auditor_10.5/page/Content/Auditor/Configuration/WindowsServer/WS_Registry.htm
-> 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.
Thanks.
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!