In this blog, we will look at Defender for Endpoint (MDE) Endpoint Detection and Response (EDR) sensor and possible conflict with Line of Business application and scripts. this sensor will be activated when you onboard a server and is independent from the AV component (MsMpEng.exe). You will find it in the services as Windows Defender Advanced Threat Protection, with Sense as short name and mssense.exe as process.
It's important to differentiate between the AV and EDR because exclusions are managed separately and the EDR may impact your machine regardless of the AV mode (real-time, passive or EDR in block mode). The general exclusions only apply to the AV sensor and
there are no direct ways to exclude a process or folder from the EDR sensor. This sensor will have no impact on most of applications and systems but in some cases an EDR exclusion will be required to ensure your workload completes successfully.
In this blog, we will look at the steps to determine the implication of the EDR sensor, which tool to use and how to remediate them.
Table of Contents
The scenario
I have seen this issue occurring on the same type of application with the following characteristics:
Document Generator: the documents are often text files (such as Word or PDF) generated from templates or aggregated.
SMB file share: I've mostly seen this issue occurring when those files are produced or exported in an SMB file share but I won't exclude that it will never occur locally.
The application running can be a script or a legacy application using legacy DLLs such as previous WinWord DLLs .
The issue occurs when the application and the EDR sensor access a file in the same time and concurrent access may not be optimised. This is basically a tempo issue when the application is attempting to write content in a file that is currently locked/evaluated by the EDR sensor and thus why those issues may seem occurring randomly.
The tool
To analyse the sequence we will use Procmon or Process Monitor from Sysinternals, an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. We have to be able to reproduce the issue to capture the events. Procmon produces extensive verbose logs so it can be cumbersome at first to find the issue when you don't know what and where to look.
The case
In my case WinWord is executed by a script and generates multiple tmp files based on a template and export the result to a remote location. Some of the file batches fail randomly and are not correctly generated.
At first we want to refine the logs to find any possible issue occurring on the final destination. Because I know the destination and the process name I can use the following filters:
1 - Process Name is WinWord.exe
2 - Path contains \\ because I suspect the files failing in a network location
Note: Procmon is case insensitive
The error we are looking for are Sharing Violation or Access Denied but it doesn't mean all occurrences are relevant to our case as many of them are unrelated to defender.
When you have identified an Access Violation or Access Denied, deselect/disable the Process Name filter and reveal if mssense.exe is the cause of the sharing violation. It should look at something like the below screenshot:
We can see that mssense.exe opens the tmp file with the sharing mode: Read as shown below
In the next entry, WinWord attempts to lock the file with write permission and a share mode read, write, delete
Because the file is already locked by mssense.exe and only Read operation, set by share mode, is allowed, WinWord operation results to Access Denied.
Let's take another example
In this example, we can see mssense.exe opens a file with the share mode Read, Write, Delete
Then WinWord use the share mode none and thus results to a sharing violation because the share mode are different.
Sharing Violation or Access Denied should occur on your application operations. You can discard those errors when they occur on mssense.
Conclusion
Take your time when investigating such failure and make sure to find multiple occurrence to ensure the issue is really due to mssense. It's important to understand the sequence of your application and where it fails. I've used MDE timeline as well to gather a high level of the application sequence. It could feel like looking for a needle in a haystack but with practice you'll find those issues in no time.
After gathering evidences that mssense impact your application, you will need to raise a support ticket with Microsoft requesting an EDR exclusion. You will also need to provide a client analyser log (https://aka.ms/BetaMDEAnalyzer) by running
DrivePath\MDEClientAnalyzer.cmdIt's important to understand that an exclusion is an opening in your environment and weaken your security so make sure to restrict that path as much as possible and follow the recommendation from Microsoft or the amazing post from Fabian Bader: The Hitchhiker's Guide to Microsoft Defender for Endpoint exclusions - Cloudbrothers
I hope this quick blog will help
Thanks for reading!
About William Francillette:
I am a Microsoft Solutions Architect specialized in Microsoft 365, Entra and Azure security products at Threatscape.
I love learning, blogging and coding. My interests are very diverse and span across architecture, security, cloud engineering, automation, DevOps and PowerShell.
I own over a dozen Microsoft certifications and have worked in IT across multiple and diverse industries for over 15 years.