Attack Surface Reduction rules are some of the highest-value hardening you can turn on in a Windows estate, and most of it is already paid for. Deploying Attack Surface Reduction rules in Intune blocks whole classes of attacker behaviour — Office spawning child processes, credential theft from LSASS, scripts launching downloaded executables — at the operating-system level, before any of it reaches your detection stack. The catch is that Block mode can break a line-of-business app as easily as it blocks malware, so the rollout order matters. This post covers how I deploy ASR rules through Intune without taking a production app down with them.
Key Takeaways
- You can deploy Attack Surface Reduction rules in Intune from the Endpoint security blade, scoped to device groups, with each rule set independently to Audit, Block, or Warn.
- Turn the three standard protection rules on in Block mode straight away — they are low-impact and high-value — and roll everything else out in Audit mode first.
- Microsoft recommends monitoring Audit results for roughly 30 to 45 days before flipping a rule to Block, which is the ASR equivalent of report-only Conditional Access.
- ASR rules depend on Microsoft Defender Antivirus being the active antivirus, and several rules also require cloud-delivered protection to be on.
- Rules are identified by GUID everywhere except the Intune and Configuration Manager UIs, where they appear by name — useful to know when you verify with
Get-MpPreference.
Environment
- Windows 11 and Windows 10 (1809+) devices enrolled in Microsoft Intune.
- Microsoft Defender Antivirus running as the primary AV in active mode, with cloud-delivered protection enabled.
- Microsoft Defender for Endpoint (Plan 1 or Plan 2) for centralised ASR reporting in the Defender portal — the rules themselves work with Defender Antivirus alone, but the reporting needs MDE.
- A test device group separate from production for the initial Audit-mode pass.
The Problem
ASR rules sit inside Microsoft Defender Antivirus and target the behaviours malware relies on rather than specific files. A rule like "Block all Office applications from creating child processes" stops the classic macro-to-PowerShell chain regardless of which document or payload is involved. That is exactly what makes ASR valuable — and exactly what makes it risky. Plenty of legitimate software does things that look identical to the behaviour ASR blocks. An ERP add-in that shells out to cmd.exe, an installer that runs from a USB stick, a reporting tool that injects into another process — all of these can trip a rule and stop working with no obvious error to the user.
So the problem is not "how do I turn ASR on." Turning it on is a few clicks. The problem is turning it on without generating a wave of help-desk tickets the next morning. The answer is the same discipline I apply to monitoring Windows security events generally: observe before you enforce. ASR has an Audit mode built for precisely this, and the rollout below leans on it heavily. Microsoft's own ASR rules overview is the authoritative reference for what each rule does.
The Solution
Step 1 — Confirm the prerequisites before you deploy anything
ASR rules are a Defender Antivirus feature. If a third-party AV is running in active mode, Defender drops to passive and the rules do not enforce. Confirm Defender Antivirus is the active AV, that real-time protection is on, and that cloud-delivered protection is enabled — three of the most useful rules (advanced ransomware protection, block untrusted executables, block obfuscated scripts) depend on the cloud component. You can confirm the live state on a device with PowerShell:
Get-MpComputerStatus | Select-Object AMRunningMode, RealTimeProtectionEnabled
Get-MpPreference | Select-Object MAPSReporting, CloudBlockLevelOn licensing: the rules enforce with Defender Antivirus, which is in-box on every supported Windows edition. What you pay for with Defender for Endpoint is the centralised ASR reporting, alerting, and advanced hunting in the Defender portal. You can run ASR without MDE, but you will be flying blind on impact, which defeats the careful rollout this whole post is about.
Step 2 — Create the ASR policy in Intune
In the Intune admin center, go to Endpoint security → Attack surface reduction → Create Policy. Choose Windows as the platform and Attack Surface Reduction Rules as the profile. This is the dedicated ASR profile; do not confuse it with the broader "Attack surface reduction" configuration profiles, which mix in exploit protection and other settings.
Inside the profile, every rule is a dropdown with four states. Behind the scenes these map to the registry values you would set with Group Policy or PowerShell:
- Not configured (0) — the rule is off and leaves any existing setting alone.
- Block (1) — the behaviour is blocked and, for most rules, an EDR alert and user pop-up are generated.
- Audit (2) — the behaviour is allowed but logged, so you can see what Block would have stopped.
- Warn (6) — the behaviour is blocked but the user can choose to unblock it; not every rule supports Warn.
Assign the policy to your test device group first, not to all devices. Intune-managed settings overwrite any conflicting local PowerShell configuration on the device, so the Intune policy is your single source of truth once assigned.
Step 3 — Enable the three standard protection rules in Block mode
Microsoft designates three rules as standard protection rules: low business impact, high security value, and safe to enable in Block mode from the start. I turn these on in Block immediately rather than auditing them:
Block abuse of exploited vulnerable signed drivers 56a863a9-875e-4185-98a7-b882c64b5ce5
Block credential stealing from LSASS 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2
Block persistence through WMI event subscription e6db77e5-3df2-4cf1-b95a-636979351e5bThe LSASS rule is the standout. It blocks the credential-dumping technique that tools like Mimikatz rely on, and it is the same threat I covered from the detection side in the Sysmon configuration guide. Two caveats worth knowing: it produces a large volume of audit noise that is mostly safe to ignore, so Microsoft explicitly says you can skip Audit and go straight to Block on a small ring; and if you already run LSA protection or Credential Guard, this rule is redundant and Defender marks it as not applicable.
Step 4 — Roll out the remaining rules in Audit mode
Everything else goes to Audit first. These are the rules most likely to catch a legitimate app, so you want to see the impact before enforcing. The ones I prioritise auditing:
Block all Office apps from creating child processes d4f940ab-401b-4efc-aadc-ad5f3c50688a
Block Office apps from creating executable content 3b576869-a4ec-4529-8536-b80a7769e899
Block executable content from email and webmail be9ba2d9-53ea-4cdc-84e5-9b1eeee46550
Block process creations from PSExec and WMI commands d1e49aac-8f56-4280-b9ba-993a6d77406c
Block Win32 API calls from Office macros 92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b
Block untrusted and unsigned processes from USB b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4
Use advanced protection against ransomware c1db55ab-c21a-4637-bb3f-a12568109d35Leave them in Audit for 30 to 45 days. During that window, the ASR rules report in the Defender portal (Reports → Attack surface reduction rules) shows every audited event: which device, which rule, which process and file. This is your evidence base. A rule with zero audit hits across the fleet is safe to enforce. A rule lighting up on one specific app is telling you exactly which exclusion you need.
Step 5 — Add per-rule exclusions, then move Audit to Block
Where Audit flags a legitimate process, add a per-rule exclusion rather than disabling the whole rule or adding a broad Defender Antivirus exclusion. Per-rule exclusions are scoped to a single ASR rule, so excluding your ERP client from the Office child-process rule does not weaken any other rule. Keep exclusions specific — a full path to the executable, not a wildcard over C:\Program Files.
Once a rule has been quiet in Audit (or only flags processes you have excluded), change its dropdown from Audit to Block and let the policy redeploy. Move in rings: test group, then a pilot of a few hundred devices, then the rest. The WMI-related rules deserve extra care if you run Configuration Manager alongside Intune, because the ConfigMgr client leans heavily on WMI — audit those longer.
Step 6 — Verify enforcement on the endpoint
Trust but verify. On a target device, Get-MpPreference returns the active rule IDs and their corresponding actions as parallel arrays:
$p = Get-MpPreference
for ($i = 0; $i -lt $p.AttackSurfaceReductionRules_Ids.Count; $i++) {
[pscustomobject]@{
RuleId = $p.AttackSurfaceReductionRules_Ids[$i]
Action = $p.AttackSurfaceReductionRules_Actions[$i] # 1 Block, 2 Audit, 6 Warn
}
}Cross-check those GUIDs against the rules you set in Intune. If a device shows nothing, the policy has not applied yet (force a sync) or a non-Defender AV is active. This local check is the fastest way to catch a device that silently fell out of scope.
Frequently Asked Questions
Do I need Microsoft Defender for Endpoint to use ASR rules?
The rules enforce with Microsoft Defender Antivirus, which ships in-box with Windows, so you can run them without Defender for Endpoint. What MDE adds is the centralised ASR rules report, EDR alerts, and advanced hunting. Without it the rules still work, but you cannot see their impact across the fleet, which makes a safe Audit-first rollout much harder.
What are the standard protection rules?
Microsoft groups three rules as standard protection: block abuse of vulnerable signed drivers, block credential stealing from LSASS, and block persistence through WMI event subscription. They are designed to be low-impact and are safe to enable in Block mode without an extended audit period, which is why they are the recommended starting point.
How long should I run ASR rules in Audit mode?
Microsoft recommends roughly 30 to 45 days of Audit before moving a rule to Block, long enough to capture monthly business processes and period-end activity that might only run once a cycle. The standard protection rules are the exception — they can go straight to Block.
Will ASR rules break legitimate applications?
They can. Rules that block child-process creation, code injection, or execution from USB sometimes catch line-of-business software doing the same thing malware does. That is the entire reason for Audit mode and per-rule exclusions — you find the false positives in the report, scope a narrow exclusion to the specific executable, and only then enforce.
Can I deploy ASR rules with PowerShell or Group Policy instead of Intune?
Yes. Add-MpPreference -AttackSurfaceReductionRules_Ids <GUID> -AttackSurfaceReductionRules_Actions Enabled sets a rule locally, and Group Policy works too. But if a device is Intune-managed, the Intune policy overwrites local settings on refresh, so pick one authority. For a managed fleet, Intune is the right place; PowerShell is best for quick testing on a single device.
Conclusion
ASR rules are one of the rare security controls that are both genuinely effective and mostly already licensed. The standard protection rules alone — blocking LSASS credential theft, vulnerable drivers, and WMI persistence — shut down techniques that show up in a large share of real intrusions, and they cost you a few minutes in the Intune console.
The reason ASR has a reputation for being scary is that people enable everything in Block mode at once and then spend a week firefighting. Do it the other way around: standard rules in Block immediately, everything else in Audit for a month, exclusions scoped tight, then enforce in rings. It is slower, but it is the difference between hardening that sticks and hardening that gets switched off after the first outage. Boring and reversible beats clever and disruptive.
Related Posts
- Sysmon Configuration for Windows Security Monitoring — the detection layer that sits behind ASR's prevention, including LSASS access events.
- Essential Windows Event IDs for Security Monitoring — what to watch once ASR is generating block and audit events.
- Windows Security: Detecting Malicious Scheduled Tasks — another persistence technique worth pairing with ASR's WMI rule.
Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.
0 comments:
Post a Comment