Bulk Device Tagging in MDE: PowerShell & API Approach
Effective device management is critical for ensuring security hygiene and maintaining operational agility within enterprise environments. In Microsoft Defender for Endpoint (MDE), device tagging plays a key role by enabling logical grouping, targeted policy application, efficient incident response, compliance tracking, and automation. It elevates device management from a manual, error-prone process to a scalable, context-aware workflow that aligns with both security and operational objectives. This guide presents a streamlined method for bulk tagging devices in MDE using the API and PowerShell automation. By following the outlined steps, security teams can automate the tagging process, minimize manual work, and maintain consistent device categorization to support compliance, reporting, and policy enforcement. Objective Use Microsoft Defender for Endpoint API to add tags for multiple devices efficiently. Step 1: Create App Registration in Entra ID Go to Entra ID (Azure Active Directory) → App registrations → New registration. Enter: Name: e.g., MDE-Auto-Tagging. Supported account types: Choose Single tenant (or multi-tenant if required). Redirect URI: Leave blank for now (not needed for client credentials flow). Click Register. Note down: Application (Client) ID Directory (Tenant) ID Step 2: Create Client Secret In the registered app → Certificates & secrets → New client secret. Add description and expiry (e.g., 6 months or 12 months). Copy the Value immediately (you won’t see it again). Step 3: Assign API Permissions In the app → API permissions → Add a permission. Select: APIs my organisation uses → Search for WindowsDefenderATP. Choose: Machine.ReadWrite.All (required for tagging). Application permissions → Expand Machine → Select: Click Add permissions. Grant admin consent for your organisation. Step 4: Validate Permissions Ensure status shows Granted for . (as shown below) If not, click Grant admin consent again. Step 5: Use PowerShell Script to apply tags to multiple devices Please review the PowerShell script hosted here: Microsoft-Unified-Security-Operations-Platform/Microsoft Defender for Endpoint/AddBulkTags.ps1 at main · Abhishek-Sharan/Microsoft-Unified-Security-Operations-Platform This script: Fetches Bearer token using Client ID, Tenant ID, and Client Secret. Reads Device IDs from CSV. Applies tags to each device via Defender API. How to Run (I am using Azure Shell for demo) Update the script with: $TenantId, $ClientId, $ClientSecret and Tag Value Path to your CSV file containing DeviceId. Upload MachineIDs.csv in Azure Shell, template shown below (line 2 and 3 are DeviceIDs) Upload the PowerShell script in Azure Shell as well Execute the PowerShell script, read the Disclaimer and provide your consent for further execution if you’re comfortable As shown below, it will apply the tags. Step 6: Validate tags Go to Devices page and check if the tags are applied or not. Security Best Practices Rotate client secrets regularly. Restrict app permissions to only what’s needed. Store secrets securely (e.g., Azure Key Vault). By implementing this automated tagging workflow, organisations can significantly simplify device management within MDE. Regularly rotating client secrets, restricting app permissions, and securely storing credentials are recommended best practices to maintain a robust security posture. With PowerShell automation and API integration, bulk tagging becomes a scalable solution—enabling teams to efficiently update device tags and leverage exclusion lists, ultimately saving time and reducing operational overhead. Reference Documentation: Add or remove a tag for multiple machines - Microsoft Defender for Endpoint | Microsoft Learn
Solving Network Connectivity for MDE and MDI
Hi, I’m Will Sykes, a Senior Security Researcher in Microsoft IR. My colleagues and I specialize in helping customers with incident response and compromise recovery. In our work with customers who’ve been the victim of cyberattack, we often must solve connectivity issues to support tools in a hybrid cloud configuration. Hybrid Cloud Challenges In today’s IT world we’re now implementing and integrating services that leverage cloud computing components. Correctly securing this often defies the adage of “never allow internet connectivity to sensitive systems” and can pose challenges to security and systems administrators to find a solution. In this article we’re going to cover a potential solution to allow the communication traffic for Microsoft Defender for Endpoint (MDE) and Microsoft Defender for Identity (MDI) in a more secure manner, while simultaneously disallowing the operating system to reach the internet. MDE and MDI MDE and MDI are both cloud powered solutions that need to run on all assets (MDE) and Tier 0 assets (MDI). To function these products must be connected to Azure endpoints, however the number of endpoints (MDI, MDE) can be large. This poses a challenge to traditional firewalls that can’t do address-based filtering and rely on IP filtering. In addition, both services cannot function in an environment where SSL inspection is done on the traffic. Thankfully both solutions support a proxy server, and the greatest advantage here is that the proxy can be configured at the MDE/MDI application level and not at the operating system level. During an incident response (IR), Microsoft DART will often deploy MDE and MDI to support real time monitoring and automatic actions to evict threat actors. Depending on the current state of the organization it may not be possible to reconfigure existing firewalls or proxies to support the new configuration. Because of the rapid nature of an IR and the need to have clear consistent network communication data from our toolset we needed an “in a box” solution. The Proxy Solution Because it’s possible to configure MDE and MDI to use a proxy without relying on the system configuration we developed a preconfigured Squid proxy solution that can be deployed automatically via a shell script in a fully configured setup. Let’s look at the parts of this solution. Operating System and Software To use the proxy, you’ll need to create an Ubuntu Linux server. Any version greater than 18.04 will do, and this can be physical or virtual. You’ll need to size the machine based on your expected load; in our experience we’ve run tens of thousands of endpoints through a proxy with 4 CPU cores and 16 GB of memory. The automation script will enable the Uncomplicated Firewall (UFW) and allow ports 22 for SSH and 3128 for Squid. The Squid install is basic; the configuration and the tuning is done via the script. The deploy script will build an endpoint file at /etc/squid/mdemdi.conf which contains the list of required cloud endpoints for MDE and MDI. It then creates a squid configuration file at /etc/squid/squid.conf with some defaults and lockdowns: The hosts allowed to use the firewall are the RFC 1918 internal networks. This can be scoped down or reconfigured depending on your network needs. The only destinations allowed by the proxy are in the mdemdi.conf file, every other destination is denied and only HTTP/HTTPS is allowed. Lastly the script will add some operating system tuning to support deployments in large environments based on our IR experiences. Internal Network Configuration Once you have the proxy configured, you’ll need to ensure that it can connect outbound to the internet unfiltered. If you have SSL filtering enabled on the proxy this will still cause MDE and MDI to fail communications. The proxy is configured to deny all internet destinations not needed by MDE and MDI, so this is a compensating control to avoid having unfiltered internet access. Of course, you can also add the identical filters to the network security devices allowing the proxy outbound internet. The next configuration step is to allow your internal networks to communicate to the proxy on TCP 3128, which is the configured listener for Squid. Configuring MDE and MDI MDE and MDI Version 3 To configure MDE you can use Group Policy to either use the native template or to manage the underlying Windows registry values. The setting can be found at Administrative Templates > Windows Components > Microsoft Defender Antivirus > Define proxy server for connecting to the network. And at Administrative Templates > Windows Components > Data Collection and Preview Builds > Configure connected user experiences and telemetry If you need to configure devices not managed by Group Policy you can manage the following registry values: HKLM\Software\Policies\Microsoft\Windows Defender\ProxyServer This is a registry value of type REG_SZ and takes the following string format: http://<server name or IP>:<port> HKLM\Software\Policies\Microsoft\Windows\DataCollection\TelemetryProxyServer This is a registry value of type REG_SZ and takes the following string format: servername:port or ip:port That’s it! Once that’s done you can confirm connectivity in the Windows Event View in the Applications and Services Logs -> Microsoft -> Windows -> Windows Defender -> Operational log. MDI Version 2 MDI can be installed directly with the proxy, however this must be done on the command line and not through the GUI. To do this add the ProxyUrl=" http://<server name or IP>:<port>" option the installer parameters. If you’ve already installed MDI and need to reconfigure the proxy that’s perfectly fine! You can use the handy MDI PowerShell Module's Set-MDISensorProxyConfiguration cmdlet or the built in utility Microsoft.Tri.Sensor.Deployment.Deployer.exe. Conclusion Based on our experiences in incident response, connectivity issues can slow or block vital security tools. The proxy solution allows network administrators to utilize a pre-configured appliance type solution to support MDE and MDI without having to modify existing security rulesets. A systems administrator can simplify their deployment of MDE or MDI by including the proxy solution as part of the application bundle, where its lifecycle can be tracked in lockstep with the application. Now the moment you’ve all been waiting for! The script can be downloaded at https://github.com/mswillsykes/squidmdemdi. Disclaimer The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Update Entra ID Device Extension Attributes via PowerShell & Create Dynamic Security Groups.
2) Overview of Extension Attributes and Updating via PowerShell What Are Extension Attributes? Extension attributes (1–15) are predefined string fields available on Entra ID device objects. They are exposed to Microsoft Graph as the extensionAttributes property. These attributes can store custom values like department, environment tags (e.g., Prod, Dev), or ownership details. Why Use Them? Dynamic Group Membership: Use extension attributes in membership rules for security or Microsoft 365 groups. Policy Targeting: Apply Defender for Endpoint (MDE) policies, Conditional Access or Intune policies to devices based on custom tags. For details on configuration of the policies refer below documentation links. https://learn.microsoft.com/en-us/defender-endpoint/manage-security-policies https://learn.microsoft.com/en-us/intune/intune-service/ https://learn.microsoft.com/en-us/entra/identity/conditional-access/ Updating Extension Attributes via PowerShell and Graph API Use Microsoft Graph PowerShell to authenticate and update device properties. Required permission: “Device.ReadWrite.All”. 3) Using PowerShell to Update Extension Attributes create app registration in Entra ID with permissions Device.ReadWriteall and Grant admin Consent. Register an app How to register an app in Microsoft Entra ID - Microsoft identity platform | Microsoft Learn Graph API permissions Reference. For updating Entra ID device properties you need “Device.ReadWrite.all” permission and Intune administrator role to run the script. Microsoft Graph permissions reference - Microsoft Graph | Microsoft Learn Below is the script Important things to note and update the script with your custom values. a) update the path of the excel file in the script. column header is 'DeviceName' Note: You may want to use CSV instead of excel file if Excel is not available on the admin workstation running this process. b) update the credential details - tenantId,clientId & clientSecret in the script. Client id and client secret are created as a part of app registration. c) update the Externsionattribute and value in the script. This is the value of the extension attribute you want to use in dynamic membership rule creation. ___________________________________________________________________________ #Acquire token $tenantId = "xxxxxxxxxxxxxxxxxxxxx" $clientId = "xxxxxxxxxxxxxxxx" $clientSecret = "xxxxxxxxxxxxxxxxxxxx" $excelFilePath = "C:\Temp\devices.xlsx" # Update with actual path $tokenResponse = Invoke-RestMethod -Uri "https://login.microsoftonline.com/ $tenantId/oauth2/v2.0/token" -Method POST -Body $tokenBody $accessToken = $tokenResponse.access_token # Import Excel module and read device names Import-Module ImportExcel $deviceList = Import-Excel -Path $excelFilePath foreach ($device in $deviceList) { $deviceName = $device.DeviceName # Assumes column header is 'DeviceName' Get device ID by name $headers = @{ "Authorization" = "Bearer $accessToken"} $deviceLookupUri = "https://graph.microsoft.com/beta/devices?`$filter=displayName eq '$deviceName'" try { $deviceResponse = Invoke-RestMethod -Uri $deviceLookupUri -Headers $headers -Method GET } catch { Write-Host "Error querying device: $deviceName - $_" continue } if ($null -eq $deviceResponse.value -or $deviceResponse.value.Count -eq 0) { Write-Host "Device not found: $deviceName" continue } $deviceId = $deviceResponse.value[0].id # Prepare PATCH request $uri = "https://graph.microsoft.com/beta/devices/$deviceId" $headers["Content-Type"] = "application/json" $body = @{ extensionAttributes = @{ extensionAttribute6 = "MDE" } } | ConvertTo-Json -Depth 3 try { $response = Invoke-RestMethod -Uri $uri -Method Patch -Headers $headers -Body $body Write-Host "Updated device: $deviceName"} catch { Write-Host "Failed to update device: $deviceName - $_" } } Write-Host "Script execution completed." ________________________________________________________________________________________________________________________ Here’s a simple summary of what the script does: Gets an access token from Microsoft Entra ID using the app’s tenant ID, client ID, and client secret (OAuth 2.0 client credentials flow). Reads an Excel file (update the path in $excelFilePath, and ensure the column header is DeviceName) to get a list of device names. Loops through each device name from the Excel file: Calls Microsoft Graph API to find the device ID by its display name. If the device is found, sends a PATCH request to Microsoft Graph to update extensionAttribute6 with the value "MDE". Logs the result for each device (success or failure) and prints messages to the console. 4) Using Extension Attributes in Dynamic Device Groups Once extension attributes are set, you can create a dynamic security group in Entra ID: Go to Microsoft Entra admin center → Groups → New group. Select Security as the group type and choose Dynamic Device membership. Add a membership rule, for example: (device.extensionAttributes.extensionAttribute6 -eq "MDE") 4. Save the group. Devices with extensionAttribute6 = MDE will automatically join. 5) Summary Extension attributes in Entra ID allow custom tagging of devices for automation and policy targeting. You can update these attributes using Microsoft Graph PowerShell. These attributes can be used in dynamic device group rules, enabling granular MDE policies, Conditional Access and Intune deployments. Disclaimer This script is provided "as-is" without any warranties or guarantees. It is intended for educational and informational purposes only. Microsoft and the author assume no responsibility for any issues that may arise from the use or misuse of this script. Before deploying in a production environment, thoroughly test the script in a controlled setting and review it for compliance with your organization's security and operational policies.Microsoft 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.
