Rolling out ASR rules safely: audit mode, exclusions and advanced hunting

Attack surface reduction (ASR) rules shut down behaviour that malware depends on, such as Office apps spawning scripts or processes reading LSASS memory. Switch every rule to Block on day one, though, and you'll discover which line-of-business apps behave like malware the hard way. In this post I'll walk through a phased rollout from Intune: what you can block immediately, how to audit the rest, how to read the results, and how to add exclusions without gutting the protection.

Prerequisites#

• 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. Warn also needs Windows 10 1809 or later, and from Defender platform 4.18.26060 the Unblock option requires administrator approval, so treat Warn as a temporary safety valve rather than a self-service exception.

Step-by-step rollout#

Step 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

Two caveats: if the Configuration Manager client runs on your devices, audit the WMI persistence rule first, because the client leans heavily on WMI. And if LSA protection is already enabled, the LSASS rule adds nothing on top of it.

Step 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. Auditing all of them together is fine; Audit mode doesn't affect users.

Step 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.

The ASR report: Reports › Endpoints › Attack surface reduction rules. The Detections tab filters to standard protection rules by default, so switch Rules to All to see your audit hits.

Advanced hunting: under Hunting › Advanced hunting, ASR events sit in DeviceEvents with an ActionType that names the rule and ends in Audited or Blocked, for example AsrOfficeChildProcessAudited. This query ranks the last 30 days of audit hits:

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

ASR events in hunting are throttled to unique processes per hour, so read the counts as a relative signal, not an exact tally.

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

Step 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.

Exclude a specific file rather than a whole folder wherever you can. Excluded files run without generating ASR events, so every exclusion also costs you visibility. Exclusions take effect when the app or service next starts, so restart it before retesting. Also note that Microsoft documents per-rule exclusions as not applying when Disable local admin merge is turned on; check that setting if an exclusion seems to be ignored.

Step 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 and 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.

References#

• Attack surface reduction (ASR) rules overview
• Configure attack surface reduction (ASR) rules and exclusions
• Monitor attack surface reduction (ASR) rule activity