← All posts

Attack Surface Reduction Rules: The Defender Feature That Blocks Attacks Before They Run

Defender ships with 20-odd toggles that block the exact behaviors malware needs — Office spawning shells, scripts launching executables, credential theft from LSASS — and most of them are off by default. They are called Attack Surface Reduction rules, and nothing about whether they are on shows up in a vulnerability scan. Here is what each class of rule stops, why audit mode is the only safe way to turn them on, and how to read your ASR posture on the machine in front of you.

Microsoft Defender Antivirus has a feature that does something signature scanning fundamentally cannot: it blocks a process not because the file is known bad, but because the behavior is one that legitimate software essentially never exhibits. Word does not normally launch cmd.exe. A macro does not normally download and execute a payload from the internet. A random unsigned binary on a USB stick does not normally need to run with no questions asked. These are Attack Surface Reduction (ASR) rules, and each one is a narrow, behavior-based interdiction aimed at a technique that real intrusions depend on.

The catch is that most of the high-value rules ship disabled. They are present on every Windows 10/11 and Windows Server box with Defender running in active mode, they cost nothing extra, and an enormous fraction of machines have never turned a single one on. Worse, ASR state is exactly the kind of thing a vulnerability scanner is blind to — patch level and CVE inventory have no opinion on whether a macro can spawn a shell on your machine. It is pure configuration, which means it is invisible unless you go looking, and it drifts silently when an admin flips a rule to audit mode for testing and forgets to flip it back.

What the Rules Actually Block

There are roughly two dozen ASR rules, but they cluster into a handful of attack classes. You do not need to memorize the GUIDs — you need to understand what each family denies, because that maps directly to how phishing-to-foothold actually plays out.

Read that list as an attacker would: every bullet is a step you would otherwise take for granted, turned into a dead end. None of it requires a new agent, a license, or a cloud subscription. It is a Defender feature already sitting on the box.

Audit Mode First — This Is Non-Negotiable

The reason ASR rules stay off is not ignorance; it is fear, and the fear is rational. A rule that blocks “Office creating child processes” will, on some machines, break a legitimate line-of-business macro, a finance add-in, or a vendor tool that does something unusual. Turn that rule straight to Block across a fleet and you will generate help-desk tickets and, worse, teach people that security “breaks things” so the next rollout gets resisted.

The answer is built into the feature. Every ASR rule has three states: Disabled, Audit, and Block (some also support Warn). Audit mode does the full evaluation and logs an event every time the rule would have fired — but lets the action through. You run every rule in audit for a week or two, harvest the events, and discover exactly which legitimate workflows would have been hit. Then you add precise exclusions for the real ones and promote the rule to Block with confidence. Skipping the audit phase is the mistake that gives ASR its reputation for breakage.

# See current ASR rules and their state (per-rule GUID + action):
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions
# Action values: 0 = Disabled, 1 = Block, 2 = Audit, 6 = Warn

# Put a rule into AUDIT mode first (example: block credential theft from LSASS):
Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 `
                 -AttackSurfaceReductionRules_Actions AuditMode

# After review, promote the validated rule to BLOCK:
Set-MpPreference  -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 `
                 -AttackSurfaceReductionRules_Actions Enabled

The audit telemetry lands in the Defender Operational log, where each rule fire is a discrete, reviewable event:

# Defender's own ASR events - 1121 = blocked, 1122 = would-have-blocked (audit), 5007 = settings changed:
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' |
  Where-Object Id -in 1121,1122 |
  Select-Object TimeCreated, Id, Message -First 40

Event 1122 is your gold: every one is a thing a rule would have blocked. If the only 1122s you see are obvious malware behavior, promote to Block today. If you see a legitimate add-in in there, you just saved yourself an outage — write the exclusion, then promote.

Why This Belongs in a Posture Audit

Here is the operational problem with ASR: it is a couple dozen independent toggles, each with three or four possible states, and the “secure” configuration is “the high-value ones in Block, the situational ones in Audit, nothing important left at Disabled.” Verifying that by eye through Get-MpPreference output — matching opaque GUIDs to actions to intended states — is exactly the kind of tedious, every-time check that quietly stops getting done. And because a single Set-MpPreference or a stray GPO can silently knock a rule back to Disabled or Audit, “we turned those on last quarter” is not the same as “they are on right now.”

That is what a configuration audit is for. On the machine in front of you, your full ASR posture — which rules exist, which are blocking, which slid back to audit or off — reads in seconds, at full depth, free:

# Audit Defender's ASR posture (and the rest of the machine) - full depth:
winsentinel --audit

# Capture it as a baseline you can diff against after the next patch cycle:
winsentinel --audit --format json --out asr-baseline.json

# Fix the weak settings that don't belong:
winsentinel --fix-it

This is the gap a vulnerability scanner cannot close. “Is the software patched?” and “can a phished macro still spawn a shell on this box?” are different questions, and a clean CVE report answers only the first. A fully updated machine with every ASR rule disabled is precisely the machine on which the standard phishing chain works end to end. Configuration state is what an attacker exploits the moment they are in — and configuration state is exactly what an audit reads.

Where It Becomes an Org Problem

On a single machine, this is complete. Every ASR check above — rule states, audit-vs-block, drift back to Disabled — runs free and at full depth on the box you own; there is no “upgrade to see the real findings.” The shape of the problem changes at scale. The danger to an organization is not one workstation with ASR off; it is that you cannot see which machines drifted. One imaging template built before ASR was a habit, one GPO that scoped a rule to the wrong OU, one vendor installer that flipped a rule to audit “temporarily” — and now an unknown subset of your fleet is back to letting macros launch shells. From any single box, that is invisible.

That is the boundary where fleet orchestration earns its keep. WinSentinel Pro runs the same ASR audit — identical depth to the free single-machine scan; Pro does not unlock extra rules or deeper checks — through an agent on each endpoint, reporting into a central node. What it adds is the org-level answer: a fleet rollup that says “42 of your 300 machines have the LSASS-protection rule disabled” in one view instead of 300 separate Get-MpPreference runs; drift alerts when a deployment knocks a blocking rule back to audit across the fleet; and compliance evidence that your endpoints held a blocking ASR posture across an audit window. Single-machine hardening is free and total. The “which of my machines silently stopped blocking the phishing chain?” question, answered as one report, is the org problem Pro exists to solve.

The Takeaway

Attack Surface Reduction is the rare security control that is already installed, costs nothing, and blocks the actual opening moves of real intrusions — and it is off by default on most machines because turning it on without a test phase has a reputation for breaking things. The discipline is simple: enable every rule in audit mode, watch the 1122 events for a week, exclude the handful of legitimate workflows you find, then promote the high-value rules to Block. Do that and a phished macro, a USB payload, an LSASS dump, and an obfuscated script all hit a wall that a fully patched, signature-scanned machine would have let straight through.

# See your ASR posture right now, then close the gaps:
winsentinel --audit
winsentinel --fix-it

Signatures catch the malware you already know about. ASR catches the behavior that all of it shares — which is how you stop the variant nobody has a signature for yet.