Defender ASR Rules via GPO: Verify Endpoint Configuration

What Are Defender ASR Rules via GPO?

Defender ASR rules via GPO let administrators distribute behavior-based protections to Windows devices through Group Policy. Attack surface reduction (ASR) rules target activity such as Office applications creating child processes or scripts launching downloaded executables. The useful question is which rule GUIDs, modes and exclusions the target device actually has, rather than whether an ASR policy exists. Microsoft configuration guidance

A policy can describe an intended protection without demonstrating that every computer receives it. Audit mode can record relevant activity without blocking it; exclusions can change what a rule evaluates. Review the deployment source and the endpoint configuration together before reporting coverage.

This walkthrough uses Microsoft Learn pages checked on 3 October 2026 and the reviewed etc-collector implementation. The PowerShell commands are documentation-based examples for an authorized Windows administrator; they were not executed against a Windows estate for this article. No endpoint coverage, attack prevalence or successful remediation is claimed.

How It Works: A Rule, Mode and Exclusion Matrix

ASR configuration is a list of rules with individual actions. In Group Policy Management, edit the intended GPO under Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → Attack Surface Reduction. Open Configure Attack Surface Reduction rules, select Enabled, then use Show... to enter each rule GUID as the value name and its mode as the value. Older templates can use Windows Defender Antivirus in the path. Microsoft's GPO procedure

The numeric actions documented by Learn are:

The values come from the ASR configuration page. Mode availability, dependencies and operating system support still need a rule-specific review in the ASR rules reference.

Build a matrix with one row per intended rule and target population. The following rows are review examples, not a recommended complete rule set or measurements from an environment:

Microsoft documents an installation-location condition for the Office rule: Office must be installed under %ProgramFiles% or %ProgramFiles(x86)%. It also says the LSASS rule is not required and provides no extra protection when LSA protection is enabled, recommending that protection alongside Credential Guard. Do not treat every available rule as an unconditional requirement. Rule-specific details

Our Credential Guard after upgrade guide explains how to verify VBS-based credential isolation and inherited disablement. That evidence does not establish the configuration of the wider ASR behavior-rule set. Keep the protections' applicability and measurements separate.

Establish which management source wins

A GPO entry and an Intune profile can conflict for the same rule. The current Learn configuration page documents policy-based settings taking precedence over local Set-MpPreference settings on startup. That page describes Group Policy as winning by default against MDM, with MDMWinsOverGP=1 favoring MDM, and advises against configuring the same ASR rules through both sources. Microsoft's separate Defender troubleshooting guidance warns that this switch does not apply to ASR rules on Windows 10. These pages differ on that boundary: verify the target OS and observed policy result instead of assuming the flag resolves every conflict.

There is another explicit boundary: controlled configuration enforces Intune or Defender for Endpoint security settings management settings and ignores conflicting Group Policy, Configuration Manager and local settings. Check whether that mechanism applies before assigning ownership to the GPO. Microsoft's policy-conflict handling

Record the intended management source, the device population, conflicting profiles and the evidence for the winning configuration. A temporary local PowerShell change can disappear when managed policy takes effect. It is therefore unsuitable as the sole proof that the managed rollout is fixed.

Detection: Compare GPO Intent with Endpoint Configuration

Step 1: Preserve the intended policy

Read the configured GUID/action list and exclusions from the actual GPO. Inspect its decoded registry.pol data for the Windows Defender Exploit Guard ASR branch, keeping the GPO identity and collection time with the evidence. A binary policy file needs policy-aware decoding; a filename alone does not reveal its settings.

Keep the per-rule list distinct from the aggregate exploitguard_asr_rules DWORD used by the collector parser described below. An enabled aggregate setting is not an inventory of GUIDs and actions.

Our guide to four Active Directory GPO security checks applies the same verification method to LLMNR, WSUS, LSA protection and UNC paths: compare policy intent, target scope and client evidence. Those four controls do not establish ASR coverage; their verification discipline is useful here.

Step 2: Read the target device's preferences

On each target being assessed, retrieve Defender preferences. The Get-MpPreference reference documents the cmdlet and its local default. The ASR configuration page documents the rule-ID and action properties.

Run the following separately in the target's administrative PowerShell session:

$p = Get-MpPreference

$p.AttackSurfaceReductionRules_Ids

$p.AttackSurfaceReductionRules_Actions

Match entries by their array position: the action at an index belongs to the rule ID at that index. Preserve the original output. If either list is missing, the lengths differ, or collection fails, record the result as unresolved rather than silently dropping entries or declaring compliance.

For an aligned, nonempty pair of arrays, this example displays the correspondence:

for ($i = 0; $i -lt $p.AttackSurfaceReductionRules_Ids.Count; $i++) {
    [pscustomobject]@{
        Id = $p.AttackSurfaceReductionRules_Ids[$i]
        Action = $p.AttackSurfaceReductionRules_Actions[$i]
    }
}

Review global ASR exclusions with Microsoft's documented read command:

(Get-MpPreference).AttackSurfaceReductionOnlyExclusions

Also inspect per-rule exclusions in the authoritative management policy. The global list alone is not a complete exception review when rule-specific exclusions are configured. Microsoft exclusion configuration

Compare each expected GUID and mode with the endpoint output. Investigate missing rules, unexpected actions and unexpected exclusions. Include the host, observation time and management source in the record; repeat after policy application to distinguish a transient local setting from the managed result. These preferences establish device configuration, while activity telemetry supplies evidence of a rule firing.

Step 3: Review ASR events

In Event Viewer, navigate to Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational. Microsoft lists the following ASR rule events on its Windows Event Viewer page:

Correlate the rule identifier, device, time and activity with the configuration matrix. Microsoft also documents Windows Event Forwarding for centralizing collection. Its deployment testing guidance distinguishes local Event Viewer from reporting capabilities that depend on the Defender product and plan.

Remediation: Pilot, Review and Enforce the Approved Rules

Step 1: Define a representative pilot

Choose a controlled device population and application owners. Check support and dependencies for the selected rules, establish the management source, and record the initial endpoint preferences. Include the business workflows likely to exercise the rules, rather than treating an idle device as a compatibility test.

Microsoft's deployment guide organizes the work into planning, testing, enablement and ongoing monitoring. It says standard protection rules can typically begin in Block or Warn without testing, while other rules should be evaluated in Audit first. An Audit pilot is a deliberate evaluation choice here, not a claim that Microsoft requires the same sequence for every rule.

Step 2: Configure Audit through the owning policy

For the GPO-managed pilot, enable Configure Attack Surface Reduction rules and populate Show... with the selected GUIDs and action 2. Use the documented values without quotation marks, extra characters or leading/trailing spaces. Confirm that the intended pilot computers receive that GPO, then repeat the endpoint preference collection.

For example, the Office child-process rule's value name is d4f940ab-401b-4efc-aadc-ad5f3c50688a; its Audit value is 2. This illustrates Microsoft's GUID/action mapping, not a discovered configuration. GPO rule configuration

Step 3: Review events and document application exceptions

Use Audit activity to identify legitimate workflows that enforcement could interrupt. Review the actual process and file context with the application owner before approving an exclusion. Record the affected rule, exact exception, reason, owner and review decision.

Group Policy provides both global exclusions and per-rule exclusions. Learn documents specific-file exclusions as preferable to excluding a whole folder in its global GPO procedure. Rule-specific exclusions require the appropriate administrative templates; the current page identifies 24H2 or later templates when that setting is absent from GPMC. Verify the available setting before designing the rollout around it. Microsoft GPO exclusions

Step 4: Move to Block or supported Warn, then verify again

Change the approved rule actions in the owning policy to Block 1, or Warn 6 where supported and appropriate. The LSASS credential-stealing rule does not support Warn. Expand through deployment rings after reviewing application behavior and the endpoint configuration. Deployment guide and rule reference

Repeat the GUID/action comparison and review Block events or Warn overrides. A completed GPO edit is not the acceptance criterion. Close the rollout decision for a population when the intended configuration is observed on its assessed devices, relevant workflows have been reviewed and remaining exceptions or unknown devices are explicit.

Avoid replacing a managed rule list with a local convenience command. Microsoft warns that Set-MpPreference overwrites the existing rules and actions supplied through that cmdlet, and that managed settings overwrite conflicting local changes on startup. Resolve the source conflict and preserve unrelated configuration. PowerShell configuration behavior

How EtcSec Detects This

EtcSec's etc-collector includes DEFENDER_ASR_NOT_CONFIGURED, a Medium-severity GPO configuration check. The reviewed defender-asr.go implementation calls FindRegistrySettingInt for DefenderASREnabled. A missing value or a value other than 1 produces Count 1; a value of 1 leaves Count 0.

The helper prioritizes a non-nil value from Default Domain Controllers Policy, then Default Domain Policy, then another available GPO. This is the collector's lookup order, not Windows policy precedence for an individual endpoint. It does not compute each computer's effective links, filtering, inheritance or MDM conflicts.

The reviewed registrypol_parser.go populates the field only from a DWORD named exploitguard_asr_rules in a key containing Windows Defender and ASR. It does not populate the full GUID/action inventory for this check. The aggregate value tested against 1 must not be interpreted as every rule's Block action.

Use this signal to open a focused configuration investigation. Attach the intended GPO list, endpoint preferences and relevant ASR events to the remediation record. Keep unavailable measurements unresolved until collected; a domain-level configuration check cannot substitute for endpoint evidence.