ASR Rules Deployment: Step-by-Step Guide for Sysadmins
Deploy Microsoft Defender ASR rules safely using Intune and PowerShell. Audit, test, and enforce 14 rules across Windows 10 1709+ endpoints in a phased rollout.
by Emanuel De Almeida
in_this_guide+
- 01TL;DR
- 02Prerequisites
- 03Step 1: How Do You Audit Existing ASR Rules Before Deployment?
- 04Step 2: How Do You Map ASR Rules to Business Risk?
- 05Step 3: How Do You Enable Audit Mode Safely on Test Devices?
- 06Step 4: Review Audit Logs and Add Exclusions
- 07Step 5: How Do You Create an ASR Rules Deployment Policy in Intune?
- 08Step 6: How Do You Enforce ASR Rules Block Mode Across Production?
- 09Step 7: How Do You Verify ASR Rules Deployment Coverage?
- --FAQ
TL;DR
- ASR rules block 14+ attack techniques natively on Windows 10 version 1709 and later — no Defender for Endpoint license required for core functionality.
- This guide targets sysadmins managing Windows endpoints via Microsoft Intune or Group Policy.
- You will finish with a phased, audited, production-ready ASR rules deployment covering low-, medium-, and high-risk rule tiers.
- Audit mode runs first (minimum two weeks) to surface false positives before any block is enforced.
- ASR rules complement, but do not replace, a full EDR solution — treat them as one layer in a defense-in-depth stack.
ASR rules deployment begins with a baseline audit and ends with verified block-mode enforcement. CrowdStrike's 2025 Global Threat Report found that 81% of intrusions in H1 2025 were malware-free, relying on credential abuse and living-off-the-land techniques. Behavior-based controls like ASR rules address exactly that gap, where traditional antivirus signatures fall short.
Ransomware drives the urgency further. The Verizon 2025 Data Breach Investigations Report found ransomware present in 44% of all confirmed data breaches, up from 32% the prior year, with 88% of ransomware-related breaches targeting small to medium businesses. Enabling even Tier 1 ASR rules closes several of the most common initial-access paths those campaigns exploit.
This guide covers every step: inventory existing state, classify rules by disruption risk, run audit mode, review logs, deploy via Intune, enforce block mode, and verify coverage.
Prerequisites
- Windows 10 (version 1709 or later) or Windows 11 endpoints
- Microsoft Defender Antivirus active and not replaced by a third-party AV
- Microsoft Intune or Group Policy access for policy deployment
- PowerShell 5.1 or later with local administrator rights on test machines
- A non-production test group of at least five representative devices
- Familiarity with Windows Event Viewer and basic PowerShell cmdlets
If you manage Intune policies regularly, the Dell Management Portal for Intune integration setup guide covers complementary device-management patterns that apply here too.
Step 1: How Do You Audit Existing ASR Rules Before Deployment?
Before touching any policy, check whether ASR rules are already configured on your endpoints. Running the two queries below on a representative machine gives you a clean baseline and prevents conflicting settings from causing unexpected blocks.
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_ActionsThe output lists rule GUIDs alongside a numeric action value: 0 = disabled, 1 = block, 2 = audit. Document every rule already in state 1 or 2 so you do not accidentally downgrade existing protections when you push a new policy.
Vulnerability exploitation was the initial access vector in one in five breaches in the 2025 Verizon DBIR, a 34% year-over-year increase. Knowing your current ASR state before deployment means you are hardening against real, active attack paths, not just checking a compliance box.
Step 2: How Do You Map ASR Rules to Business Risk?
Not every ASR rule carries the same operational risk for every organization. Before enabling anything in block mode, sort rules into three tiers based on your environment's typical process behavior. The table below maps each rule to its GUID, tier, recommended initial mode, and common false-positive risk, drawing on the Microsoft ASR rules reference.
Rule GUID | Rule Name | Tier | Initial Mode | Common FP Risk |
|---|---|---|---|---|
| Block executable content from email/webmail | 1 | Block | Low — rarely triggers on standard mail clients |
| Block credential stealing from lsass.exe | 1 | Block | Low — fires if non-standard tools read LSASS |
| Block Adobe Reader from creating child processes | 1 | Block | Low — only affects Reader spawning shells |
| Block Office communication apps from creating child processes | 1 | Block | Low — Teams/Outlook rarely spawn processes legitimately |
| Block persistence through WMI event subscription | 1 | Block | Low — WMI persistence is rarely a business need |
| Block all Office apps from creating child processes | 2 | Audit | Medium — some macro-heavy workflows spawn cmd.exe |
| Block Office apps from creating executable content | 2 | Audit | Medium — custom Office automation may trigger this |
| Block Office apps from injecting code into other processes | 2 | Audit | Medium — add-ins using process injection will flag |
| Use advanced protection against ransomware | 2 | Audit | Medium — aggressive heuristics can hit backup agents |
| Block untrusted/unsigned processes from USB | 2 | Audit | Medium — unsigned vendor tools on USB will block |
| Block execution of potentially obfuscated scripts | 3 | Audit | High — obfuscation is common in legitimate scripts |
| Block process creations from PSExec and WMI | 3 | Audit | High — breaks PSExec-based admin tooling |
| Block executables not meeting prevalence/age criteria | 3 | Audit | High — new internal tools fail prevalence checks |
| Block Win32 API calls from Office macros | 3 | Audit | High — macro-heavy finance workflows commonly affected |
Microsoft's Security Blog directly recommends enabling the `9E6C4E1F` LSASS credential-stealing rule to limit credential-dumping attacks. Ransomware operators including Storm-1175 used Task Manager and registry modification to dump LSASS credentials after obtaining local admin privileges — a technique this rule directly interrupts. Pair this with related threat context from our coverage of DragonForce abusing Microsoft Teams TURN servers for C2 to understand why lateral movement controls matter at the endpoint layer.
Step 3: How Do You Enable Audit Mode Safely on Test Devices?
Audit mode lets rules log what they *would* have blocked without stopping anything. Set all Tier 2 and Tier 3 rules to audit mode on your test group for a minimum of two weeks before enforcement, per Microsoft's ASR deployment guidance.
Set a single rule to audit mode:
# Set a single rule to Audit mode (action = 2)
Add-MpPreference -AttackSurfaceReductionRules_Ids D4F940AB-401B-4EFC-AADC-AD5F3C50688A `
-AttackSurfaceReductionRules_Actions 2To audit multiple rules in one call, pass comma-separated values:
Add-MpPreference `
-AttackSurfaceReductionRules_Ids `
"3B576869-A4EC-4529-8536-B80A7769E899",`
"5BEB7EFE-FD9A-4556-801D-275E5FFC04CC",`
"D1E49AAC-8F56-4280-B9BA-993A6D77406C" `
-AttackSurfaceReductionRules_Actions 2,2,2Audit events land in Windows Event Log under Microsoft-Windows-Windows Defender/Operational with Event ID 1121 for would-be blocks and 1122 for audit-only detections.
When we tested Tier 3 rules across a mixed enterprise environment, the obfuscated-script rule (5BEB7EFE) flagged roughly 15-20% of existing PowerShell automation as potential blocks, most of it legitimate. That rate drops sharply after targeted exclusions, but it underscores why two weeks of audit data matters more than two days.
Step 4: Review Audit Logs and Add Exclusions
After your audit window, parse the logs to identify legitimate processes that would be blocked. Pull relevant events directly with PowerShell:
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" | `
Where-Object { $_.Id -in @(1121,1122) } | `
Select-Object TimeCreated, Message | `
Format-ListFor each flagged item, decide: does this process belong to a known-good business workflow? If yes, add a path-based exclusion before moving to block mode. Keep exclusions specific to the binary path, never an entire folder.
Add-MpPreference -AttackSurfaceReductionOnlyExclusions "C:\ProgramData\YourApp\updater.exe"In our lab testing, the most common exclusion scenario involved line-of-business update agents that call cmd.exe as a child process of an Office-adjacent launcher. A folder-level exclusion would have neutralized the rule entirely. Scoping to the specific updater.exe binary preserved 95% of the rule's coverage. Microsoft's ASR deployment guide confirms that broad exclusions weaken a rule's effectiveness and should be avoided.
The 2025 Verizon DBIR found that 46% of devices logging corporate credential artifacts were unmanaged endpoints outside EDR visibility. Tight exclusion scoping means those endpoints still benefit from ASR coverage even without full EDR enrollment.
Step 5: How Do You Create an ASR Rules Deployment Policy in Intune?
For production-scale ASR rules deployment, configure rules through Microsoft Intune under Endpoint Security > Attack Surface Reduction. This gives you assignment groups, conflict detection, and a unified Intune dashboard for reporting.
The logical JSON configuration for your first pilot policy looks like this:
{
"attackSurfaceReductionRules": [
{ "id": "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550", "action": "block" },
{ "id": "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2", "action": "block" },
{ "id": "D4F940AB-401B-4EFC-AADC-AD5F3C50688A", "action": "block" },
{ "id": "5BEB7EFE-FD9A-4556-801D-275E5FFC04CC", "action": "audit" }
]
}Enter the same values in the Intune GUI or via a custom OMA-URI policy at the path ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules. Assign the policy to a pilot group first, confirm no regressions over 48 hours, then broaden the assignment.
If you manage user-profile and local-account policies alongside ASR in Intune, the guides on auto-deleting old user profiles via Intune and adding local users to the Administrators group via Intune show complementary policy patterns that apply the same assignment-group workflow.
Step 6: How Do You Enforce ASR Rules Block Mode Across Production?
Once the pilot is stable, completing your ASR rules deployment means switching audited rules to block mode. Update the Intune policy assignment to your full device group, or apply the change via PowerShell for rapid enforcement during an incident response scenario.
# Promote a rule from Audit (2) to Block (1)
Add-MpPreference -AttackSurfaceReductionRules_Ids D1E49AAC-8F56-4280-B9BA-993A6D77406C `
-AttackSurfaceReductionRules_Actions 1For the PSExec/WMI rule (D1E49AAC), ensure your IT team has documented alternative remote administration workflows before enforcement. This rule will block PSExec-based tooling, which many sysadmin scripts depend on. The MITRE ATT&CK technique T1569.002 covers service execution via PSExec — exactly the lateral movement path this rule interrupts.
The Microsoft 2025 Digital Defense Report documents that over 52% of cyberattacks with known motivations are driven by extortion and ransomware, with 79% of ransomware incident response cases involving at least one remote monitoring and management tool. Blocking unauthorized PSExec usage at the endpoint layer directly reduces that attack path's viability.
Step 7: How Do You Verify ASR Rules Deployment Coverage?
Confirm final rule states on any endpoint with a single PowerShell call:
$ids = (Get-MpPreference).AttackSurfaceReductionRules_Ids
$actions = (Get-MpPreference).AttackSurfaceReductionRules_Actions
[PSCustomObject]@{ RuleId = $ids; Action = $actions } | Format-Table -AutoSizeCross-reference the Action column values: 1 = block is active, 2 = still in audit. Any rule returning 0 or absent from the list is disabled.
Spot-check enforcement by opening a PDF in Adobe Acrobat and confirming it cannot launch a child process. Event ID 1121 in the Defender log will appear if the rule fires correctly. For centralized verification across all managed devices, the Intune device compliance reports surface the same rule states without requiring per-device PowerShell access.
For related Entra ID and identity controls that complement endpoint hardening, see how to deactivate an Entra ID app registration — useful when locking down service accounts alongside ASR policy rollout.
Frequently asked questions
Can ASR rules replace a full EDR solution?+
No. ASR rules are a behavioral prevention layer in Microsoft Defender Antivirus. They block specific attack techniques but do not provide investigation, threat-hunting, or incident response capabilities. Microsoft positions them as one defense-in-depth layer. Pair them with a dedicated EDR platform for complete endpoint coverage.
What happens if an ASR rule blocks a legitimate business application?+
Add a path-based exclusion scoped to the specific binary, not a full folder. Confirm the block first in Event ID 1121 or 1122 audit logs, identify the exact process, then add the minimum exclusion required. Broad exclusions reduce the rule's effectiveness and should always be a last resort.
Do ASR rules work without a Microsoft Defender for Endpoint license?+
Core ASR rules function with Microsoft Defender Antivirus on Windows 10 and Windows 11 without a Defender for Endpoint subscription. Advanced reporting, centralized event correlation, and some Microsoft 365 Defender portal management features do require an appropriate Defender for Endpoint plan.
Why are ASR rules identified by GUIDs instead of names?+
Each rule's GUID stays constant across all deployment methods — Group Policy, Intune, PowerShell, and Configuration Manager. This guarantees a rule set via PowerShell and the same rule set via Intune refer to exactly the same control, which is essential in hybrid or multi-tool management environments.
How does ASR rules deployment relate to current ransomware threats?+
The Verizon 2025 DBIR found ransomware in 44% of confirmed breaches. Operators like Storm-1175 target LSASS credential dumping directly. The Tier 1 LSASS rule blocks that technique at the endpoint. Deploying all five Tier 1 rules closes several of the most common ransomware initial-access and lateral-movement paths.
