ASR rules rollout & troubleshooting guide

Before you start

• Defender Antivirus must be the active antivirus. ASR rules don't run when Defender is in passive mode, EDR in block mode, limited periodic scanning or off. Real-time protection must be on, and several rules also rely on cloud-delivered protection.
• Reporting licences. The ASR report needs Defender for Endpoint Plan 2 (or Defender for Business) and advanced hunting needs Plan 2. Event Viewer works with any licence.
• Device groups as rings. Target ASR policies at Microsoft Entra device groups: a small pilot, a broader early-adopter ring, then everyone.

How the rule modes work

Every rule in the Intune policy has its own mode:

• Two rules don't support Warn: Block credential stealing from the Windows local security authority subsystem and Block Office applications from injecting code into other processes.

Checklist

1. 1

   Block the standard protection rules

   Microsoft labels three rules as standard protection and recommends Block without lengthy testing, because they rarely touch legitimate work:

   • Block abuse of exploited vulnerable signed drivers
   • Block credential stealing from the Windows local security authority subsystem
   • Block persistence through WMI event subscription
2. 2

   Create the audit policy

   In the Microsoft Intune admin center, go to Endpoint security › Attack surface reduction › Create policy, choose platform Windows and profile Attack Surface Reduction Rules. Set the standard protection rules to Block, every other rule you plan to use to Audit, and assign the policy to the pilot ring.

   Watch out: on devices with the Configuration Manager client, Microsoft advises against enabling Block process creations originating from PSExec and WMI commands through Intune or any other channel, because the client depends on WMI.

3. 3

   Measure what would have been blocked

   Leave the pilot in Audit long enough to cover your business cycles, such as month-end jobs and patch nights, then review the data.

   This query ranks the last 30 days of audit hits:

   kusto

   DeviceEvents
   | where Timestamp > ago(30d)
   | where ActionType startswith "Asr" and ActionType endswith "Audited"
   | summarize Hits = count(), Devices = dcount(DeviceId)
       by ActionType, FileName, FolderPath, InitiatingProcessFileName
   | order by Hits desc

   Event Viewer: on a single device, open Applications and Services Logs › Microsoft › Windows › Windows Defender › Operational:

   Event ID	Meaning
   1121	A rule fired in Block mode
   1122	A rule fired in Audit mode
   1129	A user overrode a Warn-mode block
   5007	Defender settings changed (handy to confirm the policy landed)

4. 4

   Add exclusions, as narrowly as possible

   For each audit hit, decide whether it's legitimate. For genuine business processes, the same Intune policy offers two lists:

   • ASR only per rule exclusions appear under a rule once it's set to Audit, Block or Warn, and apply to that rule only. Make these your default.
   • Attack surface reduction only exclusions apply to every ASR rule. Keep this list short.
5. 5

   Promote rules to Block, ring by ring

   When a rule shows no unexplained audit hits in the pilot, change it to Block (or Warn, where supported) for that ring, watch event 1121 and the helpdesk queue, then move to the next ring. Keep one policy in charge of each rule so no two policies give the same rule different modes.

Verify

• On a test device, list the rules Defender actually holds and their modes:

$p = Get-MpPreference
for ($i = 0; $i -lt $p.AttackSurfaceReductionRules_Ids.Count; $i++) {
    [pscustomobject]@{
        RuleId = $p.AttackSurfaceReductionRules_Ids[$i]
        Mode   = $p.AttackSurfaceReductionRules_Actions[$i]
    }
}

• The mode values match the table above (1 Block, 2 Audit, 6 Warn). In the portal, the report's Configuration tab shows how rules are set across devices, and promoted rules should move from ...Audited to ...Blocked action types in hunting.

Tips & gotchas

• Don't manage a rule from both Group Policy and Intune. When both set the same rule, Group Policy wins by default unless you deploy MDMWinsOverGP through a custom profile.
• The LSASS rule is noisy in Audit. Microsoft notes most of its audit events are safe to ignore, which is one reason it belongs in Block from the start.
• Office rules need an app restart. Changes to the Office code-injection rule apply only after Microsoft 365 Apps restart.
• Diagnostics can trip rules. The PsExec/WMI rule blocks the MDE Client Analyzer's connectivity checks; add a temporary exclusion or audit the rule while you collect logs.