Warning: Microsoft Defender for Endpoint (MDE) Alert Visibility Bug

There is a critical bug or arguably an undocumented ”feature” in Microsoft Defender for Endpoint (MDE) that significantly limits the visibility of endpoint protection. This bug has been verified on a Windows 11 device and appears related to the Alert Tuning functionality introduced in Defender XDR.

The core behavior is that almost every file detected by the antivirus engine gets reclassified as a ”behavior record” and no longer generates an alert. This might be acceptable if the malware engine consistently classified threats correctly and assigned appropriate severity levels but as this post will demonstrate, that is not the case. Worse, this change introduces some unexpected side effects that leave security teams in the dark.

Background

Microsoft enabled this functionality in Defender XDR, documented in message center notification MC1228325. The rollout timeline was as follows:

February 8, 2026 – Rules become visible in the portal (Preview) for review

February 8-18, 2026 – Rules are visible but not yet active, allowing teams to review and opt out

February 18, 2026 – Rules become active by default

The following is Microsoft’s description of the intended behavior:

With the default experience, you should see fewer informational or low severity endpoint alerts in your incident and alert queues, because matching alerts gets handled automatically. Some rules use resolve and others use Set as Behavior, which reclassifies an alert as a behavior record. These alerts will not appear in open alert queues and will not generate incidents, while remaining available for investigation and hunting.

The Problem

This is where things start to break down. In practice, nearly everything classifies as informational and is reclassified as a behavior record with very little transparency around what gets suppressed and why.

To illustrate the issue, we tested three threats on an endpoint:

Eicar test file – AV test file

Invoke-Mimikatz.ps1 – credential dumping tool from the PowerSploit framework

PureLogsStealer – a real-world information stealer sourced from Malware Bazaar

For each test, we checked four things: whether the file generated an alert in the Security portal, whether it was suppressed, whether it was detected and blocked, and whether it appeared in the endpoint’s event timeline.

Test Results

Test 1: Eicar

The Eicar test file was written to the endpoint and the antivirus triggered as expected but no alert was generated in the Security portal. Querying the BehaviorInfo table in Advanced Hunting confirmed that the detection was suppressed via Set-As-Behavior. The event was also visible in the endpoint’s timeline under the AntiVirusDetection action type. See the pictures below for the Set-As-Behavior rule and events displayed in the timeline of the Device:

Test 2: PureLogsStealer

The PureLogsStealer was detected and blocked by the antivirus engine, and the event appeared in the timeline. However, unlike the Eicar test, this detection did not produce a BehaviorInfo entry meaning it was suppressed without any notifications or traceability:

Test 3: Invoke-Mimikatz.ps1

The same behavior occurred with Invoke-Mimikatz.ps1. The AV engine detected and stopped it, the event appeared in the timeline, but no alert was generated and no BehaviorInfo entry was created.

Summary

A summary of the tests:

Test	BehaviorInfo	AntiVirusDetection	Alert
Eicar	Yes	Yes	No
PureLogsStealer	No	Yes	No
Invoke-Mimikatz.ps1	No	Yes	No

Discussion

The suppression logic is inconsistent and difficult to reason about. The Eicar test file, whose sole purpose is to validate that antivirus alerting works, now silently gets reclassified as a behavior record. Meanwhile, the information stealer and Mimikatz detections are suppressed entirely, without even appearing in BehaviorInfo or creating any alerts.

This raises a serious operational concern: if a threat actor is active in your environment and attempts to download Invoke-Mimikatz, should that not generate an alert? In our view, absolutely yes. High-severity detections like credential dumpers and information stealers should never be silently suppressed. We have seen cases where threats slipped past MDE using various evasion techniques, but there were always signals that enabled investigation. Removing those signals from your Security Operations team makes effective threat investigation harder.

What makes this particularly concerning is that the change was enabled by default, with no proactive warning to security teams except the MC1228325. Organizations that haven’t actively reviewed their Alert Tuning rules is probably affected by the bug.

It’s also worth noting that these tests only covered file-based detections and we did not test behavioral detections triggered by sequences of events on an endpoint, which may behave differently.

Recommendation

Until Microsoft resolves this issue, we recommend disabling all Alert Tuning rules with the action Set-As-Behavior by navigating to:

Settings -> Microsoft Defender XDR -> Alert Tuning in the Security portal.

Kusto

If you want to understand what has already been silently suppressed in your environment, the following KQL queries can help.

To see which detections have been reclassified as behavior records via Set-As-Behavior, query the BehaviorInfo table in Advanced Hunting:

BehaviorInfo | summarize count() by Description

To find detections that were blocked by the antivirus engine but never produced a BehaviorInfo entry and therefore left no trace in your alert queue:

DeviceEvents | where ActionType contains "AntivirusDetection"

Comparing the results of both queries will give you a clearer picture of the gap between what your antivirus is catching and what your security team is actually being notified about.

Updates

A case has been raised with Microsoft. They have replicated the issue and are actively working on a fix.

I will update the blog as soon as more information becomes available.

Update 2026-03-03

This issue has been resolved by Microsoft 2026-03-02.

Waiting for more information if missed alerts with severity Low-High will be reclassified or if it’s a manual work to find these.