ASR - Behavior Changes - Blocking under User Context Now?

[brink668]

Since July 7-27-2022
I have been seeing around 40 of 1800 machines in my work environment that are showing blocks under %userprofile% or usercontext for .dll blocks. This is new behavior and is recent.  All of our machines have the same ASR rule applied, I checked on the machines via registry and their ASR rules are the same.

ASR Rule/Example Path - that is having this issue

Block executable content from email client and webmail
GUID: be9ba2d9-53ea-4cdc-84e5-9b1eeee46550
Path: %userprofile%\AppData\Local\Assembly\tmp*variousfilesandpaths.dll

Did this behavior change, is this a preview of a new feature or is this a bug? I am afraid this may spread to more machines.

We have E5 License and an MS Ticket Open as well.  Hoping someone hear knows something as well.

[#2]

Hi @brink668,

I haven't observed this kind of behavior in the field with this specific ASR rule. Mostly, when specific executions or write actions are being blocked in the user space (C:\Users\%username%\*) it's because of the ASR rule Enable Controlled Folder Access.

The ASR rule Block executable content from email client and webmail is blocking .exe, dll or .scr files it's most likely that these files are being executed from Microsoft Outlook, Outlook.com or other popular webmail providers (see: https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-r....

Have you already checked which process has initiated the execution of the particular .dll files? Is it possible that you're running a new add-on in Microsoft Outlook or something which is trying to execute files?

[#3]

@Tiennes 

Thx for the reply.

the issue is the ASR rule as described in my post. Outlook.exe is the initiating process but per documentation and all the other of my 1760 machines the ASR rule is applying to System Context and as a result does NOT block or take action on %userprofile% variables .

However on 40 of the machines the ASR rule is applying to user context or %userprofile% variable.

controlled folder access is in Audit Mode 

[#4]

Happening to us to, since around the same date. Exactly as you describe. Affecting two out of ~50 users so far. No additional insight to offer. Any news from your ticket?

[#5]

@David Schrag 

Issue persists and microsoft support is reviewing logs/traces.  MS Docs team advised to me that they are not aware of any new behavior changes to ASR so this sounds like a possible bug.  I will let you know if I find anything else out.  I will be uploading more logs but the number of machines in my environment that is effected has grown to around 180 of 1800 so it is spreading but not sure what the root cause is yet.

[#6]

@brink668 Is it your experience that on unaffected machines, add-in behavior is associated with %appdatalocal%\assembly\dl3, but on affected machines the path is %appdatalocal%\assembly\tmp? That's what it looked like to me comparing ProcMon output from two different computers. My hypothesis is that something causes a switch from the normal dl3 folder to the tmp folder and the ASR rules see the latter but not the former as a threat. I am definitely working at the outer limits of my familiarity with how .NET and Windows applications work, though.

[#7]

In some regards that is similiar to what I see of the DL3 folder, though in historical logs prior to 7-27 the same DLL shows no ASR action on it and instead shows AntivirusReport.

#Example // Prior to 7-27-2022
C:\Users\<username>\AppData\Local\assembly\tmp\BJ1O086W\Newtonsoft.json.dll
Action = AntivirusReport (No ASR)

#Example // After 7-27-2022
C:\Users\<username>\AppData\Local\assembly\tmp\BJ1O086W\Newtonsoft.json.dll
Action = AsrExecutableEmailContentBlocked (ASR takes action)

[#8]

Any news on your end? I've opened a MS ticket as well, but no insight yet. As of this morning we have a third computer affected.

[#9]

No information yet

[#10]

Hi!

I got your email from Github so replying to you here. We have the same issue starting around your dates also, not sure exactly what has caused it but not all machines are affected.
After reviewing a few queries I ran in Advanced Hunting I found that the ASR rule "Block executable content from email client and webmail" GUID "be9ba2d9-53ea-4cdc-84e5-9b1eeee46550" is causing some conflict with the Outlook sign-in and also some COM add-in's.

I am deploying the ASR rules from InTune, unsure if deploying from GPO would help.

Paths are from the users %localappdata%\Microsoft\Windows\INetCache\IE\<Folderchanges per file>\

Files listed as below:

jquery-1.12.4.1.min[1].js
hrd.min[1].js
jsonstrings[1].js
jquery-1.12.4.1.min[1].js
CommonDiagnostics[1].js
knockout-3.4.2[1].js

Action Type:

AsrExecutableEmailContentBlocked

Advanced hunting query - security.microsoft.com:

DeviceEvents | where ActionType startswith "ASR"

I have disabled this ASR rule for now as I guessed this is a bug rather than a feature.

Hope this helps!

[#11]

In perusing various documents this article was updated today.

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/manage-updates-baselines-m...

• so a platform update is incoming today/tomorrow for “patch Tuesday” .
• There is a comment that there are “improved” ways to exclude… not sure the specifics of what that means
• Another interesting thing is on the same page back in March there was a platform update that fixed Outlook Addins getting blocked in ASR.

[#12]

Seeing same but I’m also getting dlls blocked in Outlook.

[#13]

Yup Com add-in's are DLL's and are also blocked for me when this ASR rule is set to block.

[#14]

Still getting a few more machines affected each day. I created a group in MEM for the affected machines and tried to exclude that group from our dynamic "all devices" group to which the ASR policy is applied, then created a similar policy for the excluded devices that audits rather than blocks when the executable content trigger is detected. But I'm not seeing any change in behavior on the devices or even any evidence that they are being properly excluded from the primary policy.

Still no useful information from Microsoft support, although they assure me that they're working on it.

[#15]

Received an update my case is being reviewed by the ASR/WDSL (Maybe WDSI) teams. All of the additional comments have been very helpful. If anyone else has any comments please add!

[#16]

Affecting us too and Microsoft have confirmed there is unexpected behaviour from their side with the rule, so hopefully they provide a fix asap @brink668 

[#17]

@brink668 and @shend141 we are just being hit with this issue but it appears to be only happening on far on a new Outlook plugin we are deploying to 3000 machines. We had the update rings paused due to an MS Edge and EMIE application guard issue and only enabled them last week.

[#18]

This ASR issue is affecting our existing Outlook add-ins, we haven't deployed any new Outlook add-ins @MikePalmer75 

[#19]

Interesting as we have not heard anything yet regarding the existing ones. Do we know if this is an platform or anti-malware or definition update issue?

[#20]

Some of our users are also experiencing the similar problems. It started in last 2-3 days and number is growing it seems like.

For us, the issue occurs when a user creates a new Teams Meeting in Outlook and click on the Meeting Options. The meeting options dialog box opens but shows nothing, then a Defender notifications pop up stating that risky action blocked.

Upon further investigation, it seems that Attach Surface Reduction (ASR) feature is blocking the addin files. When a user clicks on "meeting options", it creates a temporary folder and few .js files in C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCache\IE\UDA76Y7T

The ASR considers that a potential threat and blocks it.

We tried to clear the cache, delete temporary files but that didn't fix the issue. We also tried to use Microsoft Support and Recovery Assistant (MSRA) but that didn't fix the issue either.