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]

We are seeing the same under that path as well. Though from various apps both paid for ones and custom built ones.

[#3]

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].js

 C:\Users\local_\INetCache\IE<FOLDER>\convergedlogin_pccustomizationloader[1].js

Is any one any closer to knowing what is going on with this?

[#4]

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.

[#5]

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

[#6]

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.

[#7]

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

[#8]

@TakedaShingen 

If you get a response to say it has been fixed or if we are required to make any changes it would be great if you could post them here.

Thanks

[#9]

Microsoft Support have talked us through adding the file hash of each blocked Outlook add-in DLLs to "Indicators" in the security.microsoft.com portal. We're waiting for more info on how we can check it has applied to a device (Event Viewer, reg key(s), etc), does anyone know please?

[#10]

same for us. we had tech support adding hash based indicators in defender365 -> settings -> indicators
first we used hash from loaded plugin dll -> did not help
today we added all dll from the plugin (condeco) -> didnt help

currently we are waiting for additional microsoft support callback

[#11]

That is not a solution lol

[#12]

we also added an indicator based on condeco hash. did not fix it.
or problem plugin no1 is condeco

[#13]

the action plan was
1 taking logs
2 idicator whitelisting
3 taking logs again to get to the prob.

we have another meeting with microsoft in 20 min and this time the agend knew about the possible product team fix. for this they want to pull logs again i believe. anyhow i keep sharing our experience :D

[#14]

What you could do temporarily is create exclusions for ASR Rules.  
Blocked at Path
c:\users\jdoe\AppData\Local\Assembly\tmp\VXRVB.GHY\TheNameOfYourFile.dll

Example Exclusion
%userprofile%\AppData\Local\Assembly\tmp\*\TheNameOfYourFile.dll

Further Info

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/configure-extension-file-e...

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/enable-attack-surface-redu...

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-f...

[#15]

That was our original workaround but Microsoft Support explained this only whitelists the DLL, whereas Indicators whitelists the DLL and all associated files, including .JS JavaScript files, other DLLs, etc. So Indicators are more efficient at excluding safe add-ins than ASR rules. He also said their ASR team made more "fine tuning" yesterday and there may no longer be a need to add any file hash to the Indicators after all. Hope this helps others.

[#16]

Thanks for letting me know. I will try out the indicators instead.

[#17]

Hi @shend141,

You said that the ASR team have made some adjustments. Did they explain how those adjustments will be delivered to client and the time to see the results?

[#18]

Hi Mike, I asked the same question but he had no further details unfortunately.

I also asked how we can check if a file hash rule has applied to a device but he categorically confirmed there are no local logs in Event Viewer or any associated reg keys for security purposes. So surely there's a log on the M365 Security portal? Again, no definitive answer other than check the "last device update" column for the device, which is a good indicator but not confirmation that the file hash rule has definitely applied successfully.

'Reports > Attack surface reduction rules' already showing a much lower number of detections (mostly false-positive) but that could just be because it's a Friday and super hot weather. Monday will be a better indicator of progress once all devices have received the file hash rule updates, cold booted etc...

[#19]

Furthermore, Microsoft Support advised us to upload affected DLLs using their WDSI Submission form https://www.microsoft.com/en-us/wdsi/filesubmission so their ASR team can carry out further "fine tuning" to address these false-positive blocks. We've uploaded 2 DLLs with the 2 file hashes that represent all of the DLLs in our environment, received an email confirmation for both, currently "Status: In progress" and waiting for an update...

[#20]

Has anyone been given an explanation of why this is only affecting a small percentage of identically configured computers? 

[#21]

This would be helpful. We use a lot of outlook addons and even after safelisting I'm still getting hits. I ended up turning the whole rule to audit mode until we can get this sorted.