How to Configure Microsoft Defender for Endpoint Attack Surface Reduction Rules
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.
Attack Surface Reduction rules are behavior-based endpoint controls built into Microsoft Defender for Endpoint that block specific techniques used in ransomware, fileless malware, and credential theft attacks. Unlike signature-based detection, ASR rules block behaviors: Office spawning PowerShell, scripts running from temp directories, processes accessing LSASS memory: regardless of whether the specific malware sample is known. The 2021 Conti ransomware group specifically documented which ASR rules they worked around, confirming they meaningfully blocked attack progress. This guide covers the deployment mechanics from audit mode through production enforcement.
Understand the Rule Identifier System
Each ASR rule has a GUID identifier, a friendly name, and three operating modes: Off, Audit, and Block. The GUIDs are used in Group Policy and PowerShell configuration. Key high-value rules and their GUIDs: Block Office applications from creating child processes: D4F940AB-401B-4EFC-AADC-AD5F3C50688A; Block credential stealing from LSASS: 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B0; Block Office from injecting code into other processes: 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84; Block execution of potentially obfuscated scripts: 5BEB7EFE-FD9A-4556-801D-275E5FFC04CC; Block JavaScript or VBScript from launching downloaded executable content: D3E037E1-3EB8-44C8-A917-57927947596D; Use advanced protection against ransomware: C1DB55AB-C21A-4637-BB3F-A12568109D35. Run Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions to see current configuration. Each element in _Ids corresponds positionally to _Actions (0=Off, 1=Block, 2=Audit, 6=Warn).
Enable Audit Mode via Intune
In Microsoft Intune: Endpoint Security > Attack Surface Reduction > Create Policy. Select Platform: Windows 10 and later, Profile: Attack Surface Reduction Rules. Configure each rule to 'Audit Mode' initially. Assign to a pilot group (250-500 endpoints across diverse job functions: cover finance, legal, IT, and executive users to capture application diversity). Sync takes up to 8 hours for Intune policy application. Verify receipt on a test endpoint: Get-MpPreference | Select AttackSurfaceReductionRules_Actions should show all 2s (Audit) for the rules you configured. For Group Policy deployment: Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction. Enable 'Configure Attack Surface Reduction rules' and add each rule GUID with value 2 (Audit). Verify: auditpol /get /subcategory:"Audit Policy Change" and check Event ID 1122 in Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Review Audit Events and Identify Exclusions
ASR audit events appear in Event Viewer at Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational. Event ID 1122 = Audit (rule would have blocked), Event ID 1121 = Block (rule blocked). In Microsoft 365 Defender portal: Reports > Microsoft Defender Antivirus > Attack Surface Reduction Rules. Filter by rule and review the 'File' and 'Process' columns: these identify what would be blocked. Common legitimate applications that trigger ASR rules: Adobe Acrobat spawning JavaScript (Office child process rules), backup agents accessing LSASS, RMM tools running from temp directories, vulnerability scanners with obfuscated scripts. Use KQL in Microsoft 365 Defender Advanced Hunting:
DeviceEvents
| where ActionType startswith "AsrBlock"
| summarize Count=count() by FolderPath, FileName, InitiatingProcessFileName, bin(Timestamp, 1d)
| order by Count desc
Group by FolderPath to identify exclusion patterns: if a specific application directory consistently triggers a rule, that directory is the exclusion scope.
Configure Exclusions Correctly
ASR exclusions are path-based only: you cannot exclude by process name or hash for most rules. Exclusions apply to all ASR rules when a file in the excluded path is involved. Configure in Intune under the same ASR policy: 'Attack Surface Reduction Only Exclusions' field. Use the most specific path possible: C:\Program Files\VendorName\Application\specific-binary.exe rather than C:\Program Files\VendorName\. Never exclude entire directories like C:\Windows\Temp or C:\Users: this negates the protection. For Group Policy: Computer Configuration > Admin Templates > Windows Defender > Exploit Guard > ASR > Exclude files and paths. Warning: the LSASS protection rule (9E6C4E1F) handles exclusions differently: it uses a separate process exclusion list configured under AttackSurfaceReductionOnlyExclusions. Test exclusions in audit mode by verifying Event ID 1122 stops appearing for the excluded path before promoting to block mode.
Prioritize These Rules for Block Mode First
Not all ASR rules carry equal risk of business disruption. Promote these to Block mode first after audit review because they have low legitimate-use false positive rates and high attacker impact: (1) Block credential stealing from LSASS (9E6C4E1F): few legitimate applications access LSASS; (2) Block JavaScript/VBScript from launching downloaded executables (D3E037E1): no legitimate business process requires JS/VBS to download and run executables; (3) Block executable content from email client and webmail (BE9BA2D9): legitimate attachments are documents, not executables; (4) Block execution of files unless they meet a prevalence, age, or trusted list criterion (01443614): Smart Screen-style prevalence check. Enable after proven stable in audit: Block Office applications from spawning child processes (D4F940AB), Block Office macro code from Win32 API calls (92E97FA1), Block persistence through WMI event subscription (E6DB77E5). Handle with extra care because they generate more false positives: Block obfuscated scripts (5BEB7EFE): PowerShell-heavy environments have legitimate obfuscation; Block untrusted USB processes (B2B3F03D): depends on removable media policy.
Monitor ASR Enforcement in Production
After enabling block mode, create hunting rules for blocked legitimate business activity to catch over-blocking early. Sentinel KQL for ASR blocks affecting business applications:
DeviceEvents
| where ActionType startswith "AsrBlock"
| where FolderPath has_any ("C:\\Program Files", "C:\\Windows\\System32")
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powershell.exe", "wscript.exe")
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, InitiatingProcessFileName
| order by Timestamp desc
Set up a Teams or email alert when ASR blocks hit more than 10 unique users in a day: that threshold indicates a legitimate business application is affected. Review blocked events in the Microsoft 365 Defender portal daily for the first two weeks after enabling block mode. Create a runbook for the help desk: when a user reports an application stopped working after a security policy change, they should run Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 50 and provide Event IDs 1120/1121 to the security team for exclusion evaluation.
The bottom line
Deploy ASR rules in audit mode (value 2) first, run for 2-4 weeks covering diverse endpoint profiles, then analyze Event ID 1122 patterns in Microsoft 365 Defender Advanced Hunting to identify legitimate application exclusions. Promote to block mode starting with the four lowest-false-positive rules: LSASS credential protection, JS/VBS download blocking, email executable content blocking, and file prevalence check. Block the Office-spawning rules after verifying your macro-dependent business applications are excluded.
Frequently asked questions
How do I enable ASR rules without breaking legitimate applications?
Deploy all ASR rules in audit mode first (value 2 in Intune or Group Policy) and run for 2-4 weeks. Review Event ID 1122 in Windows Defender Operational logs or Microsoft 365 Defender Advanced Hunting to identify which legitimate applications trigger each rule. Configure path-based exclusions for those applications before switching to block mode (value 1). Start with block mode on the lowest-disruption rules first: LSASS credential stealing protection and JS/VBS download blocking typically generate very few false positives.
Which ASR rules are most effective against ransomware?
The ASR rules with the highest ransomware-prevention impact are: 'Use advanced protection against ransomware' (C1DB55AB) which blocks ransomware-specific file modification patterns, 'Block credential stealing from LSASS' (9E6C4E1F) which prevents the credential dumping that enables ransomware lateral movement, 'Block Office applications from creating child processes' (D4F940AB) which stops macro-based ransomware delivery, and 'Block persistence through WMI event subscription' (E6DB77E5) which prevents ransomware from surviving reboots via WMI.
How do I deploy ASR rules via Microsoft Intune?
Deploy ASR rules via Intune at: Endpoint Security > Attack Surface Reduction > Create Policy > Windows 10 and Later > Attack Surface Reduction Rules. Each rule is configured individually with values: 0 (Off), 1 (Block), 2 (Audit), 6 (Warn — shows a user notification before blocking). Best practice: set all rules to Audit (2) for 2-4 weeks while reviewing alerts in the MDE portal under Reports > Attack Surface Reduction, then switch to Block (1) rule by rule starting with the lowest-disruption ones. Exclusions are configured in the same Intune policy: add file paths or process names that legitimate software triggers. Intune pushes the configuration as device policies — confirm deployment in Intune's Device Status view before switching rules to Block mode.
What is the difference between ASR rules and Windows Defender Exploit Guard?
Attack Surface Reduction (ASR) rules and Exploit Guard are both part of the Windows Defender security stack but address different threat vectors. ASR rules block specific high-risk behaviors across the entire system: macro launching child processes, credential dumping, WMI persistence. Exploit Guard provides per-process exploit mitigations: DEP (Data Execution Prevention), ASLR (Address Space Layout Randomization), Control Flow Guard, and heap spray protection configured for specific applications. ASR is the broader behavioral control; Exploit Guard is targeted process-level hardening. Enable both: ASR for system-wide behavioral controls and Exploit Guard for high-risk applications like Office, browsers, and PDF readers that are common initial access targets.
How does Microsoft Defender for Endpoint ASR reporting work?
ASR events are visible in three places in the Microsoft 365 Defender portal: (1) Reports > Attack Surface Reduction: a summary dashboard showing block and audit event counts per rule over the selected time period, with the ability to filter by rule, machine, or time range. (2) Advanced Hunting: query ASR events in the DeviceEvents table using ActionType like 'AsrOfficeChildProcess%' or 'AsrLsassCredentialTheft%' — this allows correlating ASR events with other telemetry. (3) Alerts queue: ASR blocks in Block mode generate alerts that appear in the incident management queue. For tuning, Advanced Hunting is most powerful: query for AsrRuleAudited events and identify the InitiatingProcessFileName values that are triggering the rule — these are the legitimate applications needing exclusions.
How do I handle ASR rule conflicts with endpoint management tools like SCCM or RMM agents?
Management and monitoring tools are the most common source of ASR false positives because they frequently perform actions that match high-risk behavioral rules: spawning child processes, running scripts from temp directories, and accessing sensitive process memory. Before enabling block mode, query Advanced Hunting for AsrAudited events where InitiatingProcessFileName matches your RMM or SCCM executables. Create path-based exclusions scoped to the specific binary rather than the entire vendor directory -- for example, exclude 'C:\Program Files\SolarWinds\Agent\SWAgentSvc.exe' rather than 'C:\Program Files\SolarWinds\'. Test exclusions in audit mode by confirming Event ID 1122 stops appearing for that path before promoting to block. For cloud-managed endpoints using Intune, add exclusions in the same ASR policy under 'Attack Surface Reduction Only Exclusions' and verify the exclusion applies using Get-MpPreference on a test device within 8 hours of policy sync. Document every exclusion with the associated tool, version, and the specific ASR rule it conflicts with -- revisit exclusions when the tool is updated because new versions sometimes resolve the conflict.
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.