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.

Problem

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:

1. Disable the ASR rules in your environment
2. Enable the ASR rules in Audit Mode, centralize the audit events, configure exceptions and enable blocking at a later time
3. 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

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.

• Link the GPO to the client OU:
  Now take the GPO we have just created and the Security Baseline and link it to an OU where your clients reside in and they are ready to go (see also Group Policy Security Baselines and Windows as a Service – a Layered Approach).

Event forwarding Server Configuration

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):

Executable:

Arguments:

(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.

Conclusion

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.

Thanks

Thanks to Terence Beggs and SCConfigMgr for the idea and the PowerShell code regarding the Microsoft Teams forwarding.

This information is provided “AS IS” with no warranties, confers no rights and is not supported by the authors.