As mentioned in one of my previous post about the new auditing logs introduced in Microsoft Defender for Endpoint, I validated and tested several new custom detections that could add great value to your current detections.

Custom detection to Sentinel

I’m a big fan of using the power and flexibility of Sentinel. The current rules are written on the CloudAppEvent logs, which are free in the security.microsoft.com portal. However, if you want to ingest them into your Sentinel, you might end up paying a significant amount for it.

It might require some extra work, but there is a small trick you could use: Create the following rules as custom detections in the Microsoft XDR platform and then write a custom detection in Sentinel that provides the appropriate priority, entities, and automation behind it based on the incident title for example.

Detect of downloading of offboarding package

An offboarding package in the wrong hands could allow a threat actor to offboard your MDE onboarded device. This KQL query will check every 24 hours if somebody has downloaded an MDE offboarding package.

//Download of offboarding package
CloudAppEvents
| where Timestamp > ago(24h)
| extend data = parse_json(RawEventData)
| where data.Workload == "MicrosoftDefenderForEndpoint"
| where data.Operation == "DownloadOffboardingPkg"
| project Timestamp, actor=data.UserId, ActorIP=data.ClientIP, Action="Downloaded offboarding package for MDE", OperatingSystem=data.OsFamily

Device placed in isolation (+ dynamic isolation type)

When a device is put into isolation, you may want to be informed about that action. If you already have a logic app performing automated isolation or you have a custom detection with an isolation response, you might already be automatically informed (depending on your configuration). However, if an IT admin manually performs the isolation, there is currently no way of receiving a notification. With this rule logic, you can create a simple incident that will inform you of a manual device isolation, including the isolation type and the provided isolation comment.

CloudAppEvents
| where Timestamp > ago(24h)
| extend data = parse_json(RawEventData)
| where data.Workload == "MicrosoftDefenderForEndpoint"
| where ActionType == "IsolateDevice"
| extend IsolationType = iff(data.ActionScope == "Selective","Device put in isolation allowing Teams, Skype & Outlook", "Device has been placed in full isolation")
| project Timestamp, actor=parse_json(ActivityObjects[0].Name), Isolationtype=IsolationType, ActorIP=IPAddress,IsolationComment=data.ActionComment, IsolatedDevice=data.DeviceName

Tamper protection has been disabled

Tamper protection can be configured in multiple locations and ways. Without delving into the specifics of how and where you can configure your MDE, you have the option to disable tamper protection directly from the security.microsoft.com portal.

//Disable tamper protection
CloudAppEvents
| where Timestamp > ago(24h)
| extend data = parse_json(RawEventData)
| where data.Workload == "MicrosoftDefenderForEndpoint"
| where ActionType == "SetAdvancedFeatures"
| where data.SettingName == "Tamper protection"
| where data.SettingsNewValue == False
| project Timestamp, actor=data.UserId, SettingChanged=data.SettingName, TamperProtectionSettings="Tamper Protection has been disabled in the MDE portal"

getfile via Live Response

You can use live response to fetch files from an onboarded MDE device. This could also be “abused” by insider threat or attackers who want to exfiltrate data.
Sadly enough the logs do not contain a log from which device the file was downloaded :'(

CloudAppEvents
| where Timestamp > ago(24h)
| extend data = parse_json(RawEventData)
| where data.Workload == "MicrosoftDefenderForEndpoint"
| where ActionType == "LiveResponseGetFile"
| project actor=data.UserId, ActorIp=data.ClientIP, FileName=data.FileName, FileSize=data.FileSize, Filehash=data.FileSHA256

Some personal log suggestions to the MDE team!

If I were let to choose some additional log types, I would start with these:

1. Live Response Initiation: Initiating a live response can provide insights into the device file structure based on its file names and folders. Being informed about a live response session that has been started would give us valuable insights.
2. Upload file to library: I believe this is particularly important. Using live response, we are capable of running any script under system context. In purple team exercises, I have seen attempts to abuse live response capabilities to run scripts. Gaining visibility into what is being uploaded to which device can help us significantly in managing security risks.
3. Execution of Scripts via Live Response: It would be beneficial to track the scripts that were executed on every device. While you can verify this in the DeviceProcessEvents of the device, having a separate log to correlate with would be valuable 🙂
4. LiveResponseGetFile: allow it to include the device from where the file was gathered. Based on my investigation in the logs there is no trace of which device the file was gathered from. There is also no way for me to correlate it to a Live Response session as I have no initiation log.
5. Troubleshooting Mode: Troubleshooting mode allows us to disable tamper protection on any device, meaning that the command Set-MPPreference -DisableTamperProtection $true would have an impact. This command is not unknown to me, as I have seen threat actors (particularly noisy ones) try to disable MDE in this manner. It would be helpful to validate in the logs that there were no maintenance windows scheduled for the device at that time. At this moment there is no log that indicates that a troubleshooting window was created.