Article • • 5 minute read

Microsoft Defender for Endpoint: Attack Surface Reduction (ASR)

Seeing a device on the dashboard is not the same as protecting it. This article shows how attack surface reduction rules in Microsoft Defender for Endpoint close the behaviors attackers commonly abuse, how Audit, Warn, and Block modes work, and how a business can move rules from Audit to Block without breaking the tools its people rely on every day.

In this article

 Summary

Attack Surface Reduction (ASR) rules target risky software behavior that attackers commonly abuse on Windows devices. Each rule runs in a mode that controls what happens when it fires, and the safe path is to test in Audit, add narrow exclusions, and move to Block ring by ring. This article covers what the rules protect, what they require, and how to deploy and monitor them.

 Seeing Is Not Protecting

In the previous ATC Byte on Microsoft Defender for Endpoint: Onboarding, A.M Finances Group brought all 200 of its new laptops into the Microsoft Defender portal, so the security team can see every one. Visibility is the starting line, not the finish. A loan officer can still open a spreadsheet from an email that quietly starts a script, and nothing on screen looks wrong.

ASR rules exist to close behaviors like that. Microsoft describes them as rules in Microsoft Defender Antivirus that target risky software behavior on Windows devices. Legitimate apps might do some of these things too, but attackers commonly build malware that behaves the same way.

 Lock the Risky Doors

ASR rules do not only ask whether a file is malicious. They also ask whether an application should be doing something in the first place: an Office app launching another process, a script starting an executable it just downloaded, or code reaching into the local security authority subsystem for credentials. Microsoft's rule reference lists 19 rules.

Figure 1. Each rule is a door, and each door has a mode: Not configured, Audit, Warn, or Block
Figure 1. Each rule is a door, and each door has a mode: Not configured, Audit, Warn, or Block

They are a Windows feature, so they are not available on Linux or macOS, even on devices onboarded to Defender for Endpoint. They require Microsoft Defender Antivirus as the primary antivirus, enabled and in active mode, with real-time protection on, and Microsoft calls cloud-delivered protection critical to how they work. Microsoft Intune endpoint security policies are the recommended way to deploy them, and Group Policy, Configuration Manager, and PowerShell also work.

 Start With the Standard Three

Three rules are called standard protection rules: block abuse of exploited vulnerable signed drivers, block credential stealing from the Windows local security authority subsystem, and block persistence through WMI event subscription. Microsoft recommends enabling them in Block mode without the need for extensive testing.

A few caveats help. The vulnerable driver rule stops apps from saving vulnerable signed drivers, but it does not stop loading drivers already on the computer. The credential-stealing rule is redundant if you enabled LSA protection, which Microsoft recommends along with Credential Guard. And if Configuration Manager manages your devices, test the WMI rule extensively in Audit mode before moving it to Block or Warn.

 Four Modes, One Staircase

Every rule runs in one of four modes: Not configured, Audit, Warn, or Block. Not configured means the rule is not explicitly enabled. Audit acts as if the rule were blocking but takes no action, which makes it the safe way to learn what would break. Block simply stops the behavior.

Warn blocks too, but a user can select Unblock to bypass the block for 24 hours. That choice now needs administrator approval, a change that arrived with a recent platform update, so Warn is temporary relief and not a lasting exception. Warn is not available for the credential-stealing and Office code injection rules, and not in Configuration Manager.

 Audit First, Then Block

Microsoft's deployment guide frames the work as four phases: plan, test in Audit, enable in Block ring by ring, then manage and monitor. For testing, Microsoft says to enable all the rules in Audit at the same time, so you can see which ones everyday business activity triggers. Audit does not affect users, and it logs events you can review.

When a rule flags a legitimate app, add an exclusion. Then move to Block, starting with the rule that has the fewest triggered events, and widen to the next ring when the first looks right. At A.M Finances Group, Audit showed that a finance workbook launched a helper script. The team added a per-rule exclusion for that one file instead of switching the rule off, then moved the quietest rules to Block first. Keep exclusions narrow, because excluded files are allowed to run and nothing is recorded about them.

 Read the Evidence

The ASR rules report in the Defender portal, under Reports and Endpoints, is the main dashboard. Its Detections tab shows audited and blocked detections, the Configuration tab shows how each device is set up, and the Add exclusions tab lists the files rules are flagging.

For more detail, use the device timeline and advanced hunting, which queries the DeviceEvents table for action types that start with Asr. Windows Event Viewer works on any plan: event 1121 means a rule fired in Block mode, 1122 means Audit, 1129 means a user overrode a block in Warn mode, and 5007 means settings changed. Microsoft lists the report and device timeline for Defender for Endpoint Plan 2 or Defender for Business, and advanced hunting for Plan 2.

 Conclusion

Visibility gets a device into Microsoft Defender for Endpoint, and ASR rules reduce what attackers can do once it is there. Turn on the standard protection rules, test every other rule in Audit, keep exclusions narrow, and move to Block one rule and one ring at a time. A.M Finances Group went from laptops it could see to laptops with the risky doors locked, without any surprises for the business.