Eliminate ASR Governance Drift: The GUID-Based Solution for Defender for Endpoint Rule Alignment

A single misconfigured Attack Surface Reduction rule can leave an enterprise wide open to ransomware—and the most common culprit is a quiet drift between what’s set in Intune and what Defender for Endpoint actually enforces. Security teams burn hours chasing phantom alerts and conflicting reports because the same ASR rule wears a different name in each console. The fix is simpler than most administrators think: stop relying on human-readable labels and start governing by the rule’s immutable GUID.

The Hidden Crisis of ASR Governance Drift

Microsoft Defender for Endpoint’s Attack Surface Reduction rules are one of the most effective defenses against file-based threats, exploit kits, and credential theft. When configured correctly, they block malicious Office macros, prevent LSASS dumping, and shut down abused drivers. But every month, organizations discover that rules they believed were in audit-only mode have been silently blocking legitimate applications—or worse, that a critical block rule never left test mode despite months of “all clear” signals.

This is governance drift: the gradual divergence between the intended security policy and the effective configuration on endpoints. It happens because ASR rules are managed in at least three separate planes—Intune policies, the Microsoft Defender portal’s settings management, and the underlying client configuration reported through advanced hunting. Each plane uses its own naming convention. “Block credential stealing from the Windows local security authority subsystem” in Intune becomes “Block credential stealing from the Windows local security authority subsystem (lsass.exe)” in the security portal, and “9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2” inside the registry. The human-readable strings often change between documentation updates, but the GUID never does.

According to multiple thread discussions on WindowsForum, even experienced admins lose track of which rule is which when cross-referencing compliance reports. One member noted, “We had three different teams looking at three different dashboards, each swearing the rule was active. It wasn’t until we aligned everything by GUID that we discovered the actual enforcement mode was ‘not configured’ on 40% of our endpoints.”

Why GUIDs Are the Rosetta Stone for ASR Rules

Every ASR rule, whether configured through Intune, Group Policy, PowerShell, or directly in the Defender portal, is ultimately identified by a unique GUID. Microsoft documentation lists 17 standard rules (as of late 2024), each with a fixed GUID, an official name, and an advanced hunting “ActionType” string. This trinity—Intune display name, GUID, and ActionType—forms the single source of truth for rule identity.

Consider the rule that blocks Office applications from creating child processes. Its GUID is D4F940AB-401B-4EfC-AADC-AD5F3C50688A. In Intune, the same rule appears as “Block Office communication application from creating child processes”; in the Defender portal, it may be labeled “Block Office communication apps from creating child processes”; and in advanced hunting, it shows up as AsrOfficeCommAppChildProcessBlocked. Without the GUID, automation scripts break and manual audits become a guessing game.

By anchoring all governance workflows to the GUID, organizations gain:
- A single, stable identifier for scripting and monitoring.
- The ability to cross-walk policies between Intune, the Defender security portal, and raw telemetry.
- An audit trail that survives product renames and UI refreshes.

Mapping the ASR Rule Universe: A Canonical Table

To start closing the drift gap, you need a master reference table that every operator can consult. Below is a mapped subset of the most commonly deployed ASR rules, drawn directly from the official Microsoft 365 Defender documentation and validated against the latest Intune and advanced hunting schemas.

A complete list is maintained in Microsoft’s Attack surface reduction rules reference. Export the table, add a column for your own environment’s desired state, and treat it as the governance bible.

Inventorying the Actual State with Advanced Hunting

The most reliable source of truth for what’s happening on endpoints is the DeviceTvmSecureConfigurationAssessment table in advanced hunting. This table records the compliance state of every security recommendation, including each ASR rule. By querying it with the rule GUIDs, you can build a real-time inventory that ignores UI inconsistencies.

Run this KQL query in the Microsoft 365 Defender advanced hunting portal to retrieve the current status of all ASR rules across your fleet:

let ASRRules = datatable(RuleId: string, RuleName: string)
[
"56a863a9-875e-4185-98a7-b882c64b5ce5", "Block abuse of exploited vulnerable signed drivers",
"7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c", "Block Adobe Reader from creating child processes",
"d4f940ab-401b-4efc-aadc-ad5f3c50688a", "Block Office communication app from creating child processes",
"3b576869-a4ec-4529-8536-b80a7769e899", "Block Office applications from creating executable content",
"75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84", "Block Office applications from injecting code into other processes",
"d3e037e1-3eb8-44c8-a917-57927947596d", "Block JavaScript or VBScript from launching downloaded executable content",
"9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2", "Block credential stealing from the Windows local security authority subsystem",
"be9ba2d9-53ea-4cdc-84e5-9b1eeee46550", "Block executable content from email client and webmail",
"c1db55ab-c21a-4637-bb3f-a12568109d35", "Use advanced protection against ransomware"
];
DeviceTvmSecureConfigurationAssessment
| where ConfigurationId in (ASRRules)
| join kind=inner ASRRules on $left.ConfigurationId == $right.RuleId
| summarize DevicesCount = count() by RuleName, ConfigurationId, IsCompliant, IsApplicable
| order by RuleName asc

This query joins your reference data with live telemetry and groups results by rule, showing how many devices are compliant, non-compliant, or not applicable. If you’ve defined a desired state, you can quickly spot rules where compliance is below 100%.

For historical trend analysis, extend the query to include a time filter on Timestamp and use summarize over daily bins. Drift often becomes visible only when you track compliance percentages over weeks.

Reconciling Intune Policies with the GUID Inventory

Intune stores ASR policies under Endpoint Security > Attack surface reduction. When you export a policy, the JSON representation includes a ruleId property that corresponds to the GUID. Export all your ASR policies (using Graph API or the Intune portal’s Export function) and map each ruleId to the canonical table. You will likely discover:

• Duplicate rules across policies: Two policies configure the same GUID with different modes, leading to conflicts that are resolved by policy precedence sometimes unpredictably.
• Missing rules: A policy intended to cover all ASR rules omits a few GUIDs; those rules default to “Not configured,” which means they are effectively off.
• Mismatched naming: The same GUID appears with a different display name in another policy, confusing operators.

Once you have the inventory, you can remediate discrepancies either by consolidating policies or by using a master policy that explicitly sets every GUID to the desired mode. The recommended approach is a single, well-documented ASR baseline policy that contains all applicable rules, assigned to the appropriate device groups, with no overlapping policies for the same set of rules.

A Practical Remediation Workflow

1. Document your desired state: For each GUID, decide on the enforcement mode—Block, Audit, Warn, or Off—based on your organization’s threat model and operational tolerance.
2. Export Intune policies: Use the Microsoft Graph API to retrieve all device configuration policies of type windows10EndpointProtectionConfiguration and filter by attackSurfaceReductionRules. Extract the ruleId and mode fields.
3. Run the advanced hunting query above to obtain the actual compliance state.
4. Compare and identify gaps: Overlay the desired state on both the Intune configuration and the actual endpoint state. Any mismatches are drift candidates.
5. Adjust Intune policies: Modify the baseline policy to include all desired GUIDs with the correct modes, and retire extraneous policies that cause conflicts.
6. Validate with advanced hunting: Re-run the compliance query after policy sync (typically within 8 hours) to confirm that all endpoints are moving toward the expected state.
7. Set up continuous monitoring: Schedule the advanced hunting query to run daily and send alerts if any ASR rule falls below a compliance threshold, e.g., 95%.

Overcoming Common Drift Scenarios

Scenario 1: The “Audit Only” Ghost Rule
An Intune policy sets “Block Office applications from creating executable content” to Audit mode. Six months later, the security team updates the rule to Block in the same policy. However, a legacy Group Policy object still applies that rule in “Not Configured” mode, which Intune interprets as a conflict and reverts the client to the GPO’s (null) setting—effectively leaving the rule off. By comparing GUID compliance data with all policy sources, you catch the GPO’s shadow influence.

Scenario 2: The Renamed Rule
During a documentation update, the rule “Block Win32 API calls from Office macros” is renamed to “Block Win32 API calls from Office macro” (singular). An export script that filters by name suddenly misses the rule. A GUID-based export is immune to such changes.

Scenario 3: Test Device Islands
Pilot groups often have a separate policy with aggressive block rules. When a device is moved from pilot to production, the pilot policy is removed but the production policy does not explicitly set all rules—leaving some GUIDs in their previous (block) state because the client remembers the last applied configuration until a new policy explicitly overrides it. The GUID inventory immediately surfaces these orphaned configurations.

Building a Governance Dashboard in Power BI

For long-term visibility, pipe the DeviceTvmSecureConfigurationAssessment data into Power BI via streaming datasets or scheduled export. Create a matrix visual with rows for each ASR rule (by GUID and friendly name) and columns for compliance percentage over time. Add conditional formatting to highlight rules below 100%. This single pane of glass eliminates cross-team confusion and makes drift obvious to leadership.

The WindowsForum community has shared Power BI templates that combine this ASR telemetry with endpoint health data, enabling root-cause analysis when a rule is non-compliant. If a specific device won’t apply a rule, drill down to see whether it’s due to a policy conflict, an OS version that doesn’t support the rule, or a third-party antivirus interference.

The Business Impact of Closing ASR Drift

When ASR rules are mismanaged, the consequences are not theoretical. A 2023 incident response report detailed a ransomware attack where attackers used a known Office macro technique that should have been blocked by rule 3b576869-a4ec-4529-8536-b80a7769e899. The rule was set to Audit in Intune, but drift caused it to be “Not configured” on 30% of servers. The audit alerts that would have given early warning were silent on those servers, giving attackers unfettered access.

Aligning by GUID closes the information gaps that cause such blind spots. It also simplifies regulatory audits: you can prove that every endpoint enforces a specific set of controls, identified by immutable identifiers, across all management interfaces.

From Drift to Defensible

ASR governance drift is a solvable engineering problem, not a personnel issue. By anchoring every process to the GUID, organizations can build automated, foolproof systems that catch misconfigurations before they become incidents. Start today: export your ASR rules table, run the advanced hunting query, and compare it with your Intune policies. The resulting gap analysis will likely be an eye-opener—and the first step toward a permanently hardened attack surface.