Attack Surface Reduction Rules: Deployment and Tuning Guide · CloudEngineerHub
Defender11 min read10 views
Attack Surface Reduction Rules: Deployment and Tuning Guide
Deploy and tune ASR rules with Intune and Microsoft Defender for Endpoint: rule states, per-rule exclusions, audit-first methodology, event ID analysis, and PowerShell tooling.
C
CloudEngineerHub Team
Published: August 23, 2026· Last Updated: October 3, 2026·11 min read
Attack Surface Reduction Rules: Deployment and Tuning Guide
Attack surface reduction (ASR) rules are targeted behavior blocks in Microsoft Defender for Endpoint: they stop the techniques malware abuses — Office documents spawning children, scripts launching downloads, credential theft from LSASS — rather than known-bad files. Deploying them is a checkbox. Tuning them so block mode survives contact with a real enterprise is an engineering project, and this guide is that project's blueprint.
Visual Walkthrough
The audit-tune-enforce conveyor that keeps block mode safe to run.
Interactive FlowASR Rules — Event to Enforced Block5/5
Event 1122 = would-have-blocked; evidence without impact.
tune
3
Exclusions tuned
False positives resolved via path/signer exclusions.
enforce
4
Block mode 1121
Rule flips to block; event 1121 confirms real enforcement.
telemetry
5
MDE reports trend
Attack surface reduction report tracks blocks across fleet.
ASR Rules — Event to Enforced Block. 1. Behavior matches rule: Office spawning child, script downloading payload — rule fires. — 2. Audit mode logs 1122: Event 1122 = would-have-blocked; evidence without impact. — 3. Exclusions tuned: False positives resolved via path/signer exclusions. — 4. Block mode 1121: Rule flips to block; event 1121 confirms real enforcement. — 5. MDE reports trend: Attack surface reduction report tracks blocks across fleet.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Microsoft Defender Antivirus as the primary antivirus and active real-time protection (ASR rules depend on it).
Microsoft Defender for Endpoint Plan 1 or Plan 2 licensing.
Intune Administrator or Endpoint Security Manager role to create ASR policies in intune.microsoft.com.
Devices on a supported Windows version — the modern ASR rules require Windows 10/11 with current Defender platform updates.
A pilot group, a change calendar, and — critically — an agreement with application owners that audit data will drive exceptions, not anecdotes.
How It Works
Each ASR rule is a GUID identified behavior block with a per-rule state. In Intune you deploy ASR through Endpoint security > Attack surface reduction > Attack Surface Reduction Rules policy, which lets you set each rule to Block, Audit, Warn, or Off and to add per-rule exclusions. The same configuration can be delivered through the Defender/Policy CSP (AttackSurfaceReductionRules_Ids and _Actions) or Group Policy for co-managed estates.
Rule states map to numeric values in the CSP and in local policy inspection: 0 disables a rule, 1 is block, 2 is audit, and 6 is warn. Audit mode evaluates every rule and records what it would have blocked — the entire tuning methodology rests on that event stream, which appears in the Microsoft-Windows-Windows Defender/Operational event log as event ID 1121 (block) and 1122 (audit).
The Defender portal adds fleet-level reporting under Reports > Attack surface reduction rules, aggregating detections, blocks, and audits by rule and device, which is the fastest way to see blast radius before flipping a rule to block.
Step-by-Step Implementation
1. Inventory your starting state
Before deploying anything, read the current local state on representative devices with Get-MpPreference (script below). Fleets that ran older baselines often carry partial rule sets in mixed states — you need to know that baseline.
2. Deploy the standard set in audit mode
Create the Intune ASR policy, set every recommended rule to Audit, and add per-rule exclusions only where audit data later justifies them. Assign to a pilot ring first, then broader rings.
3. Harvest audit data for two to four weeks
Collect event IDs 1121 and 1122 from endpoints (script below), or use the Defender portal report for aggregation. Group by parent process and target file; the noise almost always clusters around known enterprise tooling.
4. Add per-rule exclusions, not global opt-outs
Tune with file and folder exclusions scoped to the specific rule that fires. Avoid disabling a rule fleet-wide because one workflow trips it — that trades a narrow exception for broad exposure.
5. Flip rules to block in waves
Move rules to Block ring by ring, watching both the ASR report and your service desk queue. Keep audit events flowing even after block so you can spot drift and new abuse attempts.
Configuration Deep Dive
The rule set that pays for itself first. While you should always consult the official ASR rules reference for the current list and guidance, these rules historically produce the best protection-to-friction ratio in enterprise fleets:
Rule
GUID
Block credential stealing from the Windows local security authority (lsass.exe)
9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2
Block executable content from email client and webmail
BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550
Block Office applications from creating executable content
3B576869-A4EC-4529-8536-B80A7769E899
Block Office applications from injecting code into other processes
75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84
Block JavaScript or VBScript from launching downloaded executable content
D3E037E1-3EB8-44C8-A917-57927947596D
Block process creations originating from PSExec and WMI commands
D1E49AAC-8F56-4280-B9BA-993A6D77406C
Block abuse of exploited vulnerable signed drivers
56A863A9-875E-4185-98A7-B882C64B5CE5
Block untrusted and unsigned processes that run from USB
B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4
The PSExec and WMI rule is the classic breaker. Legitimate administrators live on PSExec and WMI; if your remote-support model depends on them, that rule needs planned exclusions for admin tool paths or a workflow change — decide before block mode, not after a Tuesday outage.
Warn mode. Warn presents the user with a bypass prompt for the block. It is a useful middle state for user-triggered workflows (Office rules especially), but treat it as a transition state, not a destination — bypass fatigue is real.
Exclusions scoping. Per-rule exclusions accept files and folders by path. Pin them to exact tool paths and review quarterly; exclusions are attack surface too, and ASR exclusions differ from antivirus scan exclusions.
Real-World Enterprise Scenario
A financial services firm with 8,500 endpoints audited all recommended rules for three weeks. The harvest surfaced 412 audit events, of which 85 percent traced to four workflows: a legacy invoicing add-in that injected into Office processes, a deployment team's PSExec scripts, a VBScript-driven reporting tool, and an updater writing to a shared folder. Each got a narrow per-rule exclusion plus a ticket to fix the underlying design. Block mode rolled out over six weeks; in the following quarter, ASR rules blocked two real intrusion attempts — one LSASS access attempt and one malicious macro chain — with zero support tickets attributable to the rules.
PowerShell for ASR Deployment and Tuning
Script 1 — read the effective local ASR rule states:
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Map local ASR rule GUIDs to their action (0=Disabled, 1=Block, 2=Audit, 6=Warn)$prefs = Get-MpPreference
$map = @{ 0 = 'Disabled'; 1 = 'Block'; 2 = 'Audit'; 6 = 'Warn' }
if (-not $prefs.AttackSurfaceReductionRules_Ids) {
'No ASR rules configured on this device'return
}
for ($i = 0; $i -lt$prefs.AttackSurfaceReductionRules_Ids.Count; $i++) {
'{0} => {1}' -f$prefs.AttackSurfaceReductionRules_Ids[$i], $map[[int]$prefs.AttackSurfaceReductionRules_Actions[$i]]
}
# Expected output:# 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 => Block# 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 => Audit# D1E49AAC-8F56-4280-B9BA-993A6D77406C => Disabled
Script 2 — harvest ASR audit and block events for tuning:
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Collect ASR events (1121 = block, 1122 = audit) from the last 14 days$since = (Get-Date).AddDays(-14)
$events = Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-Windows Defender/Operational'
Id = 1121, 1122
StartTime = $since
} -ErrorAction SilentlyContinue
$rows = foreach ($ein$events) {
[pscustomobject]@{
Time = $e.TimeCreated
Event = if ($e.Id -eq1121) { 'Block' } else { 'Audit' }
Detail = $e.Message
}
}
$rows | Sort-Object Time | Export-Csv .\asr-events.csv -NoTypeInformation'ASR events collected: ' + $rows.Count
# Expected output:# ASR events collected: 87
Script 3 — list ASR policies deployed through Intune endpoint security:
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
<# Get-AsrIntunePolicies.ps1 - list endpoint security ASR intents in the tenant.
Connect-MgGraph -Scopes'DeviceManagementConfiguration.Read.All' #>$intents = Invoke-MgGraphRequest -Method GET -Uri'https://graph.microsoft.com/beta/deviceManagement/intents?$select=id,displayName,templateFamily,isAssigned'$asr = $intents.value | Where-Object templateFamily -eq'endpointSecurityAttackSurfaceReductionRules'$asr | Select-Object displayName, isAssigned | Sort-Object displayName | Format-Table -AutoSize# Expected output:# displayName isAssigned# ----------- ----------# ASR Rules - Pilot Ring True# ASR Rules - Production Ring True# ASR Rules - Legacy Servers False
Troubleshooting
Symptom
Likely cause
Fix
Legitimate admin tools blocked after enablement
PSExec/WMI rule colliding with operations workflows
Add narrow per-rule exclusions for tool paths; move the rule to Warn while tuning
Rule state on device does not match policy
Multiple policy sources (GPO, ConfigMgr, Intune)
Run the conflict report, remove legacy sources, keep one authority per value
No 1122 audit events collected
Event log cleared or rules not actually applied
Verify with Get-MpPreference and confirm the policy reached the device
User complains about ASR notifications
Warn mode prompts
Move the rule to Block with exclusions, or Off with a documented exception
Defender Antivirus is passive and rules do nothing
Third-party AV is primary
ASR requires Defender AV active; resolve the AV priority first
Exclusion path not honored
Wrong rule or syntax, or 8.3/short path mismatch
Target the exact rule, use full paths, verify case and wildcards
Visual Walkthrough
The business call every tuning review makes, with evidence.
Decision TreeASR False Positive — Block or Exclude?5/5
Decision gate
Legitimate app blocked?
Let event data — not anecdotes — drive the exception.
Yes — proven signer
1
Collect evidence
Event 1121 + file hash + publisher from MDE timeline.
2
Signer or path exclusion
Prefer certificate-based exclusions over loose paths.
3
Document exception
Owner, expiry date, review date — exceptions are debt.
4
Re-audit quarterly
Expired or unused exclusions get removed.
No — actual threat
1
Keep block active
Rule stays in block; user education + incident process.
2
Contain & investigate
MDE alert triage, isolate device if needed.
3
Feed SOC knowledge
Update detection story and runbook.
4
Posture stays honest
Quarterly audit proves blocks still earn their keep.
ASR False Positive — Block or Exclude?. Gate: Legitimate app blocked? — Yes — proven signer: Collect evidence — Yes — proven signer: Signer or path exclusion — Yes — proven signer: Document exception — Yes — proven signer: Re-audit quarterly — No — actual threat: Keep block active — No — actual threat: Contain & investigate — No — actual threat: Feed SOC knowledge — No — actual threat: Posture stays honest
Common Errors
Treating audit silence as safety. Rules audit only the behaviors they observe; two weeks of quiet may mean the attack paths were never exercised. Combine event data with threat-informed reasoning.
Setting all rules to Block at once. The blast radius lands on service desk, not on you. Wave-based enablement with a rollback path (flip back to audit) is the professional pattern.
Copying GUIDs from blog posts without the reference. One transposed character disables the wrong rule or none at all; always cross-check against the official reference.
Using antivirus exclusions where ASR per-rule exclusions are needed. They are separate mechanisms; a scan exclusion does not stop ASR blocks.
Forgetting the CSP value semantics. 2 is audit and 6 is warn in the CSP; swapping them silently changes behavior across the fleet.
Best Practices
Audit first, exclude narrowly, then block in waves — never skip the audit phase regardless of executive pressure.
Assign one owner for the ASR policy and its exception register; orphaned exclusions rot into risk.
Review the Defender portal ASR report weekly during rollout, monthly after stabilization.
Keep the same ring structure for ASR as your update rings so stakeholders already understand the cadence.
Version-control your intended rule state (a simple JSON in Git) so drift against deployed reality is diffable.
Pair ASR with App Control (WDAC): ASR stops behaviors, App Control stops binaries, and together they close different halves of the same attack surface.
Security Considerations
Every exclusion is a deliberate reduction of protection; document owner, reason, and review date for each one.
ASR rules generate telemetry that feeds detections and hunting — do not disable rule eventing even when the block itself is off.
Attackers who gain admin can alter local ASR state; monitor event ID 5007 (configuration change) in the Defender operational log for tampering.
Consider credential-theft rules (LSASS) as your highest priority — they directly blunt credential dumping used in lateral movement.
Coordinate ASR deployment with vulnerability management; vulnerable signed driver blocks depend on current Defender platform versions.
FAQ
Q: Can I deploy ASR rules with Configuration Manager or Group Policy instead of Intune?
A: Yes — ASR is supported through Group Policy, Configuration Manager, and MDM CSPs. The tuning methodology in this guide is identical; only the delivery vehicle differs.
Q: How long should audit mode run?
A: Two to four weeks covers most legitimate-behavior cycles, including monthly jobs. Add extra coverage if quarter-end or seasonal workflows exist in your environment.
Q: Do ASR rules work if Microsoft Defender Antivirus is in passive mode?
A: No. ASR depends on Defender AV being the active antivirus. Resolve third-party AV conflicts before planning rule deployment.
Q: What is the difference between Warn mode and Audit mode?
A: Audit silently records what would have been blocked; Warn actively prompts the user, who can bypass the block. Warn is for user-facing workflows, audit is for measurement.
Q: Where do I see which rules fired across the tenant?
A: In the Microsoft Defender portal under Reports > Attack surface reduction rules, and per-device in the endpoint's operational event log (IDs 1121 and 1122).
Conclusion
ASR rules are among the highest-yield endpoint controls you can deploy, and the only thing standing between audit and a clean block-mode rollout is disciplined tuning. Inventory local state, audit everywhere, exclude narrowly, block in waves — and let the event stream, not anecdotes, make every decision.
Comments
0No comments yet — be the first to share your thoughts.