Hey folks, in the last 8 years I have been helpimg a lot of companies to deploy what is now known as BeyondTrust Privilege Management for Windows (PMfW) and was formerly known as Avecto Defendpoint or Privilege Guard. In this post I want to show you how to harden your Group Policy based configurations against unwanted access.
The PMfW Agent uses a human readable XML configuration file which in most cases is deployed via Group Policy. The locally cached configuration is protected against unelevated access with NTFS permissions, but this does not apply to the default configuration of the Group Policy. The XML configuration file stored in the policy directory in the SYSVOL-Share of the Domain is readable for every authenticated user. A clever user or an attacker could use the read-only access to find a loophole in the configuration to elevate processes he is not allowed to or to gain full admin access to the computer. It is very unlikely, due to the Anti-Tampering mechanisms implemented into the Agent, but not impossible.
As you can see in the picture above the access to the local policy cache in %ProgramData%\Avecto is prohibited (1). But the user can load the XML configuration file from the GPO folder in the SYSVOL-Share and for example look up the application definitions of an Application Group (2).
If you are only using computer policies for PMfW, which is quite common, the solution is easy. Just replace the Authenticated Users entry in the Security Filtering of the relevant Group Policies with the Domain Computers group.
Changing the Security Filtering of a GPO is the same as setting NTFS permissions on the folder of the policy in the SYSVOL-Share. As you can see in the picture below accessing the GPO from the network is no longer possible for the user. However, the System Account of the device, which is automatically part of the Domain Computers group of the Active Directory Domain, is still able to access it during policy updates.
Windows 10 20H2 is again a small fall release with a long support cycle of 30 months. It shares a lot with the spring release (NTK 2004) so check out my list for this release, too.
If you found something new before me or if I missed anything important, please send me a message via Twitter.
Windows 10 2004 is the first big release since 1903 (NTK 1903) and compared to the small update of Windows 10 1909 (NTK 1909) this brings a lot of changes.
If you found something new before me or if I missed anything important please write a comment or send me a message via Twitter.
Windows Defender attack surface reduction (ASR) rules are a feature included in Windows 10 Enterprise which allows you to secure some common attack vectors like malicious E-Mail attachments or office files. It is a great additional layer for your client security strategy.
ASR is part of the Advanced Threat Protection family and therefore a Windows 10 Enterprise E5 feature. But you are allowed to use some of the rules with a Windows 10 E3 subscription though without the monitoring and management capabilities of the ATP online portal.
Most of the ASR rules included in an E3 subscription are also part of the Windows Defender Security Baseline for Windows 10 (1809) since the version for Windows 10 1709.
So what’s the problem? In my opinion you want these rules to be enabled on all your endpoints, but without monitoring and management you will have some impact on your application landscape. Especially for some of the new rules which shipped with 1809 you will need to implement exceptions, like blocking Office programs from creating child processes. But how do you want to implement exceptions if you aren’t aware which applications need them?
You have three valid options:
Disable the ASR rules in your environment
Enable the ASR rules in Audit Mode, centralize the audit events, configure exceptions and enable blocking at a later time
Enable ASR rules in block mode, centralize the block events and create exceptions promptly
Option one is obviously the worst decision you can make in terms of client security. Option two is a good way to go forward but I have worked in many projects where approaches like these were followed and in most cases the blocking was not activated before we, the externals, left. And as far as I know it was never activated at all in most cases except when it was a management goal. However, this is the recommended way to implement this technology according to Microsoft.
For me Option three is the way to go because of the Windows-as-a-Service model. A phased rollout of a feature upgrade like 1809 should give you enough time to implement exceptions for the ASR rules before you have a widespread issue if you get notified on time.
My solution to this scenario is to forward all block (or audit) events to an event collector server where a PowerShell script runs as a scheduled task. The script checks if it is the first time the executable triggered this ASR rule and if so forwards the event details to a Microsoft Teams channel. You can use the Teams channel to monitor the events and decide if you want to create an exception for the executable or not.
That is in short what I will show.
How to create an Exception for the Attack Surface Reduction Rules
At the moment you can only create exceptions for all ASR rules at once by using the group policy setting Exclude files and paths from Attack Surface Reduction Rules which you can find in Computer Configuration – Administrative Templates – Windows Components – Windows Defender Antivirus – Windows Defender Exploit Guard – Attack Surface Reduction.
Just enter the path of the executable that you want to exclude in the Name column and the 0 in the Value column.
Event forwarding Client Configuration
Windows Event Forwarding is part of the Windows Remote Management (WinRM) and can be configured on several ways. I won’t go into details about configuring WinRM, because there are already plenty of good articles about that topic. Instead I will show you an easy configuration with Group Policy. Feel free to reach out to me if you need any assistance in configuring it otherwise.
To enable Event Forwarding via GPO on the clients we have to set the following settings:
Start the WinRM service and set it to automatic:
Create a GPO and open Computer Configuration – Preferences – Control Panel Settings – Services, right click on it and select New – Service
Then click on the three dots behind Service name and select the Windows Remote Management (WS-Management) or WinRM service. After that set Startup to Automatic and Service action to Start service. Then press OK to close the dialogue.
Set the event collector server as Subscription Manager:
Go to Computer Configuration / Policies / Administrative Templates / Windows Components / Event Forwarding and open the _Configure target Subscription Manager__ setting. Click on the Show button and add Server=\<FQDN> to the table.
Now we have to configure the Event Collector Server to receive the events. You can use any currently supported Windows OS as an event collector but I would recommend using a server OS according to its role.
In order to enable the server as event collector we have to enable the event collector service and create an event subscription.
Open up an administrative cmd and enter wecutil qc and proceed with y to quickly configure the Windows Event Collector service.
After that open up the Event Viewer and click on Subscriptions. In the right pane click on Create Subscription. Give the subscription a suitable name in the windows that open up and click on Select Computer Groups….
Click on AD Domain Computers… and select an Active Directory group or the Active Directory objects you want to monitor. I used Domain Computers here so that all computers are able to send events. We already selected the computers to monitor by linking and filtering the group policy. After that press OK.
Then press on Select Events…, switch to XML and insert the following to select the Windows Defender Attack Surface Reduction Rules block and audit events (Source):
After that click on the Advanced… button and select Minimize Latency. Then click OK to save the subscription.
Now go back to the administrative cmd and use the following command to set the content format of the subscription to events which is more efficient (see also).
Configure the Team in Microsoft Teams
Go to Microsoft Teams and create or let create a new Team or reuse an existing team. I would recommend to have a dedicated team for this but do as you like.
When you have your team click on the three dots next to the team name select Add channel and create a channel for an ASR rule.
After that click on the three dots next to the channel name and select Connectors.
Search for Incoming Webhook and press the Add button.
Confirm with the__Install__ button that you want to add it to your team.
Give it a name for example Event Collector and upload a picture if you like. The picture will be used in every message sent by the script.
Press on Configure and you will get presented an URL which you should copy.
Repeat these steps for every ASR-rule and for the General channel.
Configure the Scheduled Task
After that copy the following script to your event server:
Now replace the placeholders in the GET-ASRData function (beginning in line 54) with the Webhook-URLs you created in the last step for each rule. Use the URL you create for the General channel for the default value (line 166)
If a new Windows 10 build will contain ASR rules the events will be sent to the General Channel in your teams with the new rule GUID as description. If you want to extend the script to support new rules just extend the $ASRData hash table (line 78) and add a new channel to your team.
Open up the Computer Management and go to Task Scheduler \ Task Scheduler Library and create a New Task.
Give it a name like ASR-Teams, select Run whether a user is logged on or not and select a user account to run the task. In order to use the webhooks the account needs access to the internet, so the System Account might not work if you have to use a Proxy server.
Switch to the Triggers tab, click on New… and choose a reoccurring schedule.
On the Actions tab, click on New… and use the following lines (replace with your location of the script):
(If you add the -Verbose parameter a transcript/logfile will be created in the path specified in $FilePath paramater. The default value is %programdata%\master-client)
After that check the Conditions and the Settings tab and press OK.
Now we should have anything in order and as soon as your clients start sending ASR related events to the server you should get them forwarded to Microsoft Teams.
You can now enable the new ASR rules right from the beginning of your Windows 10 1809 deployment and you will get informed if any executable is blocked in Microsoft Teams.
This is a simple proposal how to enable the ASR feature without a high user impact. If you have other tools in place to centralize events and monitor your endpoints use them instead.
When I was at a customer’s site lately and tried to enable the Windows Hello face recognition feature I encountered an error. After pressing the Get started button on the Windows Hello setup page Sorry, something went wrong was displayed without further explanations.
When I checked the Windows Event Log I could find a DistributedCOM error with the EventID 10016 which stated that the application did not have the local activation permission for the COM application.
After that I looked up the APPID from the event in the Component Services and found out that it was the RuntimeBroker which controls the execution of the AppX(Universial)-Apps. Thinking about that I remembered that we had limited the access to the camera to certain AppX-Apps via Group Policy.
I opened regedit as an Administrator and removed the value
and tested again. Then it worked! So I just needed to find out which AppX needs access to the camera. I looked up the installed AppX with the PowerShell command:
Get-AppxPackage | select Name | sort
There it was the Microsoft.BioEnrollment_cw5n1h2txyewy AppX which looked like the app I was searching for. I reset my registry changes with a Group Policy update and added the AppX name to the value of:
After that I tested again and it still worked to setup the facial recognition.
Adding the AppX Microsoft.BioEnrollment_cw5n1h2txyewy to the Put user in control of these specific apps or the Force allow these specific apps fields of the Let Windows apps access the camera setting in the GPO under Computer Settings\Administrative Templates\Windows Components\App Privacy resolved the issue and users are able to use their face to authenticate on Windows.
I just updated the Windows 10 ADMX files in the Central Policy Store of my lab domain with the Windows 10 1803 ADMX files. After that I got the error that the resource $(string.Win7Only) referenced in attribute displayName could not be found when accessing the Administrative Templates with the Group Policy Editor.
I checked the mentioned searchocr.admx and the corresponding searchocr.adml file and found out that the modified dates differed by around three years (2015 and 2018).
Looking at the extracted 1803 ADMX files from the download revealed that they only include the SearchOcr.ADML files not the corresponding ADMX.
The c:\Windows\PolicyDefinitions folder of a running instance of Windows 10 1803 does not contain the two files.
As long as I cannot find the 1803 version of the SearchOcr.admx I restored the old SearchOcr.adml file(s) from my backup and the error went away. Or even better remove the SearchOcr.ADML from every language that you want to import to the Central Policy Store.
@Jtracy_ItPro pointed out to me that the SearchOcr.adml is not the only orphaned ADML in the ADMX pack. The following list ADML files are orphaned in the 1803 ADMX pack as well
Any of these files can cause similar errors if you already have an older version of the ADMX and ADML in your Central Policy Store.
Therefore I wrote a small PowerShell function to find any orphaned ADMLs in a PolicyDefinitions folder.
You can use this function to find and remove any orphaned ADML before importing the files to the Central Policy Store
How to align the rollout of the Microsoft Security Baselines Group Policies with the Windows 10 servicing model
Update: Added WMI-Filter for Windows 10/11 21H2
Microsoft released security baselines in form of a Group Policy backup set for its operating systems in the recent years. Many enterprises are using these baselines as a security foundation. Enterprises have to adopt new settings on a lot higher frequency with the change of the servicing model and the additional release speed of Windows 10. New security baselines are now available with every release of Windows 10 every 6 months.
Note: If you want to learn more about Windows as a Service look here
The nature of Group Policies where small changes can have a huge impact on your client landscape made it necessary for enterprises to build solid change processes around them to document and verify any change. These processes are normally slow and inflexible which makes it very hard to combine them with the fast speed of new security baselines.
Another challenge for enterprises is the complexity of testing each baseline setting against a variety of several hundred applications. The traditional way was to do this in an OS upgrade project.
First, the complete baseline was activated and then redefined them during application testing. But with Windows 10 branch upgrades there are no upgrade projects and to validate a baseline with over 50 changed settings against your client landscape on a regular basis is not a feasible scenario for many companies.
In order to help the security settings keeping track with the speed of the baseline releases I am using a layered approach.
What does “layered” mean?
I distinguish between two sorts of Group Policies, the Baseline-GPOs and Custom-GPOs. The main difference between these two are that Baseline-GPOs are not changed by me at all. Every setting which differs from the baselines is made in a Custom-GPO.
Another difference between the Baseline-GPOs and the Custom-GPOs is that the baselines are filtered via WMI-Filter to the corresponding Build version of Windows 10. In contrast the Custom-GPOs are filtered to apply on all Windows 10 clients.
We need a WMI Filter for Windows 10 and for every active Build currently used. Microsoft supports the last three Build versions so you should have a maximum of three (maybe four) active builds and WMI-Filters.
Windows 10 Select * from Win32_OperatingSystem WHERE Version LIKE "10.0%" and ProductType = "1"
Windows 10 1607 Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.14393%" and ProductType = "1"
Windows 10 1703 Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.15063%" and ProductType = "1"
Windows 10 1709 Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.16299%" and ProductType = "1"
Windows 10 1803 Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.17134%" and ProductType = "1"
Windows 10 1809 Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.17763%" and ProductType = "1"
Windows 10 1903 Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.18362%" and ProductType = "1"
Windows 10 1909 Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.18363%" and ProductType = "1"
Windows 10 2004 Select Version,ProductType from Win32_OperatingSystem WHERE Version LIKE "10.0.19041%" and ProductType = "1"
Windows 10 20H2 Select Version,ProductType from Win32_OperatingSystem WHERE Version LIKE "10.0.19042%" and ProductType = "1"
Windows 10 21H1 Select Version,ProductType from Win32_OperatingSystem WHERE Version LIKE "10.0.19043%" and ProductType = "1"
Windows 10 21H2 Select Version,ProductType from Win32_OperatingSystem WHERE Version LIKE "10.0.19044%" and ProductType = "1"
Windows 11 21H2 Select Version,ProductType from Win32_OperatingSystem WHERE Version LIKE "10.0.22000%" and ProductType = "1"
The WMI-Filters contain a query about the Windows Version and the ProductType. The latter is defined as follows
1 – Client Computer
2 – Domain Controller
3 – Member Server
With these filters we make sure that the Windows 10 GPOs will only apply on Windows 10 client devices (of the defined Build Version).
I have written a short PowerShell function to import all baselines at once. You just have to export them in one folder and add ‘-Version’ (e.g. ‘-1709’) to the folder name.
Then change the ExportPath to your folder path in the following script and execute it. You will need to import the Group Policy WMI filter cmdlet module prior to successfully running the script.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The script will create or update the GPOs and name them as you can see in the picture below. Additionally it will set the corresponding WMI-Filter if it includes the Build number (e.g. 1709)
Create the Custom-GPOs
You can create a Custom-GPO for each corresponding type of baseline (Defender, Computer, …) or as I did in the example below just one Custom-GPO for all baselines.
Linking the GPOs
After having everything in place we can now link the GPOs to the OU(s). In the next picture, you can see the GPO Link order of my Windows 10 OU.
The Custom-GPOs have to be linked with a lower order number or to a Sub-OU to apply at last and overwrite the Baseline-GPO if needed.
A common baseline setting which many of my customers perceive as too strict is the UAC configuration in the baseline for Standard Users which is set to Automatically deny elevation requests.
In the Custom-GPO I changed that setting to Prompt for credentials on the Secure Desktop
As you can see in the screenshot of a Group Policy Result of a Windows 10 1709 client the baselines are applied as described and the UAC setting is overwritten by the Custom-GPO.
What is the advantage?
Instead of integrating and validating every single new baseline setting you only have to import the new Baseline-GPOs and the corresponding WMI-Filter.
Microsoft released the baselines when the Windows 10 Build became available in the Semi-Annual-Channel (formerly known as Current Branch for Business). With the release of the Fall Creators Update the final version of baselines even became available with the release to the Semi-Annual-Channel(targeted) (formerly known as Current Branch). So, it is very unlikely that you have deployed a large number of clients with the newest build before the baselines are available.
Therefore, when you start to upgrade your clients to the newest build you will automatically test the new baselines along with the new OS Version without an effect on your productive clients.
If you have to change a setting in your Custom-GPOs because of the new baselines it is very unlikely that this setting will have a negative effect on your existing clients. Because it is either a new setting which isn’t applicable for the old builds or it isn’t set in the old baselines. If the latter is the case you will set it back to the default value in most cases which already worked.
It also makes it easier to find out which of your settings differ from the baselines. You do not have to compare different GPOs with the baselines. You only have to look at your Custom-GPOs or in a Group Policy Result Report which of the settings are applied from a Custom-GPO.