Latest posts by Wolfgang Sommergut (see all)
- Office 2019, Office 365, and Microsoft 365 in comparison: Products included, editions, licensing, and support - Mon, Mar 30 2020
- Scan, download and install Windows Updates with PowerShell - Mon, Mar 23 2020
- WinPE for Windows 10: Create an ISO or a USB stick - Mon, Mar 16 2020
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.)
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.
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.
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.