Attack surface reduction rules: GUIDs and safe rollout

Attack surface reduction (ASR) rules are behaviour blocks built into Microsoft Defender Antivirus. Instead of recognising a malicious file, they stop a behaviour that malware needs and legitimate software rarely does: Word spawning PowerShell, a script launching a freshly downloaded executable, an unknown process reading LSASS memory. Because they don't depend on signatures, they stop new malware as well as old.

They are also free with Windows, configurable by Group Policy, and have an audit mode. The main reason they are not enabled everywhere is fear of breaking a business application. This guide gives you the full rule list and a rollout that manages that risk.

Requirements

• Microsoft Defender Antivirus as the primary antivirus, with real-time protection on (not passive mode).
• Cloud-delivered protection on, since some rules depend on it (notably the prevalence rule).
• Windows 10 / Windows Server 2019 or later for the full set; a few rules have narrower support (the webshell rule is for servers).

The rules

Microsoft keeps adding rules; the two most recent are the Safe Mode and copied-system-tools rules at the end of the table. Keep your Defender platform current (Microsoft requires it to be no more than two versions behind for ASR) and check the ASR rules reference when new rules appear.

Each rule takes one of these states: 0 Disabled, 1 Block, 2 Audit, 5 Not configured, 6 Warn. Warn lets the user click through a block for 24 hours, which is useful for the noisier rules on workstations. It is not supported by the LSASS and Office code-injection rules, and not through Configuration Manager.

Rollout

1. Standard protection straight to block

The three standard protection rules rarely collide with legitimate software. Put them in block mode everywhere, with one exception: on devices managed by Configuration Manager, whose client relies heavily on WMI, Microsoft asks you to test the WMI persistence rule in audit mode first.

$std = "56a863a9-875e-4185-98a7-b882c64b5ce5",
       "9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2",
       "e6db77e5-3df2-4cf1-b95a-636979351e5b"
Add-MpPreference -AttackSurfaceReductionRules_Ids $std `
  -AttackSurfaceReductionRules_Actions Enabled,Enabled,Enabled

2. Everything else in audit for two to four weeks

In Group Policy: Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction > Configure Attack Surface Reduction rules. Enable it and add one line per rule, GUID in Value name, state in Value. In Intune use an Attack surface reduction rules profile under Endpoint security. For a lab:

Add-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a `
  -AttackSurfaceReductionRules_Actions AuditMode

Use Add-MpPreference rather than Set-MpPreference when you add rules one at a time: Set- replaces the whole list.

3. Read the events

ASR events are in Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational:

Each event gives the rule GUID, the process path and the target. Group by rule and process across the fleet. You will typically find a short list of real collisions: a document management add-in spawning a helper, a line-of-business app that writes executables from a VBA macro, a management agent launched through WMI.

Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" |
  Where-Object Id -in 1121,1122 |
  Select-Object TimeCreated, Id, Message -First 50

4. Exclude narrowly, then block

Fix what you can (update the add-in, sign the script, replace the macro). For the rest, prefer per-rule exclusions, which exist on current Defender platform versions, over global ASR exclusions:

# Global ASR exclusion (applies to all rules): use sparingly and with full paths
Add-MpPreference -AttackSurfaceReductionOnlyExclusions "C:\Program Files\Contoso\DocHelper.exe"

Never exclude powershell.exe, cmd.exe, wscript.exe, whole user-writable folders like %TEMP% or %APPDATA%, or the Office binaries themselves. That doesn't narrow the rule, it turns it off.

Then move rules to block ring by ring (IT, pilot users, then everyone), keeping a watch on 1121 volume after each step.

5. Verify on the endpoint

$p = Get-MpPreference
for ($i = 0; $i -lt $p.AttackSurfaceReductionRules_Ids.Count; $i++) {
  "{0}  {1}" -f $p.AttackSurfaceReductionRules_Ids[$i], $p.AttackSurfaceReductionRules_Actions[$i]
}

If rules configured by GPO or Intune don't appear, check that Defender is the active antivirus (Get-MpComputerStatus | Select AMRunningMode should be Normal) and that no conflicting local and managed policies exist.

Exploit protection

ASR's sibling is exploit protection (the successor to EMET), configured under Windows Security > App & browser control > Exploit protection or via an exported XML applied by the Use a common set of exploit protection settings policy. System-wide defaults (DEP, bottom-up ASLR, CFG, SEHOP) should stay on. Per-application mitigations are worth adding for exposed legacy apps, but test them: forcing mandatory ASLR on an old binary can crash it.

Get-ProcessMitigation -System

Checklist

• Defender AV is primary, real-time and cloud protection on
• Three standard protection rules in block mode everywhere
• Remaining rules audited for 2 to 4 weeks, events 1122 reviewed
• PSExec/WMI rule only where Configuration Manager is not used
• Exclusions narrow, per-rule where possible, documented with an owner
• Rules in block mode by ring; event 5007 monitored for tampering

ASR rules are among the highest-return settings on Windows. For the antivirus they depend on, see the Microsoft Defender hardening guide; for stopping unknown executables altogether, application control.