Behavior Monitoring in Defender for Endpoint for macOS - Let's see what's it all about..

-


Microsoft recently released a capability within Microsoft Defender for Endpoint which improves the early detection and prevention of suspicious and malicious activities targeting  macOS users. I participated in early private previews and I was really impressed by its level of real-time monitoring and detection capabilities.

According to Microsoft - 

"Behavior monitoring observes how software behaves in real-time to detect and analyze potential threats based on the behavior of the applications, daemons, and files within your system. Behavior monitoring is a cornerstone of Microsoft Defender’s cloud-based protection strategy."

BM is being gradually rolled out, but once fully deployed, customers will benefit from this cloud-based protection within Microsoft Defender for Endpoint. 

As of writing this blog, there are of course some prerequisites that organizations will need to consider -

1. The device must be onboarded to Microsoft Defender for Endpoint.
2. Preview features must be enabled in the Microsoft Defender portal.
3. The device must be in the Beta channel (formerly InsiderFast).
4. The minimum Microsoft Defender for Endpoint version number must be Beta (Insiders-Fast): 101.24042.0002 or newer. The version number refers to the app_version (also known as Platform update).
5. Real-time protection (RTP) must be enabled.
6. Cloud-delivered protection must be enabled.
7. The device must be explicitly enrolled in the preview program.

Currently, BM is being rolled out automatically to External channel with App version > 101.25042.0002 and Production channel > 101.25032.0006. If you are not in any of these channels or required app versions, then you can enable the BM feature separately, just like I did. Here is how you can go about enabling it -

Creating the Behavior Monitoring xml

If you are on a Windows device, then copy the following content to create an .xml file.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>PayloadUUID</key>
        <string>C4E6A782-0C8D-44AB-A025-EB893987A295</string>
        <key>PayloadType</key>
        <string>Configuration</string>
        <key>PayloadOrganization</key>
        <string>Microsoft</string>
        <key>PayloadIdentifier</key>
        <string>C4E6A782-0C8D-44AB-A025-EB893987A295</string>
        <key>PayloadDisplayName</key>
        <string>Microsoft Defender for Endpoint settings</string>
        <key>PayloadDescription</key>
        <string>Microsoft Defender for Endpoint configuration settings</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PayloadEnabled</key>
        <true/>
        <key>PayloadRemovalDisallowed</key>
        <true/>
        <key>PayloadScope</key>
        <string>System</string>
        <key>PayloadContent</key>
        <array>
            <dict>
                <key>PayloadUUID</key>
                <string>99DBC2BC-3B3A-46A2-A413-C8F9BB9A7295</string>
                <key>PayloadType</key>
                <string>com.microsoft.wdav</string>
                <key>PayloadOrganization</key>
                <string>Microsoft</string>
                <key>PayloadIdentifier</key>
                <string>99DBC2BC-3B3A-46A2-A413-C8F9BB9A7295</string>
                <key>PayloadDisplayName</key>
                <string>Microsoft Defender for Endpoint configuration settings</string>
                <key>PayloadDescription</key>
                <string/>
                <key>PayloadVersion</key>
                <integer>1</integer>
                <key>PayloadEnabled</key>
                <true/>
                <key>antivirusEngine</key>
                <dict>
                <key>behaviorMonitoring</key>
                <string>enabled</string>
                </dict>
                <key>features</key>
                <dict>
                <key>behaviorMonitoring</key>
                <string>enabled</string>
                </dict>
            </dict>
        </array>
    </dict>
</plist>

Save it as com.microsoft.wdav.xml. Then follow the steps below to import it Intune.

Importing in Intune

2. Browse to Devices –> Configuration Profiles
3. Create profile and select New Policy.
4. Give the profile a name and select platform as macOS. 
5. Select Profile type as Templates and then Custom.
6. Provide the custom configuration profile name as com.microsoft.wdav.
7. Select the Deployment channel as Device channel.
8. Select the .xml that we created earlier. Your settings should look something like below -


9. Assign to a devices or user based group as needed.

Creating custom attribute for tracking (Optional)

If you will like to capture the compliance of BM feature, then you can do so through custom attributes. The compliance for the feature can be checked through Defender Portal, but I wanted something to report within Intune admin console as well.

Here is the script that I put together -

#!/bin/bash
#set -x

var=$(sudo /usr/local/bin/mdatp health --details features --field behavior_monitoring | awk '{print $1}')
echo "MDATP Behavior Monitoring Status:" $var

Save it as CustomAttribute_MDE_BM_Threat_Status_v1.0.sh

Importing the. sh in Intune

2. Go to Devices -> macOS -> Custom attributes for macOS -> Add.
3. Give a Name and a even a Description if needed.
5. Configure the following settings:


6. Assign to a device or user based group as needed.

End Result

Before the policy is applied, the feature will show disabled.


After the policy is applied, the feature should show enabled as shown below.


You can also verify for the enforcement of the policy by navigating to Settings-> General -> Device Management


Testing for BM feature

After the feature is enabled, you can test it by running the following as .sh for demonstration purposes.

#!/bin/bash
echo " " >> /tmp/9a74c69a-acdc-4c6d-84a2-0410df8ee480.txt
echo " " >> /tmp/f918b422-751c-423e-bfe1-dbbb2ab4385a.txt
sleep 5

You can import it as a standard script in Intune and run it that way. Note: This might throw an error, but during my testing, it did execute.


Once, the script is executed, it will give a specific result, similar to the one below -

MDATP Threat List: Id: "7faa0f82-8e31-4a2f-bad9-56f093b4f81b" 
Name: Behavior:MacOS/MacOSChangeFileTest 
Type: "behavior" Detection time: Thu Jun 19 13:08:32 2025 
Status: "quarantined" 
Process ID: 4052 Path: /bin/bash Sha256 hash: 706a6b99ab27a29b5fe323d3fcf08934407ab82470f82e76588146e1e5705014 Sha1 hash: fa3b768829d02e71f3299ded43f527a9d20c711e

If you want, you can capture this using custom attribute in Intune as well. Just put the following lines of code in a .sh and import it in Intune using the steps provided under "Creating custom attribute for tracking (Optional)" in this blog above.

#!/bin/bash
#set -x

var=$(sudo /usr/local/bin/mdatp threat list | awk '{print $0}')
echo "MDATP Threat List:" $var

It should look something like below.


If the demonstration script from earlier ran successfully, then the output should be displayed in Intune as well.


Behavior monitoring alerts are displayed in the Microsoft Defender XDR portal alongside all other alerts, enabling effective investigation.


That's it for now. I hope the information in this blog post helped in getting a glimpse of the BM feature and how it can be administered using tools like Intune and Defender XDR. Until next time..

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){              ...
Read more

Fixing Tamper Protection Blob Error 65000 using Microsoft Intune

-
Image
I recently encountered an issue with enabling Tamper protection as part of the implementation of Defender for Endpoint in one of customer's tenant and considering how unusual the behavior was and how I didn't encounter this before, I decide to blog my experience. If you have been battling with the same issue, then this blog may just help you. There are multiple ways to enable Tamper protection as part of MDE. One can enable at a tenant level using Defender portal or do it using Intune. I normally choose the Intune, especially when dealing with endpoints to maintain uniformity with other Defender policies being managed by Intune. However, in this particular instance, the issue started cropping randomly on some endpoints where tamper protection would not enable and throw an error code 65000, as show below. Additionally, the status in Defender will report as Unknown instead of reporting Active or something else like EDR in block mode to suggest that Defender Antimalware is running...
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from st...
Read more