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

tutu_312 · Mar 14, 2022

Or is it redundant? If not, it would be nice if this was an option to ensure enhanced security.

:)

SE_GB · Mar 14, 2022

Windows Defender Device Guard: Attack Surface Reduction

Dear community,

I am experiencing a relatively strange behavior using Attack Surface Reduction from the Defender Device Guard.

As recommended in the baseline security 1809, I did activate the recommended ASR rules; one of them being "Block untrusted and unsigned processes that run from USB" - elaborated

here.

I did create an unsigned application using Visual studio and C#. Runs fine on the build machine.

Starting it from a USB drive, Defender Application Guard blocks the application (Code 1121, ID b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4). Intended and expected behavior.

Copying the previously started (and blocked) application to the local disk and trying to start it from there, it gets blocked again. Not so expected behavior.

Renaming this executable on the local disk to "xyz_.exe" it is not blocked. Renaming it to its once blocked at USB name, it gets blocked again.

Does anybody have an idea, if the names of the blocked application are cached in some way or why this behavior occurs?

Kind regards

mjohnsonn2 · Mar 14, 2022

CCleaner Update Triggers Attack Surface Reduction Rule

The update to v5.75.8238, CCleaner64.exe triggers an Attack Surface Reduction rule:
Block credential stealing from the Windows local security authority subsystem (lsass.exe)
Rule GUID: 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2

You won't notice it unless you happen to have ASR in place with Microsoft Defender for Endpoint.
Here is the event log entry:

Log Name: Microsoft-Windows-Windows Defender/Operational
Source: Windows Defender
Event ID 1121

Microsoft Defender Exploit Guard has blocked an operation that is not allowed by your IT administrator.
For more information please contact your IT administrator.
ID: 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2
Detection time: 2020-12-11T01:57:18.185Z
User: XXXXXX-XXXXXX\xxxxxxxxxxx

Path: C:\Windows\System32\lsass.exe
Process Name: C:\Program Files\CCleaner\CCleaner64.exe
Security intelligence Version: 1.329.181.0
Engine Version: 1.1.17700.4
Product Version: 4.18.2011.6

A similar message shows up in the GUI also containing:
"Block credential stealing from the Windows local security authority subsystem (lsass.exe)"

Brink · Mar 14, 2022

Interpreting Windows Defender Exploit Guard ASR audit alerts

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

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

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

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

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

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

LSA protection and attack surface rules

Attack Surface Reduction

Attack Surface Reduction

Question about ASR Rules and Defender for Endpoint P1

CCleaner Update Triggers Attack Surface Reduction Rule

Microsoft Defender Exploit Guard on Windows 10 Pro

Windows Defender Device Guard: Attack Surface Reduction

Interpreting Windows Defender Exploit Guard ASR audit alerts

Improve your defensive posture with Exploit Guard ASR in Windows 10