Forum Discussion
ASR - Behavior Changes - Blocking under User Context Now?
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.
- I've so far only managed to check on one endpoint that was having the issue, However it's Security Intelligence Version updated to 1.373.383.0 this morning and it is no longer showing any symptoms of the problem. So early signs are encouraging that this may be fixed.
- 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?
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.
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.
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].jsAction 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!- Seeing same but I’m also getting dlls blocked in Outlook.
- Yup Com add-in's are DLL's and are also blocked for me when this ASR rule is set to block.
We are experiencing the same/similar issue too. Started about 2 weeks ago, is only effecting a small number of computers but number seems to be growing.
When Outlook requires authentication Defender blocks the log on screen from appearing as the ASR rule "Block executable content from email and client webmail" is blocking .JS files in C:\Users\local_\INetCache\IE<FOLDER>
Actual file can vary but so far I have seen: C:\Users\local_\INetCache\IE<FOLDER>\CommonDiagnostics[1].js
C:\Users\local_\INetCache\IE<FOLDER>\knockout-3.4.2[1].js
C:\Users\local_\INetCache\IE<FOLDER>\jsonstrings[1].js
C:\Users\local_\INetCache\IE<FOLDER>\jquery-1.12.4.1.min[1].js
C:\Users\local_\INetCache\IE<FOLDER>\hrd.min[1].jsC:\Users\local_\INetCache\IE<FOLDER>\convergedlogin_pccustomizationloader[1].js
Is any one any closer to knowing what is going on with this?
- We are seeing odd behaviour in that we started a rollout of a plugin to 3000 machines which had been under test for several months on 450 machines. The machines which had the application installed yesterday are reporting ASR events but the 450 pilot machines are working fine. It's almost like the ASR is trigger as it has seen a change to Outlook plugins.
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-rules-reference?view=o365-worldwide#block-executable-content-from-email-client-and-webmail).
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?
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
This ASR issue is affecting our existing Outlook add-ins, we haven't deployed any new Outlook add-ins MikePalmer75
- we have exactly the same issue for about one week. about 1-5 % of total clients affected so far but the number also seems to increase. different 3rd party plugins affected. waiting for response from ms incident manager
We are also facing the issue on several computers. The strange thing is, that all the version (Defender Engine, Signatures, Outlook and Windows) are reporting the same on affected and non-affected machines. Even the outlook internal help (press F1) is blocked.
We have also created a Microsoft case.
We provision the rules using Configuration Manager.we received the answer that it is indeed a known issue that has to be solved by the ms product team
we use intune to deliver
AsrExecutableEmailContentBlocked
- Intune_Support_Team
Microsoft
Thanks for the report! We were alerted to this thread out on Twitter and wanted to share that we’ve connected with our friends on the Defender for Endpoint team and confirmed that a signature update will be rolled out over the next few hours to resolve this issue.- ok to finish our experience: after 2 more fixes from microsoft we seem to be fine now
some users that had problems dont have them anymore
in reports -> ASR rules i also dont see any more blocks of our 3rd party software in "block exe content from email and webmail" so bit early to be sure but for now it looks like all is fixed for us- I've so far only managed to check on one endpoint that was having the issue, However it's Security Intelligence Version updated to 1.373.383.0 this morning and it is no longer showing any symptoms of the problem. So early signs are encouraging that this may be fixed.
