The power of Data Collection Rules: Detect Disabling Windows Defender Real-Time Protection

This is part 3 of a blog series on how to collect events using DCR for advanced use cases.

Part 1: The Power of Data Collection Rules: Event Collection for Advanced Use Cases in Microsoft USOP – Mic….

Part 2: PowerShell monitoring via Azure Monitor Agent (AMA) and Microsoft Sentinel

Defender for Endpoint (MDE) includes a variety of protections to prevent tampering and alerts to detect it, but attackers are constantly finding ways to successfully bypass and terminate MDE.

One product that really helps protect against all types of tampering is Defender’s tamper protection. To get the most out of the product line, make sure tamper protection is configured and applied in your environment. Make sure tamper protection is turned on – Microsoft Community Hub.

However, there are scenarios where organizations cannot enforce tamper protection on all devices, and attackers are always trying their best to bypass defenses and devise new and creative approaches to evade detection mechanisms and defenses. It is recommended that you monitor Defender-related event logs in parallel and respond when you discover such malicious behavior.

In this article, we will look at what event IDs you can collect to detect potential malicious behavior that could impact the protection of your organization’s devices.

First, let’s look at the relevant event IDs and definitions. You can also refer to this article for more details on each event. To troubleshoot Microsoft Defender Antivirus issues, review event logs and error codes..

The following event IDs can be found in the Security event log and are relevant to detecting if MDE is disabled:

• 3002 – Real-time protection failed with an error.
• 5001 – Real-time protection is disabled.
• 5008 – The anti-malware engine encountered an error and failed.
• 5010 – Scanning for malware and other potentially unwanted software is disabled.
• 5012 – Virus scanning is disabled.

These events also include regular configuration changes, so they should be reviewed regularly and action taken only if a specific configuration change is initiated without the user’s consent.Now let’s look at how to collect these specific logs from Microsoft Sentinel and Unified Security Operations Platform (if you haven’t onboarded Microsoft Sentinel to the Microsoft Defender Portal, here’s how to do it: Connect Microsoft Sentinel to Microsoft Defender XDR – Microsoft Defender XDR | Microsoft Learn).

I will mention several event IDs and explain in detail why I recommend them. To collect them all: You can jump directly to the summary section. Copy the final xPath query at the bottom of the article.

Step 1: Configure Data Collection Rules (DCR) to collect the required events.

As in the previous article (link), the Azure Monitor Agent (AMA) allows you to select which events to collect from your servers.

This time we are collecting non-security events, so to create a DCR, select Configure in Microsoft Sentinel, and then select Data Connectors.

Then select Windows Forwarded Events. If you can’t find this connector, first download the solution from the Content hub (under Content management).

Here, select Create DCR, add the server, then select Custom in Collection. Paste the following xPath query.

Microsoft-Windows-Windows Defender/Operational!*[System[(EventID=3002) or (EventID=5001) or (EventID=5008) or (EventID=5010) or (EventID=5012)]]

Step 2: Detect instances where critical parts of MDE are disabled or terminated

For advanced hunting, use the following queries to find instances where critical parts of MDE are disabled or terminated:

WindowsEvent
| where EventID in (3002, 5001, 5008, 5010, 5012)
| extend ["EventID description"] = case(
    EventID == 3002, "Real-time protection encountered an error and failed",
    EventID == 5001, "Real-time protection is disabled",
    EventID == 5008, "The antimalware engine encountered an error and failed",
    EventID == 5010, "Scanning for malware and other potentially unwanted software is disabled",
    EventID == 5012, "Scanning for viruses is disabled",
    "Unknown EventID"
)
| extend ProductName = tostring(EventData["Product Name"]), ProductVersion = tostring(EventData["Product Version"])
| project TimeGenerated, Computer, SystemUserId, EventID, ['EventID description'], ProductName, ProductVersion

Now you might want to create a detection function. Consider creating a detection function. Near real-time (NRT) analysis— When this happens, it will trigger an alert. In that case, go to Analytics (under Data Connectors) and create a detection. Don’t forget to map your entities, as this is important for the correlation engine to work.

Step 3: Detect configuration changes

It is also a good practice to monitor configuration changes, as they may indicate that an attacker is manipulating them. If the configuration change is not initiated by a privileged person, such behavior is suspicious.

The following events may also be found in the Security event log and indicate configuration changes:

• 5004 – Real-time protection configuration has changed.
• 5007 – Anti-malware platform configuration has changed.

To collect these events, add the following XPath query to an existing DCR that you can edit in the connector you used in step 1.

Microsoft-Windows-Windows Defender/Operational!*[System[(EventID=5004) or (EventID=5007)]]

Use this query to detect configuration changes.

WindowsEvent
| where EventID == 5013
| extend ["EventID description"] = "Tamper protection blocked a change to Microsoft Defender Antivirus"
| extend ProductName = tostring(EventData["Product Name"]), ProductVersion = tostring(EventData["Product Version"]), OldValue = tostring(EventData["Old Value"]), NewValue = tostring(EventData["New Value"])
| project TimeGenerated, Computer, SystemUserId, EventID, ['EventID description'], ProductName, ProductVersion, OldValue, NewValue

However, you may not want to trigger an incident when these events occur, because the configuration change may not be malicious. In this case, you have two options:

1. Create analytics rules that generate alerts but do not generate incidents. This is an interesting approach for customers who use: Unified Security Operations Platform (onboarding Microsoft Sentinel to the Microsoft Defender portal). This means that if the correlation engine detects something suspicious, an incident can occur.
2. Create a hunting query (select Hunting in Threat Management).

Step 4: Detecting Tampering Attempts

There is another event that may be useful to track down, Event ID 5013. If you have tamper protection enabled on your device and there was an attempt to change the Defender configuration that was blocked by tamper protection, you will find this in the Defender event log under Event 5013.

To collect these events, add the following XPath query to an existing DCR that you can edit in the connector you used in step 1.

Microsoft-Windows-Windows Defender/Operational!*[System[(EventID=5013)]]

Use this query to detect configuration changes.

WindowsEvent
| where EventID == 5013
| extend ["EventID description"] = "Tamper protection blocked a change to Microsoft Defender Antivirus"
| extend ProductName = tostring(EventData["Product Name"]), ProductVersion = tostring(EventData["Product Version"])
| project TimeGenerated, Computer, SystemUserId, EventID, ['EventID description'], ProductName, ProductVersion

Tracking this event can be useful for early detection of manipulation attempts in your environment.

summation

To collect all events mentioned in this document, you can use this xPath query under the Windows Forwarded Events connector (this will move the events to the WindowsEvent table):

Microsoft-Windows-Windows Defender/Operational!*[System[(EventID=3002) or (EventID=5001) or (EventID=5004) or (EventID=5007) or (EventID=5008) or (EventID=5010) or (EventID=5012) or (EventID=5013)]]

This is the end Part 3 Our 3-part blog series How to collect events using DCR for advanced use cases

We welcome your feedback and questions about this or any other part of this blog article series, and look forward to hearing from you.

Special thanks to reviewers Ashwin Patil and Yaniv Carmel of the Security Research Team.

Miriam Wiesner (@miriamxyra) – Principal Security Research PM, Microsoft Defender XDR Incidents | Maria de Sousa-Valadas Castaño – Principal Product Manager, Unified SecOps Platform | Shirley Kochavi – Principal Product Manager, Unified SecOps Platform