My Biggest Pain Points with Microsoft Defender for Endpoint (MDE).

Intro

Microsoft Defender for Endpoint (MDE) has had numerous improvements since its inception just a few years ago. Many powerful features have been introduced including impressive enrichment correlation from systems like Defender for Identity. Still, with any product, there have also been some pain points. I am hoping this post spreads some awareness to the Microsoft Product team so they continue to set a high bar and improve the service.

My approach when it comes to getting familiar with a product or solution is test out the features and make a baseline that I can refer back to at a later date. I do so by testing and validating feature functionality. I get immersed into the product and carefully observe how an action taken works. I review the outcomes of each action. This methodical process has continuously surfaced, and identified issues or misbehaving features in products I use, and MDE is no different.

As always, just because a product advertises a function or performs a similar process does not mean the outcome is the same.

Misleading Data Retention

Data Retention (180 Days)

While Microsoft allows you to select data retention for compliance requirements (up to 180 days), this selector is quite misleading as it is only saving high-level information for 180 days. The detailed level of information is not kept; only high-level events such as incidents, alerts, devices, and Action History are saved. If you try to perform an Advanced Hunting query, you can only search back 30 days of historical information.

This discrepancy is particularly frustrating because nowhere in the documentation or service states that “Advanced Hunting” is only available for 30 days. If we can select 180 days of retention for “Compliance Requirements” we should be able to perform advanced hunting against 180 days worth of data, especially with an E5 license.

While you can forward this data into an Azure Data Explorer (ADX) service and use the same query language as available in Advanced Hunting, it is not exactly a straightforward configuration process. In addition, this service costs extra.

Further Reading:

• Limitless Microsoft Defender for Endpoint Advanced Hunting with Azure Data Explorer (ADX)
• How to stream Microsoft Defender ATP hunting logs in Azure Data Explorer – Microsoft Tech Community

Containment Actions

Isolation

If you try to isolate an offline machine which is not connected to the internet, the MDE isolation action will eventually time out/expire. This usually times out after a few hours. I find this to be a huge security gap and completely unacceptable. This action should not time-out.

Suppose you isolate a machine even if it is offline. In that case, the isolation function should continue to attempt to isolate that machine until it surpasses the data retention period selected (e.g. that would be 180 days in my case).

In all of the other EDR tools I have ever used, if you isolate a machine even if it is offline, that isolation function would continuously try to isolate that target machine. If you knew a machine had malware and you wanted to take action to prevent that asset from spreading proactively, you would not be able to.

Workaround 10-28-2021: Create a custom detection rule that queries for a machine name or DeviceID to auto-isolate if the machine comes back online using “Automated Response Actions”.

MDE Query:

//Automatically Isolate Devices Listed in this Query
DeviceProcessEvents
| where (DeviceName contains "MachineName001" or DeviceName contains "MachineName002" or DeviceName contains "MachineName003")
| distinct Timestamp,DeviceName,DeviceId,ReportId
| project Timestamp,DeviceName,DeviceId,ReportId

Under actions select “Isolate Device” Full. Once any process events are generated by any of the machines in the query above the MDE Automated Response action will isolate the machine. This will usually occur within just a few minutes of the machine being online.

Stop & Quarantine vs Block Indicator (Two WorkFlows)

There are two ways to block/ban files; while the functionality may seem the same, the actions and their respective outcomes are very different, and there are caveats to both. These inconsistencies should be unified into one action step. The only saving grace I have is that MDE is pretty powerful. When combined with other protections (Defense in Depth) such as EDR Block Mode + Attack Surface Reduction Rules (ASR) + Microsoft Security Telemetry, this does help. However, a more unified approach would be best.

Unable to ban/override Microsoft Signed files

When using MDE, you cannot ban or block a Microsoft Signed file from running. I wish we could override those settings. In other EDR tools I have used, I would be able to if I wanted to ban “RDCMAN.exe.” In MDE, you cannot. There might be a time where this functionality will backfire, such as vulnerable EQNEDT32.exe, where Microsoft lost the source code and could not patch this file. While Microsoft did not sign this particular file, I still think there should be a Role or Permission to allow InfoSec teams to override this behavior.

Ban A File (but do not remediate)

I wish MDE allowed you to ban or prevent from running but not remediate a file. There are scenarios in our environment the ban may be temporary while we are in investigative mode. We want to ban the file from running but not necessarily delete/remediate the file as a proactive measure. See options available below. While at one point the feature was named “Block and Alert” it performed remediation as well. However, we do need a “Block and Alert” addition, while keeping the “Block and Remediate” function.

Live Response/Investigation

I use Live Response a lot when investigating alerts. Another feature I would like to have is the flexibility to run commands directly when using Live Response without having to resort to uploading scripts first. At least make this part of the Advanced Live Response permissions. Having to edit a script then upload it to take an advanced action slows down the response process. However, running scripts also has its benefits as we can chain together many commands to get a list of information from a machine quickly.

Settings/Permissions

Microsoft is embracing Zero Trust, but some of the Least Privilege models are missing in the permissions of MDE. The granularity is not there, and any actions that are selectable in the UI should have permissions connected to them.

While we do leverage custom groups and roles, the level of granularity does not extend too far, and we wish we could set specific default actions that would be defined on the backend based on the role permission. For example, we want to set the ban hash expiration timeout to always be “Never” of the Block Indicator screen. A user should not need to make this decision, thus reducing selection mistakes.

Questions to the Community

• Have you noticed any of these issues as well?
• Have you noticed other issues?
• Have you identified different behavior than what I have seen?