M
miriamwiesner
This is Part 3 of our Blog series on how to collect events using DCRs for advanced use cases:
Part 1: The power of Data Collection Rules: Collecting events for advanced use cases in Microsoft USOP - Mic....
Part 2: Monitoring PowerShell through Azure Monitor Agent (AMA) and Microsoft Sentinel
Although Defender for Endpoint (MDE) consists of various protections against tampering and of alerts to detect it, adversaries are constantly trying to find a way to successfully circumvent and terminate MDE.
One product that really helps you to protect against all kinds of tampering, is Defender’s Tamper protection. To make the most out of your product suite, ensure that you have Tamper Protection configured and enforced in your environment: Make sure Tamper Protection is turned on - Microsoft Community Hub.
But nevertheless, there are scenarios in which organizations cannot enforce Tamper Protection for all devices and attackers being attackers always try their best to bypass defences and come up with new creative approaches to evade detection mechanisms and defences. Therefore, it might be a good idea to monitor Defender related event logs in parallel and to respond if you spot such malicious behaviour.
In this article we will review what event IDs you can collect to detect potential malicious behaviour that can affect the device protection in your organization.
First, let’s have a look at the relevant event IDs and their definitions. To get more detail on each event, you can also refer to this article Review event logs and error codes to troubleshoot issues with Microsoft Defender Antivirus.
The following event IDs can be found in the Security event log and are relevant to detect if MDE was disabled:
Since these events also contain regular configuration changes, they should be reviewed on a regular basis and only be acted upon if a certain configuration change was initiated without your knowledge.Now, we will see how we can collect these specific logs in Microsoft Sentinel and the Unified Security Operations Platform (if you have not onboarded Microsoft Sentinel to the Microsoft Defender portal, see how to do it here: Connect Microsoft Sentinel to Microsoft Defender XDR - Microsoft Defender XDR | Microsoft Learn).
Please note that we will be mentioning several event Ids and drilling down on why we recommend them. If you wish to collect them all, you can go directly to the Summary section at the bottom of the article and copy the final xPath query.
Just like we did in the previous article (link), using the Azure Monitor agent (AMA), you can select the events you would like to collect from your servers.
To create your DCR, as this time we are collecting non-Security events, under Microsoft Sentinel, select Configuration and then Data connectors:
Then, select Windows Forwarded Events. If you cannot find this connector, please make sure you download the solution from the Content hub (under Content management) in the first place.
From here, select create DCR, add your servers, and under Collect select Custom. Paste the following xPath queries:
In Advanced Hunting, please use the following query to find instances in which critical parts of MDE were disabled or shut down:
Now, you may want to create a detection —consider creating a near-real time (NRT) analytic— to trigger an alert when this happens. In that case, please go to Analytics (under Data connectors), and create your detection. Please remember to map the entities, as this is critical for the correlation engine to work, among other things.
Additionally, it is also a good practice to monitor configuration changes, as this might indicate that an attacker is tampering with it. If a configuration change was not initiated by someone who is authorized to, consider this behaviour suspicious.
The following events can be also found in the Security event log and indicate a configuration change:
To collect these events, please add the following XPath query to your existing DCR, which you can edit from the connector used in Step 1:
Use this query to detect a configuration change:
However, you may not want to trigger incidents when these events happen, as configuration changes may not be malicious. In this case, you have two options:
There is also another event that you might find useful to keep track of: event id 5013. If you have Tamper Protection enabled on your devices and if any attempts were made to change Defender’s configuration, that were blocked by the Tamper Protection feature, you can find it in the Defender event log under event 5013.
To collect these events, please add the following XPath query to your existing DCR, which you can edit from the connector used in Step 1:
Use this query to detect a configuration change:
It might be useful to keep track of this event to early spot attempted manipulation attempts in your environment.
If you wish to collect all events mentioned in this article, you can use this xPath query under the connector Windows Forwarded Events (as this will make the events to go the WindowsEvent table):
This concludes Part 3 of our 3 Part blog series on how to collect events using DCRs for advanced use cases_
We welcome your feedback and questions on this or any of the other parts of this blog article series and look forward to hearing from you.
Special thanks to our reviewers Ashwin Patil and Yaniv Carmel from the Security Research team.
Miriam Wiesner (@miriamxyra) – Senior Security Research PM for Microsoft Defender XDR Incidents | Maria de Sousa-Valadas Castaño – Senior Product Manager Unified SecOps Platform | Shirley Kochavi – Senior Product Manager Unified SecOps Platform
Continue reading...
Part 1: The power of Data Collection Rules: Collecting events for advanced use cases in Microsoft USOP - Mic....
Part 2: Monitoring PowerShell through Azure Monitor Agent (AMA) and Microsoft Sentinel
Although Defender for Endpoint (MDE) consists of various protections against tampering and of alerts to detect it, adversaries are constantly trying to find a way to successfully circumvent and terminate MDE.
One product that really helps you to protect against all kinds of tampering, is Defender’s Tamper protection. To make the most out of your product suite, ensure that you have Tamper Protection configured and enforced in your environment: Make sure Tamper Protection is turned on - Microsoft Community Hub.
But nevertheless, there are scenarios in which organizations cannot enforce Tamper Protection for all devices and attackers being attackers always try their best to bypass defences and come up with new creative approaches to evade detection mechanisms and defences. Therefore, it might be a good idea to monitor Defender related event logs in parallel and to respond if you spot such malicious behaviour.
In this article we will review what event IDs you can collect to detect potential malicious behaviour that can affect the device protection in your organization.
First, let’s have a look at the relevant event IDs and their definitions. To get more detail on each event, you can also refer to this article Review event logs and error codes to troubleshoot issues with Microsoft Defender Antivirus.
The following event IDs can be found in the Security event log and are relevant to detect if MDE was disabled:
- 3002 - Real-time protection encountered an error and failed.
- 5001 - Real-time protection is disabled.
- 5008 - The antimalware engine encountered an error and failed.
- 5010 - Scanning for malware and other potentially unwanted software is disabled.
- 5012 - Scanning for viruses is disabled.
Since these events also contain regular configuration changes, they should be reviewed on a regular basis and only be acted upon if a certain configuration change was initiated without your knowledge.Now, we will see how we can collect these specific logs in Microsoft Sentinel and the Unified Security Operations Platform (if you have not onboarded Microsoft Sentinel to the Microsoft Defender portal, see how to do it here: Connect Microsoft Sentinel to Microsoft Defender XDR - Microsoft Defender XDR | Microsoft Learn).
Please note that we will be mentioning several event Ids and drilling down on why we recommend them. If you wish to collect them all, you can go directly to the Summary section at the bottom of the article and copy the final xPath query.
Step 1: Configure the data collection Rule (DCR) to collect the required events
Just like we did in the previous article (link), using the Azure Monitor agent (AMA), you can select the events you would like to collect from your servers.
To create your DCR, as this time we are collecting non-Security events, under Microsoft Sentinel, select Configuration and then Data connectors:
Then, select Windows Forwarded Events. If you cannot find this connector, please make sure you download the solution from the Content hub (under Content management) in the first place.
From here, select create DCR, add your servers, and under Collect select Custom. Paste the following xPath queries:
Microsoft-Windows-Windows Defender/Operational!*[System[(EventID=3002) or (EventID=5001) or (EventID=5008) or (EventID=5010) or (EventID=5012)]]Step 2: Detecting instances in which critical parts of MDE were disabled or shut down
In Advanced Hunting, please use the following query to find instances in which critical parts of MDE were disabled or shut down:
Code:
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, ProductVersionNow, you may want to create a detection —consider creating a near-real time (NRT) analytic— to trigger an alert when this happens. In that case, please go to Analytics (under Data connectors), and create your detection. Please remember to map the entities, as this is critical for the correlation engine to work, among other things.
Step 3: Detecting configuration changes
Additionally, it is also a good practice to monitor configuration changes, as this might indicate that an attacker is tampering with it. If a configuration change was not initiated by someone who is authorized to, consider this behaviour suspicious.
The following events can be also found in the Security event log and indicate a configuration change:
- 5004 - The real-time protection configuration changed.
- 5007 - The antimalware platform configuration changed.
To collect these events, please add the following XPath query to your existing DCR, which you can edit from the connector used in Step 1:
Microsoft-Windows-Windows Defender/Operational!*[System[(EventID=5004) or (EventID=5007)]]Use this query to detect a configuration change:
Code:
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, NewValueHowever, you may not want to trigger incidents when these events happen, as configuration changes may not be malicious. In this case, you have two options:
- Create an analytic rule that triggers an alert, but not an incident. This is an interesting approach for customers using the Unified Security Operations Platform (onboarding Microsoft Sentinel to the Microsoft Defender portal). This was, if the correlation engine finds anything suspicious, you may get an incident.
- Create a hunting query (under Threat Management, select Hunting).
Step 4: Detect tampering attempts
There is also another event that you might find useful to keep track of: event id 5013. If you have Tamper Protection enabled on your devices and if any attempts were made to change Defender’s configuration, that were blocked by the Tamper Protection feature, you can find it in the Defender event log under event 5013.
To collect these events, please add the following XPath query to your existing DCR, which you can edit from the connector used in Step 1:
Microsoft-Windows-Windows Defender/Operational!*[System[(EventID=5013)]]Use this query to detect a configuration change:
Code:
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, ProductVersionIt might be useful to keep track of this event to early spot attempted manipulation attempts in your environment.
Summary
If you wish to collect all events mentioned in this article, you can use this xPath query under the connector Windows Forwarded Events (as this will make the events to go 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 concludes Part 3 of our 3 Part blog series on how to collect events using DCRs for advanced use cases_
- Part 1: The power of Data Collection Rules: Collecting events for advanced use cases in Microsoft USOP - Mic...
- Part 2: Monitoring PowerShell through Azure Monitor Agent (AMA) and Microsoft Sentinel
We welcome your feedback and questions on this or any of the other parts of this blog article series and look forward to hearing from you.
Special thanks to our reviewers Ashwin Patil and Yaniv Carmel from the Security Research team.
Miriam Wiesner (@miriamxyra) – Senior Security Research PM for Microsoft Defender XDR Incidents | Maria de Sousa-Valadas Castaño – Senior Product Manager Unified SecOps Platform | Shirley Kochavi – Senior Product Manager Unified SecOps Platform
Continue reading...