In the previous post I provided an overview of the history of Windows Defender and an overview of the various features that have the name Windows Defender in them. When then looked at Windows Defender SmartScreen and Windows Defender Cloud based protection. Today I’d like to continue with my notes from the field and personal experiences and take a look at Windows Defender Exploit guard. Again, the objective of this blog post is to inspire you getting the most out of the Defender feature set to improve your security posture.

Windows Defender Exploit Guard

First let’s get rid of the wrong assumption out of the way that you need a Windows 10 E5 license to use Windows Defender Exploit Guard because you can and are allowed to use Exploit Guard as well with a Windows 10 E3 license. The thing with the E5 license is that you get more management capabilities such as monitoring the impact when auditing or enabling blocking rules.

Windows Defender Exploit guard consist of four components:

• Attack Surface Reduction (ASR): A set of controls that enterprises can enable to prevent malware from getting on the machine by blocking Office-, script-, and email-based threats
• Network protection: Protects the endpoint against web-based threats by blocking any outbound process on the device to untrusted hosts/IP through Windows Defender SmartScreen
• Controlled folder access: Protects sensitive data from ransomware by blocking untrusted processes from accessing your protected folders
• Exploit protection: A set of exploit mitigations (replacing EMET) that can be easily configured to protect your system and applications.

If you are totally unfamiliar with Windows Defender Exploit Guard, I suggest you read Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware first and then continue reading here.

Please note that the first three components require that always on protection for Windows Defender must be enabled.

Manageability and monitoring

Before looking at each individual component , let’s first clarify the topic about manageability and monitoring.

Configuring and deploying exploit guard settings

Depending on how you manage your clients, you can use on of the following methods to configure and deploy Windows Exploit Guard features.

• Group Policy Management
• System Center Configuration Manager
• Microsoft Intune
• PowerShell
• Windows Security App

For more information see:

• Enable exploit protection
• Enable network protection
• Enable controlled folder access
• Enable attack surface reduction rules

Monitoring impact and effectiveness

You see, enabling and deploying these features is pretty straight forward. But depending on your environment enabling some of these features can negatively impact users, so what you want to do is monitor the possible impact and deploy these settings in a controlled manner.

With the exception of certain exploit protection rules, most of the features and rules can be configured to run in audit or in block mode. But regardless of the mode used, all results are always written into the Windows Event log.

If you start experimenting with the various Windows Exploit Guard features on your own computer, you will want to examine the exploit guard event logs. For this I wrote a PowerShell cmdlet that helps you to easily retrieve these logs. When interested read: Retrieving Windows Defender Exploit Guard Windows Event logs with PowerShell.

The below example shows the log result of an audited ASR Rule. Take note of the referende ID as it relates to the corresponding ASR Rule, in this case ‘Block Office applications from creating executable content’. You find a list of all possible IDs here.

The next example shows the log result of a blocked network protection rule. Here Defender ATP custom indicators were used where I configured to block access to the domain shown below.

And here we see the result when auditing controlled folder access. Exploit Guard CFA File creator.exe was detected as it writes to a user protected folder. When deploying this in production, you will first want to identify these events and add any legitimate software to the CFA allowed applications configuration.

Okay, so you have tried out these settings on your own system and decided to move forward and deploy this to a number of test clients, pilot group however you name the within your organization. In any case as mentioned earlier , some of these rules could negatively impact your users, so you will want to monitor the effect, either by running, where possible, the rule in audit mode or in block mode. And here is where we get back to the E3 or E5 licensing topic. Here’s how Microsoft explains it:

What this means is that if you are already doing Windows Event log forwarding either through native Windows Event Forwarding, Azure Log Analytics or any other 3^rd party event collection solution, you should include the above described events in your log collection so that you can review the results. If you don’t have a Windows Event log forwarding in place but have a Windows 10 Enterprise E5 license, you can use the Microsoft Defender Advanced Threat Hunting capability to analyze the log results.

When running the following advanced hunting query, we get a summary of exploit guard events.

MiscEvents

| where ActionType contains “Asr” or ActionType contains “ExploitGuard” or ActionType contains “ControlledFolderAccess”

| summarize count() by ActionType

| sort by ActionType

So to find the results when auditing Windows Defender Exploit Guard Controlled folder access we run the following querry:

MiscEvents

| where ActionType == “ControlledFolderAccessViolationAudited”

| extend auditmode = extractjson(“$.IsAudit”,AdditionalFields, typeof(string))

| project FileName , FolderPath , InitiatingProcessFileName , auditmode , ComputerName , AccountName

And here an example to find Windows Defender Network Protection logs.

MiscEvents

| where ActionType == “ExploitGuardNetworkProtectionBlocked”

| project ComputerName , RemoteUrl , InitiatingProcessFileName

But wait there’s more, when opening https://security.microsoft.com under the Reports node, we find more information about our ASR deployment.

When going to the details page by selecting ‘View detections’ we get more detailed results of the audited or blocked rules. Use the ‘GroupBy’ option to group the results by rule, Device, Application etc.

Here we see an overview of how many clients receive ASR rules and whether they run in audit or block mode.

And finally we can use the ‘add exclusions’ node to see the impact and get the exclusion information that we would need to configure to mitigate possible issues.

Good, now just in case all this has triggered an interest in looking closer at Windows Defender Exploit guard, below are some additional refences , blog posts I recommend reading.

• Windows Defender Exploit Guard ASR VBScript/JS Rule
• Windows Defender Exploit Guard ASR Rules for Office
• Windows 10: Windows Defender Exploit Guard-Attack Surface Reduction rules
• Windows 10: Windows Defender Exploit Guard-Exploit Protection
• Assessing the effectiveness of a new security data source: Windows Defender Exploit Guard
• Hunting Windows Defender Exploit Guard with ATP

That’s it for today, stay tuned for Part 3 of this series anytime soon.