Aug 02 2022 05:50 PM - edited Aug 02 2022 05:54 PM
Aug 02 2022 05:50 PM - edited Aug 02 2022 05:54 PM
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
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.
Aug 02 2022 11:10 PM
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?
Aug 03 2022 04:01 AM - edited Aug 03 2022 04:06 AM
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
Aug 05 2022 07:37 AM
Aug 05 2022 10:01 AM
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.
Aug 05 2022 10:11 AM
@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.
Aug 05 2022 11:10 AM
Aug 08 2022 07:23 AM
Aug 08 2022 06:33 PM - edited Aug 08 2022 06:34 PM
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:
Advanced hunting query - security.microsoft.com:
Aug 08 2022 06:42 PM
In perusing various documents this article was updated today.
Aug 08 2022 06:46 PM
Aug 09 2022 10:21 AM
Aug 09 2022 04:13 PM
Aug 10 2022 05:25 AM
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
Aug 10 2022 06:52 AM
Aug 10 2022 07:10 AM
This ASR issue is affecting our existing Outlook add-ins, we haven't deployed any new Outlook add-ins @MikePalmer75
Aug 10 2022 07:29 AM
Aug 10 2022 06:02 PM
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.