Improve your defensive posture with Exploit Guard ASR

[Chris Jackson]

Windows 10 brings with it a host of new security features – but some of them come with a string attached: you must turn them on! (Security is never easy, is it?) So, why is some assembly required? If there is a security feature that is opt-in, you can bet that there is the potential for some app compat impact. If turning on a security feature stops you from getting your work done, then, in most cases, it’s just not helpful. After all, you use computers to get work done!

Now, those of you who know me know that when presented with the Kobayashi Maru scenario, I like to cheat – take a lose/lose and create a way to win! And with Windows Defender Exploit Guard Attack Surface Reduction, the key to snatching victory from the jaws of defeat is Audit Mode. Even if you can’t stop the malicious activity from happening (because of the potential risk to app compat), you can detect that something potentially bad has happened, and act quickly to respond to the threat.

So, how do you go about getting some relatively low risk protection and enhancements to your detective controls?

Configure

The first step is to confirm any prerequisites. Once you’ve gotten the prerequisites configured, you want to enable Attack surface reduction rules in Audit mode.

If you are using Windows Defender ATP as your endpoint detection and response (EDR) solution, then you’ve already increased your security posture. These events will be added to the telemetry stream and immediately improve the quality of the device alerts you are generating.

Monitor

Once you’ve enabled the protective controls, you need to monitor what you’re finding, identifying any benign applications to build your exclusion list.

If you’re not using Windows Defender ATP as your EDR solution, you can monitor Windows Events Logs to capture audit mode events. See Enable Attack surface reduction for more details, or (even easier), use Windows Event Forwarding.

Not surprisingly, we do make this even easier if you are using Windows Defender ATP as your EDR solution. Let’s walk through that process.

First, with audit mode enabled, you’ll see events surfacing in the home page:

But what are these events? To investigate there, we’ll leverage Advanced Hunting. First, let’s query and have a look at how many events we’ve observed:

MiscEvents
 | where ActionType contains "ExploitGuard" 
 | summarize NumberOfEvents=count() by ActionType
 | sort by NumberOfEvents desc

Here, we can see the raw number of events triggered by each of the features of Exploit Guard:

Now, next we want to drill down on what exactly the rules are which we triggered, which we can do with the following query:

MiscEvents
 | where ActionType startswith "ExploitGuardAsr"
 | extend RuleGuid = tolower(tostring(parsejson(AdditionalFields).RuleId))
 | extend IsAudit = parse_json(AdditionalFields).IsAudit
 | project ComputerName, RuleGuid, MachineId, IsAudit
 | summarize MachinesWithAuditEvents = dcountif(MachineId,IsAudit==1), MachinesWithBlockEvents = dcountif(MachineId, IsAudit==0), AllEvents=count() by RuleGuid

This query will give us a readout of where machines are triggering audit and block events. (Note: this query does output the rules as a GUID – you can find an improved version of this query which translates from GUID to rule name up on GitHub.

So far, we’ve been pivoting on the protection, and as the Security Administrator concerned with operational impact, that’s probably not the only view you care about. So, next let’s get an understanding of the devices which would be impacted by enforcing these rules – here’s a query which explores by device, counting the number of alerts per device:

MiscEvents
 | where ActionType startswith "ExploitGuardAsr" 
 | summarize EGDetections=count() by ComputerName, ActionType
 | order by EGDetections desc

When we run this, we can see the device impact:

In this case, we have a single device which would be EXTREMELY impacted! In most cases, however, you don’t have quite that concentration, so the important pivot becomes which apps are impacted. So, let’s pivot that query again to focus on the apps:

MiscEvents
 | where ActionType startswith "ExploitGuardAsr" 
 | extend RuleGuid = tolower(tostring(parsejson(AdditionalFields).RuleId))
 | summarize DevicesImpacted=dcount(ComputerName) by InitiatingProcessFileName, ActionType, RuleGuid
 | order by DevicesImpacted desc

Now we can see which apps are impacted, and how many devices you light up, so we can start building exclusion rules:

With this pivot, we have enough data to start customizing our rules to move forward with the switch from Audit to Block.

Configure

We can then work this list, identifying if the behavior is, indeed, benign and, if so, writing an exclusion for the applications which would otherwise be impacted by a block.

Monitor

Once we’ve configured our exclusions, we can then switch rules from Audit to Enforce, and monitor the environment (using the approach described above) to detect if any new applications emerge which are impacted and where we need to reconfigure and extend the exclusion list.

Conclusion

As we walked through the process, I just want to reiterate that from the moment we flipped on Audit Mode, we improved our security posture. Improving the observability of the environment has important benefits. Obviously, we want to eventually get to Block where we can, but even when we can’t, improving the quality of our detective signals delivers immediate value. With Windows 10 and Windows Defender ATP, our goal is to deliver incremental value – every step you take on the process should make you safer, rather than having to wait until you finish everything before you can start to receive a return on your investment.