Windows 10: Interpreting Windows Defender Exploit Guard ASR audit alerts

Brink · Aug 14, 2018

In my previous blog, I talked about how you can leverage Windows Defender ATP’s Advanced hunting to monitor Attack Surface Reduction (ASR) alerts in audit mode and dig a little deeper into the potential application compatibility impact of enforcing more rules.

Like many app compat scenarios; however, it’s not exactly that easy. And, as one of my colleagues from Windows Defender Research was quick to point out, blocks are not guaranteed to cause application failure (for example, if the app expects and gracefully handles the result).

TL;DR

(For any non-nerds reading this – are there really non-nerds reading my blog? – that stands for too long; didn’t read.)

The easiest process to transition from audit to enforce is as follows:

Audit -> Exclude impacted apps -> Enforce

The more secure way to transition from audit to enforce is:

Audit -> Test potentially impacted apps -> Exclude verified impacted apps -> Enforce

The gory details

An audit alert being triggered does not guarantee that something bad has happened. Let’s look at an example with a (very small) environment we were running. We found two applications that were signaling an ASR block signal, but we must interpret what that signal means to understand if the app was actually impacted.

In this case, we found two apps that appear to be impacted by a single ASR rule:

If we look up what that ASR rule actually is, we discover that it corresponds with this rule:

Block credential stealing from the Windows local security authority subsystem (lsass.exe)

This rules flags whether we allow an app to open lsass process memory. Now, I’m reasonably sure that neither of the potentially impacted apps are actively trying to steal credentials and/or secrets. So, what legitimate task could they be doing that would flag this?

Well, the GoogleUpdate.exe process is probably looking to update a collection of software and walk the process list to see if you have any stuff already running (so it can offer to close it for the update and avoid a reboot). And taskmgr.exe is actively trying to enumerate all the processes on the device (i.e. doing its job).

One way to discover all of the running tasks on a system is to capture a snapshot of all running processes; for example, by calling CreateToolhelp32Snapshot, and specify for dwFlags TH32CS_SNAPALL. If you then want to get information on each task, you can then open up the process. If you call the OpenProcess API, you can then specify the dwDesiredAccess as PROCESS_ALL_ACCESS, because, hey, just asking for everything is easiest, right?

That pattern is likely to show up a few times because, as it turns out, we wrote that exact code for you.

Following this pattern, when you get to lsass.exe in the process list, you’ll be alerted to the fact that you used an overly permissive request and, in block mode, Windows Defender ATP will decline it. But, as you can see in the demo code, you can check for failure. If you check for a null handle and respond appropriately, then the failure doesn’t break your app.

And, in the case of this ASR rule, we have come across zero impact to application compatibility by switching to enforced mode. (Note: that doesn’t mean there will never be a compatibility issue. It’s just that, in this case, it appears to be statistically unlikely.) Yes, Windows Defender ATP will flag an alert and, in block mode, prevent you from being granted a handle, but doing so doesn’t necessarily break your app.

When should I test, and when shouldn’t I?

To answer this question, we must take this deeper understanding of a rule and take some action. In this case, we should look at the potential impact of enforcing this rule. If I exclude an application, then I ever so slightly increase my security risk. If a malicious actor were to try using one of the exploits you were trying to protect against (in this case, accessing LSASS memory) through this application, we would no longer block it because of the exception. Configuring ASR rules in Block mode for all but a couple of apps is good, but configuring it in Block mode for all apps is better (as long as nothing breaks)!

But, pragmatically, it may not be feasible to test absolutely everything every time. Testing fatigue is a real thing in today’s fast-moving technology world! So, I’d be tempted to evaluate the potential impact of the rule, and then decide if I want to block by default (if there is a very low potential for app impact) or exclude the app (if the potential for app impact is higher). If I choose the latter, I would also want to look at how I might be able to incorporate testing the next time I happen to be testing the app for some other reason. Additionally, keep in mind that you can customize the Windows Security Center, so you can supplement blocking with a link in the toast that pops up to help users more quickly submit feedback that something was indeed broken!

Learn more

Hopefully by peeling the onion a bit, we’ve shed some light on some of the subtleties when it comes to making pragmatic decisions for securing your organization. Going quickly can be better than doing nothing, but pausing briefly to evaluate your decision can often pay off in terms of security. Going forward, we want to continue to give you data points to help guide you in your risk/return decisions!

For more details on the full Exploit Guard stack, see Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware.

For more details on app compat strategy in a faster-moving world (which applies to all changes, not just OS changes), see my posts on Windows 10 app compat strategy and Defining app tranches to drive your app compat testing.

Chris Jackson,
Microsoft
Click to expand...

Source: https://techcommunity.microsoft.com/...ts/ba-p/228366

:)

GreginMich · Aug 14, 2018

Bug? In Windows Defender Exploit Guard.

If we assume that this is just a glitch, then you might be able to reset the Exploit protection defaults by exporting the settings from an unaffected PC (with default settings) and then importing those settings on the affected machines. This looks
to be the backup/restore tool for the Exploit protection settings:

Deploy Exploit protection mitigations across your organization

Export and Import Exploit Protection Settings in Windows 10

AndreTen · Aug 14, 2018

Does Windows Defender Exploit Protection log anywhere?

Does this document helps?

*Arrow docs.microsoft.com | list-of-all-windows-defender-exploit-guard-events

and docs.microsoft.com | evaluate-exploit-protection

Brink · Aug 14, 2018

Moving Beyond EMET II – Windows Defender Exploit Guard

Since we last wrote about the future of EMET and how it relates to Windows 10 back in November 2016 (see Moving Beyond EMET), we have received lots of invaluable feedback from EMET customers and enthusiasts regarding the upcoming EMET end of life. Based on that feedback, we are excited to share significant new exploit protection and threat mitigation improvements coming with the Windows 10 Fall Creators Update!

We recently introduced Windows Defender Exploit Guard (WDEG) which will complete our journey to incorporate all of the security benefits of EMET directly into Windows. This effort was significantly influenced by two insights that came up most frequently in our survey data, customer support calls, and conversations with EMET stakeholders and security enthusiasts. More than anything else, our customers have expressed that they want (1) a user-friendly UI for configuring mitigation settings and (2) a way to protect their legacy apps on Windows 10.

As such, with the Windows 10 Fall Creators Update, you can now audit, configure, and manage Windows system and application exploit mitigations right from the Windows Defender Security Center (WDSC). You do not need to deploy or install Windows Defender Antivirus or any other additional software to take advantage of these settings, and WDEG will be available on every Windows 10 PC running the Fall Creators Update. Windows Insiders can start trying out WDEG today following these simple steps:

Right-click the WDSC icon in the taskbar notification area and click Open, or search the Start menu for Windows Defender Security Center.

From the Windows Defender Security Center, click on App & browser control.

Scroll to the bottom of the resulting screen to find Exploit protection settings.

In addition to the new user-friendly interface in WDSC, we have added the same legacy app protections that our EMET customers have come to expect, thus achieving parity between Windows 10 mitigation support and all of the mitigation features provided by EMET. While we strongly recommend the use of Control Flow Guard (CFG) to provide the strongest protections available, we understand that many enterprises depend on legacy apps to run their business operations, many of which may never get recompiled with CFG. These users can now use Exploit Guard to help secure such apps on modern systems by configuring control flow protections for legacy apps, similar to those offered by EMET but built-in directly to Windows 10 as part of WDEG. These legacy app control flow protections include:

Export Address Filtering (EAF)

Import Address Filtering (IAF)

Validate API Invocation (CallerCheck)

Simulate Execution (SimExec)

Validate Stack Integrity (StackPivot)

Another common ask from our customers was for auditing support. To facilitate easy deployment and usage of mitigations without the burden of application compatibility side effects, we have introduced audit mode support for both EMET legacy app mitigations as well as existing native mitigations provided by Windows.

Although EMET shipped with a set of recommended configuration settings, we know that many EMET customers customized the policy to suit the specific needs of their business. To help facilitate the migration to Windows Defender Exploit Guard, we have added a new PowerShell module that converts EMET XML settings files into Windows 10 mitigation policies for WDEG. More information about this PowerShell module, and about how EMET features relate to security features in Windows 10, can be found in the topic Understanding Windows 10 in relation to the Enhanced Mitigation Experience Toolkit.

Lastly, Windows Defender Exploit Guard includes much more than the features integrated from EMET, and we look forward to discussing host intrusion prevention capabilities and other WDEG components in a future blog post. In terms of upcoming features, WDEG will soon be fully integrated with Windows Defender ATP (WDATP) to provide a single-pane-of-glass view across the Windows security stack. Violations of configured WDEG mitigations will be logged by WDATP and used as additional signals for more advanced exploit detection.

For more details on Windows 10’s threat mitigations, please refer to our Windows 10 Threat Mitigations documentation on Microsoft Docs.

- Nate Nunez, OS Security
Click to expand...

Source: Moving Beyond EMET II - Windows Defender Exploit Guard Defense

Windows 10: Interpreting Windows Defender Exploit Guard ASR audit alerts

Interpreting Windows Defender Exploit Guard ASR audit alerts

Interpreting Windows Defender Exploit Guard ASR audit alerts

Interpreting Windows Defender Exploit Guard ASR audit alerts

Interpreting Windows Defender Exploit Guard ASR audit alerts - Similar Threads - Interpreting Defender Exploit

Does Microsoft Defender Exploit Guard Attack Surface Reduction Rules ASR still function...

Microsoft Defender Exploit Guard on Windows 10 Pro

Windows 10 Exploit Guard

Windows Defender Application Guard?

Need exclusion for Defender Exploit Guard Network Protection

Need exclusion for Defender Exploit Guard Network Protection

Improve your defensive posture with Exploit Guard ASR in Windows 10

Enable Windows Defender Exploit Guard Network Protection in Windows 10

Moving Beyond EMET II – Windows Defender Exploit Guard

Users found this page by searching for:

what is asr alert

windows defender ASR

Exploit Guard Alert