Microsoft Defender for Endpoint (MDE) — Custom Role Design for Troubleshooting Mode–Only Access
1) Introduction In customer environments, Security Operations (SOC) teams and Windows infrastructure teams frequently need to investigate endpoint issues in the Microsoft Defender for Endpoint portal—often under time pressure—while still preserving strong governance over who can change security controls. Because Troubleshooting Mode can enable temporary modification of Defender Antivirus settings even when devices are governed by organizational policies (for example, when policy protections are in place using Tamper protection settings), granting this capability broadly can introduce configuration drift, increase operational risk, and blur accountability. To address this, customers typically require a least‑privilege, scoped access model that enforces Segregation of Duties (SoD): Investigators (Security Reader) retain visibility and investigation capability but cannot create or modify MDE security policies. Only an explicitly authorized group is granted the minimum permissions required to enable Troubleshooting Mode, and that access is restricted to a defined device scope using device groups—supporting both risk reduction and clear governance. This approach ensures teams can perform required investigations and controlled troubleshooting while maintaining least privilege, SoD, and predictable operational impact across the customer’s environment. This document describes an approach to providing controlled access to Troubleshooting Mode on a scoped set of devices. - An Entra ID user group to collect eligible users - A custom Defender XDR role with only the minimum required permissions - Microsoft Defender for Endpoint device groups to scope where those permissions apply The goal is to enable safe troubleshooting while maintaining least privilege and preventing unintended policy changes. 2) Prerequisite & Coverage - An Entra ID user group to collect eligible users - A custom Defender XDR role with only the minimum required permissions - Microsoft Defender for Endpoint device groups to scope where those permissions apply The goal is to enable safe troubleshooting while maintaining least privilege and preventing unintended policy changes. This setup is necessary to: - Enforce least privilege (only the permissions needed for Troubleshooting Mode and limited operational actions) - Scope powerful actions to a defined device group instead of all devices - Support a split model where one Security Reader group gets Troubleshooting Mode access and another Security Reader group remains view/operate without TS Mode - Preserve governance: users can investigate and perform limited actions but cannot create or modify MDE policies - Improve auditability by ensuring key actions are observable via device telemetry and the Action Center (while acknowledging that some telemetry may not include the initiating username). 3) Implementation Steps for Troubleshooting Mode (TO BE PERFORMED IN MICROSOFT DEFENDER PORTAL / ENTRA ID) 3.1 Prepare Entra ID User Group Identify an existing Entra ID user group that contains users (IT Infra Team) with the Security Reader role or create a new dedicated Entra ID user group for this purpose. - This group will be used consistently for: - Assigning the custom Defender XDR role - Scoping access to Defender for Endpoint device groups 3.2 Create and Assign Custom Defender XDR Role Create a custom Defender XDR role with Microsoft Defender for Endpoint (MDE) Security Settings Management permissions. - While creating the custom role, select only the minimum required permissions to maintain a least-privilege model. - Assign this custom Defender XDR role to the Entra ID user group identified in Step 1. Reference: See screenshots below for role creation, permission selection, and Entra ID group assignment. 3.3: Assign Entra ID User Group to Device Group Assign the same Entra ID user group (used in Steps 1 and 2) to a Microsoft Defender for Endpoint device group. - Devices in the device group should be dynamically grouped using supported criteria such as: - Device tags - Device name patterns - Other supported device attributes - This scoping ensures that the custom role permissions apply only to the intended set of devices. Reference: See screenshot under below showing device group creation and Entra ID group-to-device group assignment. 3.4 Resulting User Experience and Permissions After completing Steps 3.1 through 3.3, users who sign in with: - Security Reader role, and - Custom Defender XDR role will observe the following behavior in the Microsoft Defender portal: - Troubleshooting Mode is available on the scoped devices - Users cannot create or modify MDE policies - Users have access only to a controlled set of operational and investigative actions, including: - Exclude - Go hunt - Download force release from isolation script - Ask Defender Experts This configuration enables safe troubleshooting while preventing configuration drift or unauthorized security policy changes. Reference: See screenshot under below illustrating the available actions and the absence of policy creation/modification options. Reference: See screenshot below where creation of AV policy failed as User will not have access to Intune to create policy. 4. In an alternate scenario, two separate Security Reader groups are maintained: one group requires access to Troubleshooting Mode, while the other should have no Troubleshooting Mode access. Users in the latter group (no TS Mode requirement) can continue to use standard Microsoft Defender for Endpoint (MDE) operational capabilities such as managing tags, setting device criticality, running antivirus scans, collecting an investigation package, reporting device inaccuracy, initiating advanced hunting (Go hunt), triggering policy sync, and running automated investigations. Users in the Troubleshooting Mode-enabled Security Reader group must also be assigned to the appropriate MDE device group to ensure their device-level access and workflows continue to function as expected. Reference: See the screenshot below, which illustrates the additional MDE capabilities available to users who also have access to the device group 5: Auditing and Event Visibility - Events related to Tamper Protection changes and Troubleshooting Mode enablement are captured in Microsoft Defender for Endpoint telemetry. - These events are logged and visible for audit and investigation purposes. - The username is not recorded in these specific event entries, which is expected behavior in the current Defender auditing model. However, the activation of Troubleshooting Mode is still logged and visible in the device Action Center, which allows confirmation that the mode was enabled on the device and the username. Reference: See screenshot under Step 6 showing the relevant audit and event records in Timeline of Device Page. Similarly ,correlate using KQL across two Event Tables (DeviceEvents & EntraIdSignInEvents). Below is the KQL query let TimeWindow = 10m; let Lookback = 7d; // Portal sign-ins (Security & Compliance Center) let DefenderPortalSignins = materialize( EntraIdSignInEvents | where Timestamp >= ago(Lookback) | where Application == "Microsoft 365 Security and Compliance Center" | project SignInTime = Timestamp, PortalUserUpn = AccountUpn, PortalUserObjectId = AccountObjectId, SignInIP = IPAddress, CorrelationId | extend TimeBucket = bin(SignInTime, TimeWindow) ); // Tamper-protection related events (broaden as needed) let TamperEvents = materialize( DeviceEvents | where Timestamp >= ago(Lookback) | where ActionType has "Tamper" or ActionType == "TamperingAttempt" | project TamperTime = Timestamp, DeviceId, DeviceName, ActionType, AdditionalFields | extend TimeBucket = bin(TamperTime, TimeWindow) ); // Output rows: (UPN, TamperTime) within +/- window TamperEvents | join kind=inner (DefenderPortalSignins) on TimeBucket | where abs(datetime_diff("minute", TamperTime, SignInTime)) <= toint(TimeWindow / 1m) | project PortalUserUpn, TamperTime, SignInTime, DeviceName, DeviceId, ActionType, SignInIP, CorrelationId, AdditionalFields | order by TamperTime desc This query correlates by time proximity. It indicates “user signed into the portal around the time a tamper event happened.” It does not prove that the portal user caused the tamper event (that requires audit telemetry for the action). If you later want attribution (“who enabled troubleshooting mode / changed settings”), we should pivot to Defender Action Center message and then confirm the user. The query can be used for generating alert using custom detection rule and take this alert to Security Operations center using API integration. Below is reference to the sample output of the query. 6) Summary Option 3 enables a controlled Troubleshooting Mode experience by combining Entra ID group-based user assignment, a custom Defender XDR role with minimal permissions, and device group scoping in MDE. With this approach, eligible users can troubleshoot only the intended devices and perform a limited, operationally safe set of actions, while policy creation/modification remains restricted. Audit and investigation are supported through MDE telemetry and device Action Center visibility, with the known limitation that certain telemetry entries may not include the initiating username.Using the Microsoft Defender for Endpoint Files API to Validate Malware Hashes
Introduction Security advisories frequently include file hashes (SHA-1 or SHA-256) as indicators of compromise (IoCs). Microsoft Defender for Endpoint (MDE) exposes a Files API that lets SecOps quickly look up Microsoft’s verdict and metadata for a given hash. This enables rapid assessment—whether a file is classified as Malicious, Suspicious, Clean, or Unknown—and helps analysts decide the next response action without needing to download or execute the sample. What is the Files API in MDE and why is it used in Security Operations? The Files API is part of the Defender for Endpoint REST APIs that returns a file profile by hash identifier. Analysts use it to: • Validate whether Microsoft has a global verdict for a hash named in an advisory. • Retrieve telemetry such as global prevalence and first/last observed times to gauge risk and spread. • Pivot to related alerts and devices when needed. This lookup shortens triage time and avoids unnecessary handling of potentially dangerous samples. Prerequisites To call the Files API using application (client credentials) context, you need: A Microsoft Entra ID App Registration (Web app / service). API permissions on the WindowsDefenderATP resource (Microsoft Defender for Endpoint). Minimum: File.Read.All (Application). Admin consent granted for the permissions. Network access to the MDE API endpoint (region-based base URL) and the Microsoft identity platform (OAuth 2.0). Tip: For interactive testing, you can also use the API Explorer in the Microsoft Defender portal under Partners & APIs, which runs requests under your user context and RBAC scope. How to use the Files API via PowerShell 1) Acquire an OAuth token from the Microsoft identity platform using your app’s client ID and secret with the .default scope for the Defender API. 2) Send an HTTP GET request to the Files endpoint with the hash (SHA-1 or SHA-256) as the identifier. 3) Inspect the JSON response field "fileClassification" and other metadata (globalPrevalence, first/last observed). 4) Use the verdict to decide next actions (e.g., create an Indicator to block, hunt in Advanced Hunting, or open related alerts). Actual Script ===== STEP 1: Get OAuth Token (MDE v1) ===== $tenantId = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" $appId = "xxxxxxxxxxxxxxxxxxxxxxxxxxx" $appSecret = "xxxxxxxxxxxxxxxxxxxxxxxxxxx" # update with your tenant and app values $tokenUri = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" $body = @{ client_id = $appId scope = "https://api.securitycenter.microsoft.com/.default" client_secret = $appSecret grant_type = "client_credentials" } $tokenResponse = Invoke-RestMethod -Uri $tokenUri -Method Post -Body $body -ContentType "application/x-www-form-urlencoded" $token = $tokenResponse.access_token # ===== STEP 2: Call MDE v1 Files API ===== $hash = "97bf5e1a903a978b2281496e0a897688e9d8e6f981238cf91e39bae20390defe" # Replace with your actual hash values. $uri = "https://api.securitycenter.microsoft.com/api/v1.0/files/$hash" try { $response = Invoke-RestMethod -Uri $uri -Headers @{ Authorization = "Bearer $token" Accept = "application/json" } -Method Get } catch { Write-Error "API call failed: $($_.Exception.Message)" if ($_.ErrorDetails.Message) { Write-Host $_.ErrorDetails.Message } return } switch ($response.fileClassification) { "Malicious" { Write-Host "MDE recognises this hash as MALICIOUS. Threat Name: $($response.threatName)" -ForegroundColor Red } "Suspicious" { Write-Host "MDE recognises this hash as SUSPICIOUS." -ForegroundColor Yellow } "Clean" { Write-Host "MDE recognises this hash as CLEAN." -ForegroundColor Green } default { Write-Host "MDE does NOT have a signature for this hash (Unknown)." -ForegroundColor Gray } } $response | ConvertTo-Json -Depth 5 Script Explanation Token acquisition: Uses OAuth 2.0 client credentials flow to obtain an access token; scope targets Defender for Endpoint API. Endpoint call: Builds a GET request to the Files endpoint with the hash identifier. Error handling: Catches HTTP errors and prints server-provided details if available. Verdict mapping: Reads the fileClassification field and prints a color-coded verdict (Malicious, Suspicious, Clean, Unknown). Response output: Prints the full JSON for deeper analysis and logging. Recommended Inputs The Files endpoint accepts SHA-1 or SHA-256 identifiers; ensure you pass the correct hash type. Consider using certificate credentials or managed identity instead of client secrets for production automation. Sample Output API Explorer - Other Option to query File API The Microsoft Defender for Endpoint API Explorer is a tool that helps you explore various Defender for Endpoint APIs interactively. The API Explorer makes it easy to construct and do API queries, test, and send requests for any available Defender for Endpoint API endpoint. Use the API Explorer to take actions or find data that might not yet be available through the user interface. The tool is useful during app development. It allows you to perform API queries that respect your user access settings, reducing the need to generate access tokens. You can also use the tool to explore the gallery of sample queries, copy result code samples, and generate debug information. With the API Explorer, you can: Run requests for any method and see responses in real-time. Quickly browse through the API samples and learn what parameters they support. Make API calls with ease; no need to authenticate beyond the management portal signin. Access API Explorer From the left navigation menu, select Partners & APIs > API Explorer. Supported APIs API Explorer supports all the APIs offered by Defender for Endpoint. The list of supported APIs is available in the APIs documentation. Get started with the API Explorer In the left pane, there's a list of sample requests that you can use. Follow the links and click Run query. Some of the samples may require specifying a parameter in the URL, for example, {File Hash}. Permissions Required You need to log in with an account that has appropriate RBAC roles in Microsoft Defender for Endpoint. API Explorer enforces the same role-based access control (RBAC) as the portal: Security Administrator or Global Administrator for high-privilege actions (e.g., offboarding a device, submitting indicators). Lower roles (e.g., Security Reader) can only run read-only queries like Get file information or Get alerts. No additional API permissions or app registration are needed because requests run under your user context. Conclusion The MDE Files API gives SecOps an immediate way to validate hashes from advisories and threat feeds, reducing time-to-triage and enabling consistent response. When a hash is classified as Malicious or Suspicious, teams can move directly to containment (e.g., creating an Indicator to block). When it is Clean or Unknown, analysts can pivot to hunting, sandboxing, or further intelligence before acting. Integrating this lookup into runbooks helps security operations quickly and safely respond to emerging threats. References Get file information API: https://learn.microsoft.com/en-us/defender-endpoint/api/get-file-information Supported MDE APIs (Endpoint URI & versioning): https://learn.microsoft.com/en-us/defender-endpoint/api/exposed-apis-list Access the Microsoft Defender for Endpoint APIs (intro & app context): https://learn.microsoft.com/en-us/defender-endpoint/api/apis-intro Create an app to access MDE without a user (app registration & permissions): https://learn.microsoft.com/en-us/defender-endpoint/api/exposed-apis-create-app-webapp API Explorer: https://learn.microsoft.com/en-us/defender-endpoint/api/api-explorerMDE for Non‑Persistent VDI — Implementation Guide & Best Practices.
1. Overview: Microsoft Defender for Endpoint (MDE) for Non‑Persistent VDI Non‑persistent VDI instances are reset or reprovisioned frequently. To ensure immediate protection and clean device inventory, MDE provides a dedicated onboarding path that calculates a persistent device ID and onboard early in the boot process. Key considerations: Use the VDI onboarding package and choose the single‑entry method (recommended) to avoid duplicate devices when hosts are recreated with the same name. Place the onboarding script in the golden image but ensure it executes only on child VMs (first boot) after the final hostname is assigned and the last reboot completes. Never fully onboard or boot the golden/template/replica image into production; if it happens, offboard and clean registry artifacts before resealing. Consider enabling the portal feature “Hide potential duplicate device records” to reduce inventory noise during transition periods. 2. Stage the scripts in the Golden Image (do NOT onboard the image) Goal: Ensure early, reliable onboarding of pooled VDI instances without tattooing the master image. Download the Windows onboarding package (Deployment method: VDI onboarding scripts for non‑persistent endpoints). Extract and copy the files to: C\Windows\System32\GroupPolicy\Machine\Scripts\Startup Configure Local/Domain GPO to run the PowerShell script at startup (SYSTEM, highest privileges). For single‑entry, add Onboard-NonPersistentMachine.ps1 on the PowerShell Scripts tab. Ensure the script runs only after final hostname and the last reboot in your provisioning flow to prevent duplicate objects. Example (Domain GPO scheduled task at startup as SYSTEM): Program/Script: C\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Arguments: -ExecutionPolicy Bypass -File \srvshare\onboard\Onboard-NonPersistentMachine.ps1 3. Never Onboard the Golden/Template/Replica VM If the golden image was accidentally onboarded (Sense service started), you must offboard and clean before resealing: sc query sense del "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Cyber\*.*" /f /s /q reg delete "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection" /v senseGuid /f Run the official offboarding script for your tenant before cleanup, when available. 4. (Optional) Tag Devices Automatically from the Image Tags simplify scoping of device groups and policies. Add a DeviceTagging registry value during image build: reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging" /v Group /t REG_SZ /d "VDI-NonPersistent" /f Tag appears after device info refresh; a reboot accelerates reporting. 5. Performance & AV Configuration for VDI (Important) 5.1 Shared Security Intelligence & Cache Maintenance Purpose: Reduce CPU and disk spikes at sign‑in by offloading unpackaging of definitions to a shared source and by pre‑running cache maintenance on the master image. Step‑by‑step GPO configuration: Create a secure UNC share for definition packages (e.g., \srvshare\WDAV-Update) and grant read to VDI computer accounts. GPO → Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Security Intelligence Updates → Enable “Define security intelligence location for VDI clients” and set \srvshare\WDAV-Update. In the same node, set update cadence (daily time) and enable randomization to avoid I/O storms. PowerShell examples: Set-MpPreference -SignatureUpdateInterval 4 Set-MpPreference -SignatureFallbackOrder "InternalDefinitionUpdateServer|MicrosoftUpdateServer" Run Windows Defender Cache Maintenance on the golden image before sealing: schtasks /Run /TN "\Microsoft\Windows\Windows Defender\Windows Defender Cache Maintenance" 5.2 FSLogix Exclusions Why exclusions matter: FSLogix mounts user profiles as VHD/VHDX files. Scanning these at attach/detach causes logon delays, black screens, and app launch slowness. Paths and extensions to exclude: %TEMP%\*.VHD %TEMP%\*.VHDX %Windir%\TEMP\*.VHD %Windir%\TEMP\*.VHDX \\<storage>\<share>\*.VHD \\<storage>\<share>\*.VHDX \\<storage>\<share>\*.VHD.lock \\<storage>\<share>\*.VHD.meta \\<storage>\<share>\*.VHD.metadata \\<storage>\<share>\*.VHDX.lock \\<storage>\<share>\*.VHDX.meta \\<storage>\<share>\*.VHDX.metadata GPO: Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Exclusions (File/Folder and Extension). PowerShell examples: Add-MpPreference -ExclusionExtension VHD,VHDX Add-MpPreference -ExclusionPath "C:\ProgramData\FSLogix","\\storage\fslogix-share\*.VHD*" 5.3 General Scan Posture Real‑time & cloud‑delivered protection (GPO): Enable Real‑time protection, Cloud‑delivered protection, Join MAPS, and “Block at first sight.” Scheduled scans (GPO): Daily Quick Scan (e.g., 02:00) with randomization window. Weekly Full Scan (e.g., Sunday 03:00). Consider “Start the scheduled scan only when computer is on but not in use” to reduce user impact. CPU throttling settings: Set-MpPreference -ScanAvgCPULoadFactor 30 # 5..100 (0 = no throttling) Additional scheduling/throttling options (Intune/Policy CSP as applicable): ScanOnlyIfIdleEnabled = True DisableCpuThrottleOnIdleScans = True ThrottleForScheduledScanOnly = True EnableLowCPUPriority = True Validation commands: Get-MpPreference | fl ScanAvgCPULoadFactor,ScanScheduleQuickScanTime,SignatureUpdateInterval Get-MpComputerStatus | fl AMServiceEnabled,AntivirusSignatureVersion,RealTimeProtectionEnabled 6. Validate Onboarding After first boot of a pooled VM, verify device appears in Defender portal (Assets → Devices). For single‑entry method, reboot/redeploy a few instances with the same hostname and confirm one device object is reused. Optionally enable “Hide potential duplicate device records” (Settings → Endpoints → Advanced features). This is like only filtering the view of Devices list does actual remove the records from the MDE portal. Run a detection test if needed (per Microsoft guidance) to verify sensor connectivity. 7. Quick Checklist — Build Step Download VDI onboarding package from Defender portal. Copy scripts to Startup folder in golden image; configure GPO/Task to run PS1 at boot as SYSTEM. Do NOT onboard/boot the golden image into production; if it happens, offboard + clean senseGuid & Cyber cache. (Optional) Set DeviceTagging registry value for scoping (e.g., VDI-NonPersistent). Configure Shared Security Intelligence path; schedule updates; run Cache Maintenance on master image. Apply FSLogix AV exclusions (paths + extensions). Set scan posture (RTP + cloud, schedules, CPU throttling). Validate onboarding behavior and inventory cleanliness. 8. Summary & Best Practices Checklist for golden image: Script staged, not executed on master; executes only on child VMs at final boot stage. Shared Security Intelligence path configured; cache maintenance pre-run. FSLogix exclusions present prior to first user logon. RTP and cloud protection enabled; scans scheduled with randomization; CPU load factor tuned. Common pitfalls & fixes: Golden image onboarded → Offboard + clean registry/cache; reseal. Script runs before final hostname → Duplicate device records. Delay script until last reboot/final rename. No exclusions for FSLogix → Long logons/black screens. Add VHD/VHDX exclusions and share paths. Simultaneous scans across hosts → Enable randomization; schedule during off‑hours. References Onboard non‑persistent VDI devices: https://learn.microsoft.com/en-us/defender-endpoint/configure-endpoints-vdi Onboard Windows devices in Azure Virtual Desktop: https://learn.microsoft.com/en-us/defender-endpoint/onboard-windows-multi-session-device Configure Microsoft Defender Antivirus on RDS/VDI: https://learn.microsoft.com/en-us/defender-endpoint/deployment-vdi-microsoft-defender-antivirus FSLogix prerequisites (AV exclusions): https://learn.microsoft.com/en-us/fslogix/overview-prerequisites Configure AV exclusions (file/extension/folder): https://learn.microsoft.com/en-us/defender-endpoint/configure-extension-file-exclusions-microsoft-defender-antivirus Create and manage device tags: https://learn.microsoft.com/en-us/defender-endpoint/machine-tags Advanced features (hide duplicate records): https://learn.microsoft.com/en-us/defender-endpoint/advanced-features Schedule antivirus scans using Group Policy: https://learn.microsoft.com/en-us/defender-endpoint/schedule-antivirus-scans-group-policy Troubleshoot MDAV scan issues (CPU throttling, idle scans): https://learn.microsoft.com/en-us/defender-endpoint/troubleshoot-mdav-scan-issuesMicrosoft Defender for Endpoint (MDE) Live Response and Performance Script.
Importance of MDE Live Response and Scripts Live Response is crucial for incident response and forensic investigations. It enables analysts to: Collect evidence remotely. Run diagnostics without interrupting users. Remediate threats in real time. For more information on MDE Live Response visit the below documentation. Investigate entities on devices using live response in Microsoft Defender for Endpoint - Microsoft Defender for Endpoint | Microsoft Learn PowerShell scripts enhance this capability by automating tasks such as: Performance monitoring. Log collection. Configuration validation. This automation improves efficiency, consistency, and accuracy in security operations. For more details on running performance analyzer visit the below link. Performance analyzer for Microsoft Defender Antivirus - Microsoft Defender for Endpoint | Microsoft Learn While performance analyzer is run locally on the system to collect Microsoft Defender Anti-Virus performance details , in this document we are describing on running the performance analyzer from MDE Live Response console. This is a situation where Security administrators do not have access to the servers managed by Infra administrators. Prerequisites Required Roles and Permissions To use Live Response in Microsoft Defender for Endpoint (MDE), specific roles and permissions are necessary. The Security Administrator role, or an equivalent custom role, is typically required to enable Live Response within the portal. Users must possess the “Manage Portal Settings” permission to activate Live Response features. Permissions Needed for Live Response Actions Active Remediation Actions under Security Operations: Take response actions Approve or dismiss pending remediation actions Manage allowed/blocked lists for automation and indicators Unified Role-Based Access Control (URBAC): From 16/02/2025, new customers must use URBAC. Roles are assigned to Microsoft Entra groups. Access must be assigned to device groups for Live Response to function properly. Setup Requirements Enable Live Response: Navigate to Advanced Features in the Defender portal. Only users with the “Manage Portal Settings” permission can enable this feature. Supported Operating System Versions: Windows 10/11 (Version 1909 or later) Windows Server (2012 R2 with KB5005292, 2016 with KB5005292, 2019, 2022, 2025) macOS and Linux (specific minimum versions apply) Actual Script Details and Usage The following PowerShell script records Microsoft Defender performance for 60 seconds and saves the output to a temporary file: # Get the default temp folder for the current user $tempPath = [System.IO.Path]::GetTempPath() $outputFile = Join-Path -Path $tempPath -ChildPath "DefenderTrace.etl" $durationSeconds = 60 try { Write-Host "Starting Microsoft Defender performance recording for $durationSeconds seconds..." Write-Host "Recording will be saved to: $outputFile" # Start performance recording with duration New-MpPerformanceRecording -RecordTo $outputFile -Seconds $durationSeconds Write-Host "Recording completed. Output saved to $outputFile" } catch { Write-Host "Failed to start or complete performance recording: $_" } 🔧 Usage Notes: Run this script in an elevated PowerShell session. Ensure Defender is active, and the system supports performance recording. The output .etl file can be analyzed using performance tools like Windows Performance Analyzer. Steps to Initiate Live Response Session and Run the script. Below are the steps to initiate a Live Response session from Security.Microsoft.com portal. Below screenshot shows that console session is established. Then upload the script file to console library from your local system. Type “Library” to list the files. You can see that script got uploaded to Library. Now you execute the script by “run <file name>” command. Output of the script gets saved in the Library. Run “getfile <path of the file>” to get the file downloaded to your local system download folder. Then you can run Get-MpPerformanceReport command from your local system PowerShell as shown below to generate the report from the output file collected in above steps. Summary and Benefits This document outlines the use of MDE Live Response and PowerShell scripting for performance diagnostics. The provided script helps security teams monitor Defender performance efficiently. Similar scripts can be executed from Live Response console including signature updates , start/stop services etc. These scripts are required as a part of security investigation or MDE performance troubleshooting process. Benefits: Faster incident response through remote diagnostics. Improved visibility into endpoint behaviour. Automation of routine performance checks. Enhanced forensic capabilities with minimal user disruption.Understanding Device Control for macOS in Defender for Endpoint
Step-by-step implementation guide Requirements for Implementing Device Control: Defender for Endpoint or Defender for Business licenses (can be a trial subscription) Minimum OS version: macOS 11 or higher Minimum product version: 101.34.20 The implications of these requirements are that first, the macOS devices need to be onboarded in Defender for Endpoint for the Device Control policies to be enforced, secondly the OS needs to be at certain level or higher and third the minimum product version required, implies that the Defender app needs to be installed on the macOS device. Another aspect to take into consideration is that Defender can be running in active or passive mode for Device Control to work. Check the feature comparison table in this article to view how the Defender for Endpoint features behave when Defender is running active or passive mode. For this guide, I would like to focus on how we implement the policies for Device Control on macOS devices using Microsoft Intune. When deploying Device Control using Microsoft Intune, you have the advantage of using a native platform that integrates with Defender XDR portal and EntraID. Integrating device control into this broader security framework is crucial for maintaining a robust defense against potential threats. Considerations for Device Control to be effective and allow a smooth onboarding of devices: Your MacOS devices must be running at least macOS 11.x or higher. You will need a Microsoft365 subscription to be able to license your devices for Defender for Endpoint. To access and use Removable Storage Access Control, you must have Microsoft 365 E3 or E5. The Defender app needs to be installed and licensed (the device went through the onboarding process) on the macOS device. The main difference between Windows OS devices and macOS devices is that in Windows OS, the Defender application is part of the core OS and in macOS it needs to be installed as a regular application you can install on the device, preferably through Microsoft Intune. After the devices are onboarded in Defender for Endpoint, the devices will appear in EntraID as a synthetic object, meaning that you will see the “join type” field as blank. This allows you to group these devices in EntraID dynamic groups to automate the app deployment process. To enable devices to get endpoint security management settings from either Microsoft Intune or Defender portal, you need to enable to configure your tenant to support Defender for Endpoint security settings management. Older versions of Mac devices’ hardware, as long as they can support macOS 11.x or higher, can run the feature. The performance of the feature will depend on how the hardware performs, due to the fact that it is an outdated device. In order to apply device control policies, the device needs to be onboarded in Defender for Endpoint. Just applying the .mobileconfig file directly to the device or the .json file if using JAMF will not cause any effect on the device. To learn more about the .mobileconfig file and .json file, please refer to these articles. .mobileconfig and .json files. One of the key differences with Device control implementation in other operating systems like macOS is that the configuration is done via Microsoft Intune device configuration profile. This experience is not yet available in Defender portal. This guide applies for macOS devices managed by Intune. To further understand the pre-requisites for Device Control for macOS on Defender for Endpoint, please refer to this article. Process of deploying Defender for Endpoint app on macOS to prepare for device control policies Now, after you get all the pre-requisites aligned and ready to go, it is time to start preparing the environment in Intune for Device Control. Configuration Steps Install Microsoft Defender for Endpoint on macOS: Ensure that Microsoft Defender for Endpoint is installed and running on your macOS devices. You can follow the installation guide available on the Microsoft Learn website. This process is described in Fig.1 2. Build the MobileConfig File: Create a mobileconfig file that includes the necessary groups, rules, and settings for device control. You can use the demo file available on GitHub as a reference:. This file serves as a useful starting point for developing how the policy should function on the device. Validate your policy with the JSON schema to ensure the format is correct: https://github.com/microsoft/mdatp-devicecontrol/device_control_policy_schema.json 3. Deploy the MobileConfig File Using Intune: Sign in to the Microsoft Intune admin center and navigate to Devices > macOS. Select 'Create profile', choose 'Templates', and then 'Custom'. Upload the mobileconfig file you created in the previous step Configure Device Control Policies: Open the Microsoft Intune admin Center and navigate to the Device configuration section. Create a new policy for macOS devices. Specify the types of devices you want to control (e.g., USB drives, external hard drives). Set the permissions for each device type. You can choose to allow, block, or restrict access based on various criteria such as device ID, vendor ID, or serial number. 5. Deploy the Policy: Once the policy is configured, deploy it to the targeted macOS devices. Ensure that the devices are connected to the internet and can receive policy updates from the Microsoft Defender portal or Microsoft Intune. 6. Monitor and Manage Devices: Use the Microsoft Defender portal to monitor the status of connected devices. You can view the Device control report in Defender portal to track device usage and identify any unauthorized access attempts. You can also perform advanced hunting in Defender portal to monitor when a policy was triggered. Below I list a couple of KQL queries that can help with this monitoring. Example 1: Discover if the removable storage policy was triggered: Note: Before running, check spaces and syntax of the query is ok after copying and pasting the query in Advanced Hunting, to prevent errors. //RemovableStoragePolicyTriggered: event triggered by Disk and file system level enforcement for both Printer and Removable storage based on your policy DeviceEvents | where ActionType == "RemovableStoragePolicyTriggered" | extend parsed=parse_json(AdditionalFields) | extend RemovableStorageAccess = tostring(parsed.RemovableStorageAccess) | extend RemovableStoragePolicyVerdict = tostring(parsed.RemovableStoragePolicyVerdict) | extend MediaBusType = tostring(parsed.BusType) | extend MediaClassGuid = tostring(parsed.ClassGuid) | extend MediaClassName = tostring(parsed.ClassName) | extend MediaDeviceId = tostring(parsed.DeviceId) | extend MediaInstanceId = tostring(parsed.DeviceInstanceId) | extend MediaName = tostring(parsed.MediaName) | extend RemovableStoragePolicy = tostring(parsed.RemovableStoragePolicy) | extend MediaProductId = tostring(parsed.ProductId) | extend MediaVendorId = tostring(parsed.VendorId) | extend MediaSerialNumber = tostring(parsed.SerialNumber) |project Timestamp, DeviceId, DeviceName, InitiatingProcessAccountName, ActionType, RemovableStorageAccess, RemovableStoragePolicyVerdict, MediaBusType, MediaClassGuid, MediaClassName, MediaDeviceId, MediaInstanceId, MediaName, RemovableStoragePolicy, MediaProductId, MediaVendorId, MediaSerialNumber, FolderPath, FileSize | order by Timestamp desc Example 2: This query interrogates the DeviceEvents table, searching for “PnP” (Plug n Play) types of action. The field Additional fields provides essential information about the device ClassGUID and what .inf files are part of the driver stack used to perform the action. DeviceEvents | where ActionType contains "PnP" | where Timestamp > ago(30d) | project ActionType, DeviceName, InitiatingProcessAccountUpn, InitiatingProcessAccountDomain, IsProcessRemoteSession, AdditionalFields // the Additional Fields field shows the DeviceGUID, ClassGUID, driver information, etc. In conclusion: In today's fast-paced and mobile-driven world, device control stands out as an essential security feature for organizations and individuals alike. By enabling device control, businesses can ensure a seamless protection experience, safeguarding sensitive data against unauthorized access or potential threats posed by removable and portable devices. Its cross-platform functionality, spanning Windows, macOS, and beyond, highlights its adaptability and relevance in a diverse technological landscape. Furthermore, device control fosters a proactive approach to cybersecurity, by enabling device control, organizations can proactively safeguard sensitive data and mitigate risks before they escalate. Enabling this feature not only strengthens your security posture but also demonstrates a commitment to protecting the integrity and privacy of your systems in an increasingly unpredictable digital ecosystem. Explore additional resources: To further enhance your understanding of the critical role Device Control plays in safeguarding your organization, explore these indispensable resources on Defender for Endpoint. Empower yourself with the knowledge to proactively secure sensitive data, mitigate risks, and stay ahead in an ever-evolving digital landscape. How to deploy Defender app to macOS endpoints using Intune. Implementing device control on macOS guidelines. Defining settings on your mobileconfig file. Best practices to deploy device control for macOS on Defender for Endpoint. FAQ about device control on macOS. How to deploy device control from Defender for Endpoint using JAMF.
