ASR Rules & Events - MDE Toolkit

Why this mattered

Attack Surface Reduction rules are some of the highest-value protections in Defender, and also some of the most awkward to reason about. A rule can be set by Intune, by Group Policy, or by someone running a PowerShell command on the machine in front of them. Those three sources live in different places, and tools that read only one of them quietly report the other two as “Not Configured”.

That is the difference between “this protection is off” and “this protection is on, but nobody in your fleet management tool knows it”. MDE Toolkit now reads all three and tells you which one won.

1. The Overview — one grid, real answers

🔎

Every rule, every source

Rule state is merged from the Intune/MDM policy key, the classic Group Policy key, and Defender’s own live configuration. On a typical managed device this surfaces rules that were previously invisible.

🏷️

A Source column

Each row says where its setting came from — Intune / GPO, Group Policy, Local, or nothing. Locally-set rules are highlighted, because they are real configuration that will not survive a rebuild and is not enforced across the fleet.

🚫

“Block” means Block

The mode column used to say “Enabled”, which is ambiguous when it sits next to Audit and Warn. It now says exactly what Defender will do: Block, Audit, Warn, or Not configured.

⚠️

Conflict detection

When policy asks for one mode and Defender is enforcing another — a policy that hasn’t applied yet, or a local override — the row is flagged and the reason is spelled out.

📖

Details on demand

Expand a row for the rule GUID, a plain-English explanation of where the setting came from, and any exclusions that apply to that specific rule.

🎛️

Filters that make sense

Filter by mode, by source, or by free text. There is no longer a separate “Not Configured” section — those rules are rows in the same grid, so the picture is complete in one place.

2. Events — find out what actually got blocked

A new sub-page under ASR Rules turns the raw event log into something you can triage.

Repeats are grouped. Events collapse by rule, process and target, sorted by how often they fired. Four hundred blocks of one line-of-business binary is one tuning problem, not four hundred incidents.
Warn bypasses are finally visible. When a user is warned and runs the content anyway, the rule fired and was defeated. Those events are now shown alongside straightforward blocks — previously they were nowhere to be seen.
It works in any language. Fields are read from the structured event data rather than by matching text in the rendered message, so the page behaves the same on a non-English install.
Filter and export. Search, time range, action, rule, and a warn-bypasses-only toggle. Export to CSV when you need it in a ticket.
Check before you exclude. The page generates an Advanced Hunting query for the block you are looking at, so you can find out whether it is noise on one device or a pattern across the fleet before you punch a hole in a control.
Drill-through. Clicking an entry on the Overview’s Recent Events card takes you straight to that event.

3. Exclusions that expire, and that you can audit

Defender has no concept of a temporary exclusion and records nothing about who created one or why. Both of those are problems six months later, when nobody remembers why a folder is exempt from ransomware protection.

🔐 Created safely

Two steps: choose the path, scope and duration and give a required justification; then review the exact command that will run and the command that will undo it before anything is written.
Scoped to one rule by default rather than the blunt all-rules form. Overly broad paths and wildcards are called out.
If Intune or Group Policy owns ASR, or Tamper Protection is on, the tool warns you up front instead of reporting a false success.
Writes are verified against Defender afterwards. A zero exit code is not proof — under Tamper Protection the change can be silently ignored, and the tool reports honestly when it didn’t stick.

⏳ Cleaned up automatically

Pick 4 hours, 24 hours, 7 days or 30 days. The exclusion reverts itself when the clock runs out.
Expiry runs from a scheduled task, so it still happens when the app is closed and the user has gone home.
An audit ledger records who, when, why, the exact commands, and the expiry — in a directory locked to SYSTEM and Administrators.
Reconcile with Defender compares the ledger against live state and reports drift both ways: recorded but missing, or reverted but still present.

Exclusions survive uninstalling the toolkit — deliberately. Permanent exclusions are left in place, and the ledger is preserved as an audit record. Still-active temporary exclusions are reverted first, because a temporary exclusion outliving the tool that promised to expire it would be a silent security hole.

4. Guardrails for administrators

If you don’t want local admins creating permanent exclusions at all, you can say so. These are optional — a device with none of them set behaves exactly as before.

Setting	Type	Default	What it does
`AsrAllowPermanentExclusions`	DWORD	1	`0` removes Permanent, forcing every exclusion to expire.
`AsrAllowTemporaryExclusions`	DWORD	1	`0` removes all temporary durations. Set both to `0` to disable exclusion creation entirely.
`AsrExclusionMaxHours`	DWORD	0	Hard cap in hours; `0` means uncapped. Applied last, so the duration list below cannot widen it.
`AsrExclusionDurationsHours`	SZ	4,24,168,720	Your own duration menu, in hours, comma-separated.
`ForceReadOnlyMode`	DWORD	0	`1` blocks every exclusion write — creation and removal alike.

Enforcement happens where the change is applied, not just in the dropdown, so the policy is not merely cosmetic. Temporary-only with a four-hour ceiling is two values.

Temporary exclusions only, four hours maximum

reg add "HKLM\SOFTWARE\Policies\MDE-Toolkit" /v AsrAllowPermanentExclusions /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\MDE-Toolkit" /v AsrExclusionMaxHours /t REG_DWORD /d 4 /f

Prefer Group Policy? All of these are in the downloadable ADMX templates, under Computer Configuration → Administrative Templates → MDE Toolkit → ASR Exclusion Guardrails.

These are guardrails, not a security boundary. They prevent accidental long-lived exclusions and configuration drift. They do not stop a determined local administrator, who can call Defender’s own cmdlets directly — the audit ledger is what makes that visible.

Who sees what

Setting	Default	Notes
`VisibilityAsrDashboardPage`	1 (admin only)	The ASR Overview grid.
`VisibilityAsrEventsPage`	1 (admin only)	Setting this to `3` gives standard users read-only event triage. Exclusion actions stay hidden regardless — they are gated on elevation independently.

Values are 0 hidden, 1 administrators, 2 standard users, 3 both.

Download MDE Toolkit Full 3.3.1 release notes