How to Configure Microsoft Defender for Endpoint Baseline Policies
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Microsoft Defender for Endpoint is significantly more capable than its default configuration suggests. Fresh MDE deployments have cloud-delivered protection at Basic level, no ASR rules enabled, network protection off, and tamper protection dependent on Intune enrollment status. Organizations that deploy MDE and accept the defaults are missing a large fraction of the product's protective capability.
The Microsoft Security Baseline for Windows specifies the recommended settings: but even that baseline does not enable all ASR rules (which require per-environment testing). This guide covers what to enable, in what order, and how to use audit mode to prevent business disruption.
Priority 1: Core Protection Settings
These settings should be enabled immediately: they have minimal business impact risk and provide foundational protection.
Tamper Protection (most critical):
Tamper protection prevents local administrators and malware from disabling Defender components: real-time protection, cloud-delivered protection, and signature updates. Ransomware routinely disables AV as its first action; tamper protection blocks this.
# Verify current tamper protection status
Get-MpComputerStatus | Select-Object TamperProtectionSource, IsTamperProtected
# TamperProtectionSource: 'ATP' (managed by Intune/MDE) or 'Disabled'
# Enable via PowerShell (temporary: use Intune for persistent management):
Set-MpPreference -DisableTamperProtection $false
# Intune: Endpoint Security > Antivirus > Windows Security > Tamper Protection: On
# This is the authoritative persistent setting
Cloud-delivered protection and automatic sample submission:
# Set cloud-delivered protection to "Not configured" (lets Microsoft manage level)
# Or explicitly set to "High" block level:
Set-MpPreference -CloudBlockLevel High
Set-MpPreference -CloudExtendedTimeout 50 # Allow up to 50 seconds for cloud analysis
Set-MpPreference -MAPSReporting Advanced # Full telemetry for cloud protection
Set-MpPreference -SubmitSamplesConsent SendAllSamples
# Verify:
Get-MpPreference | Select-Object CloudBlockLevel, CloudExtendedTimeout, MAPSReporting, SubmitSamplesConsent
Intune Antivirus Policy (create under Endpoint Security > Antivirus):
Profile: Windows Antivirus (Windows 10 and later)
Microsoft Defender Antivirus settings:
Cloud-delivered protection level: Not configured (uses Microsoft defaults)
Cloud protection timeout extension: 50
Automatic sample submission: Send all samples
Real-time protection: Enabled
Behavior monitoring: Enabled
Script scanning: Enabled
Scan all downloaded files: Enabled
Network protection: Enabled (block mode)
PUA protection: Enabled (blocks potentially unwanted apps)
Microsoft Defender Security Center:
Tamper protection: Enabled
Priority 2: Attack Surface Reduction Rules
ASR rules block specific behaviors commonly used by malware: Office macro abuse, credential theft from LSASS, script obfuscation, and more. They must be deployed in Audit mode first to identify legitimate application collisions before switching to Block mode.
Audit-then-Block workflow:
# Step 1: Deploy ALL rules in Audit mode via PowerShell or Intune
# (Audit mode: events logged but nothing blocked)
Set-MpPreference -AttackSurfaceReductionRules_Ids @(
"BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550", # Block executable content from email
"D4F940AB-401B-4EFC-AADC-AD5F3C50688A", # Block Office from creating child processes
"3B576869-A4EC-4529-8536-B80A7769E899", # Block Office from creating executable content
"75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84", # Block Office from injecting into other processes
"D3E037E1-3EB8-44C8-A917-57927947596D", # Block JavaScript/VBScript from launching executables
"5BEB7EFE-FD9A-4556-801D-275E5FFC04CC", # Block obfuscated scripts
"92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B", # Block Win32 API calls from Office macros
"01443614-CD74-433A-B99E-2ECDC07BFC25", # Block executable files unless they meet prevalence criteria
"C1DB55AB-C21A-4637-BB3F-A12568109D35", # Use advanced protection against ransomware
"9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2", # Block credential stealing from Windows local security authority
"D1E49AAC-8F56-4280-B9BA-993A6D77406C", # Block process creations from PSExec and WMI
"B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4", # Block untrusted/unsigned USB processes
"26190899-1602-49E8-8B27-EB1D0A1CE869", # Block Office communication apps from creating children
"7674BA52-37EB-4A4F-A9A1-F0F9A1619A2C", # Block Adobe Reader from creating child processes
"E6DB77E5-3DF2-4CF1-B95A-636979351E5B" # Block persistence through WMI subscription
) -AttackSurfaceReductionRules_Actions @(
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2
) # 2 = Audit mode for all
# Step 2: Monitor audit events for 2 weeks
# Events in Event Viewer: Applications and Services Logs > Microsoft > Windows >
# Windows Defender > Operational > Event ID 1121 (block) / 1122 (audit)
# Query audit events from MDE Advanced Hunting:
# DeviceEvents | where ActionType startswith "AsrAudit" | summarize count() by ActionType, FileName
# Step 3: After reviewing audit results, switch impactful rules to Block:
Set-MpPreference -AttackSurfaceReductionRules_Ids "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2" \
-AttackSurfaceReductionRules_Actions 1 # 1 = Block mode
High-value ASR rules to enable first (lowest legitimate app impact):
| Rule | GUID | Risk of false positive |
|---|---|---|
| Block LSASS credential stealing | 9E6C4E1F... | Low: few legitimate apps access LSASS |
| Block executable content from email | BE9BA2D9... | Low: legitimate email attachments are documents, not executables |
| Block Office child processes | D4F940AB... | Medium: some Office macros spawn legitimate processes |
| Block obfuscated scripts | 5BEB7EFE... | Medium: some IT scripts use obfuscation for legacy reasons |
| Block untrusted USB | B2B3F03D... | Low: USB policies usually align with this |
| Block WMI persistence | E6DB77E5... | Low: legitimate WMI subscriptions are rare |
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Priority 3: Network Protection and Web Filtering
Network protection extends SmartScreen to all processes: not just browsers: blocking connections to known malicious hosts at the network layer.
# Enable network protection in Block mode
Set-MpPreference -EnableNetworkProtection Enabled # 'Enabled' = Block, 'AuditMode' = Log only
# Verify
Get-MpPreference | Select-Object EnableNetworkProtection
# 1 = Enabled (block), 2 = AuditMode, 0 = Disabled
# Network protection blocks:
# - Connections to domains in Microsoft Threat Intelligence
# - Connections to IP addresses known for phishing, exploit kits, C2
# - Works for ALL processes (not just Edge/Chrome)
Web Content Filtering (requires MDE Plan 1 or Plan 2):
Web content filtering in MDE allows category-based URL blocking without a proxy: it works at the network protection layer directly on the endpoint.
Microsoft 365 Defender Portal > Settings > Endpoints > Web content filtering:
Create policy "Block-HighRisk-Categories":
Categories to block:
- Hacking (very high value: blocks malware-hosting sites)
- Malware sites
- Phishing
- Anonymous proxies (prevents proxy bypass attempts)
- Adult content (policy)
- Gambling (policy)
Assign policy to:
- All devices (or specific device groups)
EDR in block mode (for environments with third-party AV):
Microsoft 365 Defender Portal > Settings > Endpoints > Advanced features:
EDR in block mode: On
# This allows MDE's EDR to block malicious artifacts even when
# a different AV product is the active real-time protection engine
# Essential during vendor transitions or in Defender + third-party AV co-existence
Verification and Advanced Hunting
Verify MDE policy coverage across your fleet:
# Run on each machine to get current policy settings
Get-MpComputerStatus | Select-Object `
AMRunningMode, AntivirusEnabled, RealTimeProtectionEnabled,
IsTamperProtected, TamperProtectionSource,
NISEngineVersion, BehaviorMonitorEnabled, IoavProtectionEnabled
# Or query fleet-wide from MDE Advanced Hunting:
# In Microsoft 365 Defender > Hunting > Advanced Hunting:
// MDE Advanced Hunting: find machines with tamper protection disabled
DeviceInfo
| where Timestamp > ago(1d)
| where isnotempty(MachineGroup)
| join kind=leftouter (
DeviceTvmSecureConfigurationAssessment
| where ConfigurationId == "scid-91" // Tamper protection config
| project DeviceId, IsCompliant
) on DeviceId
| where IsCompliant == 0 or IsCompliant == "" // Non-compliant or not assessed
| project DeviceName, OSPlatform, MachineGroup, IsCompliant
// Find machines where ASR rules are not in block mode:
DeviceTvmSecureConfigurationAssessment
| where ConfigurationId startswith "scid-10" // ASR-related SCIDs
| where IsCompliant == 0
| summarize count() by ConfigurationId, ConfigurationName
| sort by count_ desc
Detect ASR blocks in Advanced Hunting:
// What ASR rule is blocking the most legitimate traffic? (Helps identify tuning needs)
DeviceEvents
| where ActionType startswith "Asr"
| where Timestamp > ago(7d)
| summarize
BlockCount = countif(ActionType endswith "Blocked"),
AuditCount = countif(ActionType endswith "Audited"),
AffectedFiles = make_set(FileName, 10)
by ActionType
| sort by BlockCount desc
The bottom line
MDE baseline configuration starts with tamper protection (prevents malware from disabling Defender), cloud-delivered protection at High block level, and real-time protection verification: these have near-zero false positive risk. Then deploy all ASR rules in Audit mode for 2 weeks, review blocking events in Advanced Hunting, and move rules to Block mode once confirmed safe. Enable network protection in Block mode for all-process SmartScreen and web content filtering for category-based URL blocking. Verify fleet compliance using DeviceTvmSecureConfigurationAssessment in Advanced Hunting.
Frequently asked questions
What are the most important Microsoft Defender for Endpoint settings to enable?
In priority order: (1) Tamper protection: prevents malware from disabling Defender components; (2) Cloud-delivered protection at High level: enables near-zero-day protection; (3) Network protection in Block mode: extends SmartScreen to all processes; (4) ASR rules deployed in Audit mode then Block mode after testing: blocks Office macro abuse, LSASS access, and script obfuscation. These settings close the largest gaps between MDE default configuration and full protective capability.
How do you safely enable ASR rules without breaking applications?
Deploy all ASR rules in Audit mode first (value 2 in PowerShell, or Audit in Intune) and monitor for 2 weeks using MDE Advanced Hunting (DeviceEvents where ActionType startswith 'AsrAudit'). Review which rules are triggering against which applications, create exclusions for confirmed legitimate applications, then switch rules to Block mode. High-value, low-false-positive rules to block first: LSASS credential stealing, executable content from email, and untrusted USB process execution.
What is Microsoft Defender for Endpoint and what does it detect?
Microsoft Defender for Endpoint (MDE, formerly Defender ATP) is Microsoft's enterprise EDR platform. It provides: real-time behavioral detection of malware, ransomware, and attack techniques using cloud-backed telemetry; Attack Surface Reduction (ASR) rules that block specific attack behaviors at the process level; automated investigation and response (AIR) that automatically contains infected devices; Advanced Hunting for KQL-based threat hunting across endpoint telemetry; and integration with Microsoft Sentinel for SIEM correlation. MDE collects process creation, network connections, file activity, and registry changes from every enrolled endpoint and makes them queryable in the DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, and DeviceRegistryEvents tables.
What are Microsoft Defender ASR rules and which ones should I enable?
Attack Surface Reduction (ASR) rules block specific process behaviors associated with malware execution. The highest-value, lowest-disruption rules: 'Block credential stealing from the Windows local security authority subsystem' (prevents Mimikatz-style LSASS dumping); 'Block executable content from email client and webmail' (prevents Office macro-dropped executables); 'Block Office applications from injecting code into other processes' (prevents macro-based code injection); 'Block untrusted and unsigned processes that run from USB' (prevents USB-based malware). Rules to deploy with extra caution (more legitimate application impact): 'Block all Office applications from creating child processes' (some legitimate addins break) and 'Use advanced protection against ransomware' (broad behavioral heuristics with higher false positive rate).
How do I configure Microsoft Defender for Endpoint to isolate a device automatically?
MDE supports automated device isolation via custom detection rules and automated investigation response (AIR). Manual isolation: in the MDE portal, navigate to the device, select Actions > Isolate Device — this enforces network isolation at the OS level within seconds, allowing only MDE C2 traffic. Automated isolation via custom detection rule: create a detection rule in Defender portal under Settings > Custom Detection Rules that triggers on specific alert severity and evidence types, with Response Action set to 'Isolate Machine'. Live Response is available even on isolated devices: MDE's communication channel remains active, so forensic commands can still be run on the isolated machine. Note: isolation affects all user sessions on the device, not just the suspicious process.
How do you verify that MDE ASR rules are enforced in Block mode across a fleet using Advanced Hunting?
Query DeviceTvmSecureConfigurationAssessment for ASR-related configuration IDs (scid-1001 through scid-1021 cover individual ASR rules) and filter where IsCompliant = 0 to surface machines where rules remain in Audit or Disabled state. Cross-reference with DeviceEvents filtering on ActionType starting with 'AsrBlocked' to confirm Block-mode enforcement is generating events: a machine showing ASR-related SCIDs as non-compliant but generating no AsrBlocked events may have a GPO conflict overriding the Intune policy. Check for policy conflicts by running Get-MpPreference on sampled endpoints and comparing AttackSurfaceReductionRules_Actions values against the Intune-deployed policy. If Intune and GPO both manage ASR, Intune wins only when the device is Intune-managed without co-management conflicts; use the Intune device configuration report under Devices > Monitor > Assignment failures to identify conflict sources.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.