MDE Passive Mode — Operations Runbook

Overview

Microsoft Defender for Endpoint (MDE) is built into Windows 10/11 and Windows Server 2019+. Cortex XDR is the primary EDR on all Cirius Group Windows devices. When both are present, MDE must run in Passive Mode. This is not optional — Active Mode with Cortex XDR running has caused CPU saturation in production before.

---

1. What Passive Mode Is and Why It's Required

What Passive Mode Does

In Passive Mode, MDE (MsSense.exe / the Sense service):

• Continues scanning and telemetry collection
• Sends events to the M365 Defender portal and optionally to Log Analytics Workspace
• Provides compliance posture data and vulnerability assessment
• Does not quarantine files, block processes, or take remediation actions

Cortex XDR handles all active remediation: behavioral blocking, process kill, file quarantine, network isolation.

What Happens in Active Mode with Cortex XDR Running

Both agents attempt to own the endpoint protection role simultaneously:

• CPU saturation — both perform real-time scanning, both run behavioral engines. This has happened before. On production VMs with normal workloads the combined overhead can pin a CPU core.
• Double quarantine — a malicious file gets quarantined by Cortex, then MDE independently tries to quarantine or restore it. Race conditions produce unpredictable results: files in quarantine twice, alerts from both tools for the same event, or Cortex losing track of a file it already acted on.
• Alert duplication — Arctic Wolf sees MDE alerts and Cortex alerts for the same event, increasing noise and potentially triggering duplicate incidents in SecOps.
• Policy conflict — both engines maintain their own exclusion lists. A Cortex exclusion does not propagate to MDE and vice versa.

The Accepted Tradeoff

Running MDE in Passive Mode means surrendering MDE's active remediation capability. This is the correct call because:

1. Cortex XDR provides superior behavioral detection and is the contracted EDR.
2. MDE's passive telemetry still feeds the M365 Defender portal, giving visibility into device health, vulnerability posture, and compliance state.
3. Arctic Wolf has an MDE connector and consumes MDE data regardless of mode.
4. If Cortex XDR goes silent on a device, MDE automatically escalates to Active Mode as a failsafe — see Section 8.

---

2. How Passive Mode Is Enforced

Primary: Intune Configuration Profile

Portal path:Intune admin center → Endpoint security → Antivirus → Create policy

• Platform: Windows 10, Windows 11, and Windows Server
• Profile: Microsoft Defender Antivirus

Setting to configure:

Setting	Value
Allow Defender to run in passive mode	Enabled

This maps to the Defender CSP: ./Device/Vendor/MSFT/Policy/Config/Defender/AllowOnAccessProtection

Under the hood Intune writes the registry key described below. The profile must be assigned to All Devices (or the appropriate group covering all Intune-managed Windows devices).

Alternative profile path (if using Settings Catalog):

Intune admin center → Devices → Configuration → Create → Settings catalog

• Search: ForceDefenderPassiveMode
• Setting: Microsoft Defender Antivirus > ForceDefenderPassiveMode → Enabled (1)

Backup / Manual Verification Method: Registry Key

HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\ForceDefenderPassiveMode
Type: DWORD
Value: 1  (Passive Mode)
Value: 0  (Active Mode — should not be present on any device with Cortex XDR running)

This key is authoritative. When Intune pushes the policy it writes this key. You can read it directly on a device to confirm the policy applied.

Azure VMs: Defender for Servers

Azure VMs in subscriptions where Defender for Servers (Plan 1 or Plan 2) is enabled get MDE deployed automatically via the MDE extension (MDE.Windows). Intune does not manage Azure VMs in the same way — the passive mode setting for these VMs must be applied via one of:

• Azure Policy — custom policy writing the registry key via a guest configuration extension, or
• Run Command — one-time fix via Azure portal or az CLI, or
• Arc-connected VMs — if the VM is Arc-enrolled, Intune policy can reach it

For Azure VMs not Arc-enrolled, the registry key method is the operational fallback. See Section 5 for the full Azure VM procedure.

GPO Enforcement (domain-joined servers)

Intune covers Intune-managed devices, but domain-joined Azure/on-prem servers are enforced by GPO so that rebuilt servers inherit Passive Mode automatically — a rebuild can reset Defender to Active (this is what pegged VEEAMAZP01 at 100% CPU).

Run on a DC (BIZADSAZP01 / CGIADSAZP01) with Domain Admin rights:

.\scripts\Set-MDEPassiveMode.ps1 -ServersOU "OU=Servers,DC=ciriusgroup,DC=com"

The script is idempotent — it creates/updates the "MDE - Force Passive Mode (Cortex Primary)" GPO, writes the authoritative ForceDefenderPassiveMode = 1 value, and links it to the Servers OU. Use -WhatIf to preview. Do not link it to a Tier-0 / Domain Controller OU without confirming Cortex coverage there first.

---

3. Verifying Passive Mode Is Set Correctly

On an Individual Device (PowerShell)

Check the registry key directly:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection" -Name "ForceDefenderPassiveMode" -ErrorAction SilentlyContinue | Select-Object -ExpandProperty ForceDefenderPassiveMode

Expected output: 1 If the key is absent or the value is 0, the device is not in Passive Mode.

Check MDE running mode via Defender cmdlet:

Get-MpComputerStatus | Select-Object AMRunningMode

Expected output:

Value	Meaning
Passive	Correct — MDE is in Passive Mode
EDR Block Mode	Acceptable — MDE in EDR Block Mode (less common, still not competing with Cortex)
Normal	Problem — MDE is in Active Mode; Cortex XDR conflict risk
SxS Passive Mode	Side-by-side passive, also acceptable

Check Sense service status:

Get-Service -Name Sense | Select-Object Status, StartType

The Sense service should be Running. If it is stopped, MDE telemetry is not flowing regardless of mode.

One-liner for rapid triage across multiple keys:

[PSCustomObject]@{
    ForcePassiveMode = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection" -ErrorAction SilentlyContinue).ForceDefenderPassiveMode
    AMRunningMode    = (Get-MpComputerStatus).AMRunningMode
    SenseService     = (Get-Service Sense -ErrorAction SilentlyContinue).Status
    CortexRunning    = ((Get-Process -Name "cortex*" -ErrorAction SilentlyContinue) -ne $null)
} | Format-List

Across All Intune-Managed Devices (Intune Report)

Portal path:Intune admin center → Reports → Device configuration → Device status

1. Select the MDE Passive Mode configuration profile
2. Filter by Not compliant or Error to see devices where the policy has not applied successfully
3. Devices showing Succeeded have the policy applied — confirm with a spot-check PowerShell query on a few machines

Alternative — Assignment status view:

Intune admin center → Devices → Configuration → [MDE Passive Mode profile] → Device and user check-in status

Columns: Device, User, Last check-in, Status. Filter Status != Succeeded.

On Azure VMs (Defender for Cloud / Portal)

Check MDE extension presence:

az vm extension list --resource-group <rg> --vm-name <vm> --query "[?name=='MDE.Windows']" --output table

Check passive mode registry via Run Command:

az vm run-command invoke \
  --resource-group <rg> \
  --name <vm> \
  --command-id RunPowerShellScript \
  --scripts "Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection' -Name ForceDefenderPassiveMode -ErrorAction SilentlyContinue | Select-Object -ExpandProperty ForceDefenderPassiveMode; (Get-MpComputerStatus).AMRunningMode"

Defender for Cloud — device inventory:

Azure portal → Microsoft Defender for Cloud → Inventory → filter OS = Windows

The inventory shows MDE onboarding status per VM. It does not directly expose the running mode, but a VM showing as onboarded with an active Cortex XDR process and no passive mode key is a gap to fix.

---

4. What to Do If a Device Shows Active Mode

Immediate Assessment

Before acting, determine whether Cortex XDR is actually running on the device:

Get-Process -Name "cortex*" -ErrorAction SilentlyContinue
Get-Service -Name "CortexXDRAgent" -ErrorAction SilentlyContinue | Select-Object Status

If Cortex XDR is NOT running: MDE in Active Mode is acceptable temporarily. The device has no EDR coverage — escalate as an EDR gap, not a passive mode issue. Investigate why Cortex is absent before re-enabling passive mode enforcement (you want Cortex back first).

If Cortex XDR IS running: Both are fighting. Fix immediately. Proceed below.

Fix 1: Push Intune Policy (Preferred)

1. Confirm the device is enrolled in Intune: Intune admin center → Devices → All devices → [device name]
2. Confirm the MDE Passive Mode configuration profile is assigned to this device's group
3. Force a policy sync:
   • From Intune portal: Device → Sync
   • From the device: Settings → Accounts → Access work or school → [account] → Info → Sync
   • PowerShell on device: Invoke-MDMDeviceSync (requires the Intune Management Extension or device management cmdlets)
4. Wait up to 15 minutes, then re-run the verification PowerShell commands

Fix 2: Force Registry Key via Intune Remediation Script

If the profile exists but isn't applying (policy conflict, MDM enrollment issue), push a remediation script:

Detection script:

$val = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection" -Name "ForceDefenderPassiveMode" -ErrorAction SilentlyContinue).ForceDefenderPassiveMode
if ($val -ne 1) { exit 1 } else { exit 0 }

Remediation script:

$path = "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection"
if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null }
Set-ItemProperty -Path $path -Name "ForceDefenderPassiveMode" -Value 1 -Type DWord -Force
# Restart MsSense to pick up the change without a full reboot
Restart-Service -Name Sense -Force -ErrorAction SilentlyContinue

Deploy at:Intune admin center → Devices → Scripts and remediations → Create

• Run as: System
• Run in 64-bit: Yes
• Detection frequency: every hour until fixed

Fix 3: Manual Registry Write (Break-Glass, Azure VMs)

For immediate remediation on a single machine when Intune is not the path:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection" -Name "ForceDefenderPassiveMode" -Value 1 -Type DWord -Force
Restart-Service -Name Sense -Force
Get-MpComputerStatus | Select-Object AMRunningMode

On an Azure VM via Run Command:

az vm run-command invoke \
  --resource-group <rg> \
  --name <vm> \
  --command-id RunPowerShellScript \
  --scripts "Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection' -Name 'ForceDefenderPassiveMode' -Value 1 -Type DWord -Force; Restart-Service -Name Sense -Force; (Get-MpComputerStatus).AMRunningMode"

If CPU Is Already Saturated

1. Verify which process is consuming CPU: Get-Process | Sort-Object CPU -Descending | Select-Object -First 10
2. If MsMpEng.exe or MsSense.exe is the top consumer, passive mode is not applied
3. Do not kill the processes — fix the root cause first, then restart the services cleanly
4. If the system is unresponsive: isolate from production load (remove from load balancer if applicable, or snapshot the VM), apply the registry fix, restart the Sense service, verify AMRunningMode is Passive
5. A full reboot is the cleanest resolution if the service restart does not reduce CPU within 5 minutes

---

5. Azure VM-Specific Procedures

How Defender for Servers Auto-Deploys MDE

When Defender for Servers Plan 1 or Plan 2 is enabled at the subscription level, Microsoft automatically deploys the MDE.Windows VM extension to eligible Windows VMs. This extension onboards the VM to the M365 Defender portal and starts the Sense service. The extension runs as part of Azure's guest agent; it does not check whether another EDR is present.

This means any Windows VM in a subscription with Defender for Servers enabled will have MDE running — and without the passive mode registry key, it will default to Active Mode if Cortex XDR is also installed.

Check which subscriptions have Defender for Servers enabled:

az security pricing list --query "[?name=='VirtualMachines'].{Name:name, PricingTier:pricingTier}" --output table

Run this for each subscription (switch context with az account set --subscription <id>).

List all Windows VMs with the MDE extension installed:

az vm extension list --ids $(az vm list --query "[].id" --output tsv) --query "[?name=='MDE.Windows'].{VM:virtualMachine.id, ProvisioningState:provisioningState}" --output table 2>/dev/null

For large environments, iterate per resource group:

for rg in $(az group list --query "[].name" --output tsv); do
  az vm extension list --resource-group $rg --query "[?name=='MDE.Windows'].{RG:'$rg', VM:id, State:provisioningState}" --output table 2>/dev/null
done

Verify Passive Mode Across Azure VMs at Scale

Use Azure Policy with a Guest Configuration assignment to audit the registry key, or run a script across all VMs in a resource group via Invoke-AzVMRunCommand in a loop.

PowerShell loop across a resource group:

$vms = Get-AzVM -ResourceGroupName <rg>
foreach ($vm in $vms) {
    $result = Invoke-AzVMRunCommand -ResourceGroupName $vm.ResourceGroupName -VMName $vm.Name -CommandId "RunPowerShellScript" -ScriptString @"
        `$val = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection' -Name ForceDefenderPassiveMode -ErrorAction SilentlyContinue).ForceDefenderPassiveMode
        `$mode = (Get-MpComputerStatus -ErrorAction SilentlyContinue).AMRunningMode
        [PSCustomObject]@{ VM = '$($vm.Name)'; ForcePassive = `$val; RunningMode = `$mode }
"@
    $result.Value[0].Message
}

Subscription-Level Check

In the Azure portal:

Defender for Cloud → Environment settings → [subscription] → Defender plans → Servers

If Servers is On (Plan 1 or Plan 2), MDE is being deployed to Windows VMs in that subscription. Ensure passive mode is enforced on all of them.

For VMs that are Arc-enrolled: Azure Arc → Machines → [machine] → Extensions — confirm MDE.Windows is present. Arc machines can receive Intune policies if Intune-Arc integration is enabled.

---

6. Monitoring

KQL — Find Windows Devices Reporting MDE in Active Mode

This query requires MDE events flowing to the Log Analytics Workspace via Defender for Cloud / Defender for Endpoint integration (table: DeviceInfo in the M365 Defender schema, or custom tables if using a LAW connector).

If using the M365 Defender Advanced Hunting schema (forwarded to LAW):

DeviceInfo
| where Timestamp > ago(24h)
| where OnboardingStatus == "Onboarded"
| where isnotempty(MachineGroup)
| project DeviceName, OSPlatform, OnboardingStatus, Timestamp
| join kind=leftouter (
    DeviceProcessEvents
    | where Timestamp > ago(24h)
    | where FileName =~ "cortex.exe" or FileName =~ "CortexXDRAgent.exe"
    | summarize CortexSeen = max(Timestamp) by DeviceName
) on DeviceName
| extend CortexRunning = isnotempty(CortexSeen)
// Filter to devices where Cortex is present — these must be in Passive Mode
| where CortexRunning == true

Check the registry key value via MDE's DeviceRegistryEvents:

DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has "Windows Advanced Threat Protection"
| where RegistryValueName == "ForceDefenderPassiveMode"
| project Timestamp, DeviceName, RegistryValueName, RegistryValueData, ActionType
| order by Timestamp desc

A RegistryValueData of 0x00000001 is correct. A missing record or 0x00000000 indicates the key is not set.

If MDE events land in LAW via Defender for Cloud (table: SecurityEvent or custom):

// Check for MDE-sourced events — confirms MDE is sending telemetry
SecurityEvent
| where TimeGenerated > ago(24h)
| where Source == "Microsoft-Windows-Sysmon" or Channel == "Microsoft-Windows-Windows Defender/Operational"
| where EventID in (5001, 5010, 5012)
// EventID 5001 = Defender disabled; 5010 = real-time protection disabled
// These should not appear if passive mode is configured correctly
| summarize count() by EventID, Computer
| order by count_ desc

Intune Compliance Report for Passive Mode Policy

Intune admin center → Reports → Device configuration

1. Select the MDE Passive Mode profile
2. Export to CSV for a point-in-time record
3. Filter Status column for values other than Succeeded
4. Devices with Error or Not applicable require investigation

Run this check monthly as part of the monthly security review, or after any large Intune enrollment event (new hires, device refresh).

---

7. Cortex XDR and MDE Coexistence

What Each Tool Does

Capability	Cortex XDR	MDE (Passive Mode)
Real-time behavioral detection	Yes — primary	No active blocking
File quarantine	Yes	No
Process termination	Yes	No
Network isolation	Yes (via console)	No
Threat intelligence	WildFire, Palo Alto TI	Microsoft TI
Vulnerability assessment	Yes	Yes
Compliance posture	Via Cortex console	Via M365 Defender portal / Intune
Device health telemetry	Yes	Yes
M365 Defender portal integration	No	Yes — device appears in portal
Arctic Wolf visibility	Yes — cortex_agent.py	Yes — MDE connector
LAW integration	Via syslog CEF (planned)	Via Defender for Cloud

Why Both Running Is Intentional

MDE in passive mode provides a second source of telemetry and integrates with Microsoft's ecosystem (M365 Defender portal, Secure Score, Intune compliance, Defender for Cloud). This gives visibility without operational conflict. Arctic Wolf's MDE connector means even passive-mode MDE data surfaces in MDR analysis.

Cortex XDR owns the response plane. MDE owns Microsoft platform integration. Neither needs to be removed.

Exclusion Alignment

Because each tool scans independently, exclusions must be maintained in both:

• Cortex XDR exclusions: managed in the Cortex XDR console (Cortex console → Endpoints → Exclusions)
• MDE exclusions: managed via Intune or Group Policy (Intune → Endpoint security → Antivirus → [profile] → Exclusions)

When adding a new exclusion (e.g., a security tool's process or a legitimate scan path), add it in both. A Cortex-only exclusion still allows MDE to generate noise on the same path, and vice versa.

---

8. Cortex XDR Agent Goes Silent — MDE Failsafe Behavior

What Happens

If the Cortex XDR agent stops reporting (process crash, failed update, agent uninstall, OS-level issue), MDE detects the absence of a registered third-party AV/EDR and automatically switches from Passive Mode to Active Mode.

This is a built-in Windows Security Center behavior. MDE monitors the registration status of third-party security products via the Security Center API. When Cortex XDR deregisters (or its health check fails), Windows Security Center flags the AV slot as empty and MDE steps up.

This Behavior Is Acceptable and Expected

MDE switching to Active Mode when Cortex is gone is the correct failsafe. A device with no active EDR protection is a gap — MDE filling that gap automatically is the right outcome.

Do not configure MDE to stay in Passive Mode permanently via a lockout policy. The ForceDefenderPassiveMode = 1 registry key keeps MDE passive only while Windows Security Center sees Cortex XDR as active. When Cortex deregisters, the key behavior may be overridden by Windows Security Center's own logic depending on the Windows version. In practice: when Cortex is gone, MDE goes active regardless of the key.

Operational Response When MDE Switches to Active Mode Automatically

1. This will appear in Arctic Wolf and SecOps — MDE active mode on a device that should have Cortex running is an EDR coverage gap alert, not a misconfiguration alert
2. Do not suppress the alert — the root cause is Cortex being absent, not MDE being wrong
3. Investigate Cortex XDR agent health on that device:
   • Cortex console: Endpoints → [device] → Agent Status
   • On device: Get-Service -Name "CortexXDRAgent"
4. Remediate Cortex first (reinstall, update, or investigate agent crash)
5. Once Cortex is healthy and registered with Windows Security Center, MDE automatically reverts to Passive Mode — the ForceDefenderPassiveMode key is still present and takes effect again
6. Verify with: Get-MpComputerStatus | Select-Object AMRunningMode — should return Passive within a few minutes of Cortex re-registering

Monitoring for Cortex Silence + MDE Active Mode

This condition (Cortex absent, MDE active) is detectable in LAW:

// Devices where MDE reported activity but Cortex has no recent events
// Requires both MDE and Cortex telemetry in LAW
let CortexActive = 
    SecurityAlert
    | where TimeGenerated > ago(4h)
    | where ProductName contains "Cortex"
    | summarize LastCortex = max(TimeGenerated) by Computer;
DeviceInfo
| where Timestamp > ago(4h)
| where OnboardingStatus == "Onboarded"
| join kind=leftouter CortexActive on $left.DeviceName == $right.Computer
| where isnull(LastCortex)
| project DeviceName, OSPlatform, Timestamp, LastCortex

Cortex silence detection is also handled by the defense evasion agent in the kill chain workstream (Cortex returning 0 findings while other agents are elevated = HIGH alert).

---

Reference

Item	Value
Registry path	HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection
Registry key	ForceDefenderPassiveMode
Registry type	DWORD
Passive Mode value	1
Active Mode value	0 (or key absent)
MDE service name	Sense
MDE AV process	MsMpEng.exe
MDE sensor process	MsSense.exe
Cortex service name	CortexXDRAgent
Intune profile type	Microsoft Defender Antivirus
Intune portal	https://intune.microsoft.com
Defender for Cloud	https://portal.azure.com/#blade/Microsoft_Azure_Security
M365 Defender portal	https://security.microsoft.com
Cortex XDR console	https://ciriusgroup.xdr.us.paloaltonetworks.com
Central LAW workspace ID	5d76d1f2