Windows ASR rules: block macros and ransomware

A large share of attacks against SMBs relies on the same handful of techniques: a booby-trapped Office macro, a script that steals credentials from memory, or an executable launched straight from an email. These methods work because they abuse perfectly legitimate features of Windows and Office. Microsoft Defender's Attack Surface Reduction (ASR) rules block these behaviours at the source, with no third-party antivirus and no heavy configuration. They are part of Microsoft Defender for Endpoint and are fully manageable from Intune, which makes them one of the best effort-to-impact hardening moves for a Windows fleet.

The key idea: instead of waiting for an antivirus to recognise a malicious file by signature, ASR forbids in advance the chains of events that healthy software never needs. A Word document has no legitimate reason to launch PowerShell, and a mail client has no business running a downloaded .exe. By closing those paths, you neutralise entire families of attacks without having to know each one individually.

What ASR rules actually do

ASR rules are guardrails built into Defender that forbid actions commonly used by malware while leaving legitimate work untouched. They do not match a signature: they stop a behaviour. Each rule targets a specific, documented attack vector.

• Block executable content launched from an email client or webmail.
• Prevent Office applications from creating child processes, the classic malicious-macro vector.
• Block credential theft from the Windows LSASS subsystem.
• Stop JavaScript and VBScript from launching downloaded executables.
• Block execution of potentially obfuscated scripts.
• Use advanced protection against ransomware.

A concrete example of a blocked attack

Take a common scenario. An accountant receives a fake invoice as a Word file. The document asks them to enable macros to "see the content". Once enabled, the macro tries to launch PowerShell to download ransomware. Without ASR, this chain runs unobstructed. With the rule that prevents Office from creating child processes, the macro fails at the exact moment it calls PowerShell: the attack stops before the payload is even downloaded.

Start in audit mode, then switch to block

Every rule has three states: not configured, audit and block. Audit mode logs what would have been blocked without preventing anything: it is the safe way to measure the impact on your line-of-business apps before enforcing. It is a step you should never skip on rules prone to false positives.

1. 1Turn the low-false-positive rules straight to block, such as LSASS protection and blocking executable content in email.
2. 2Put the more sensitive rules in audit for one or two weeks, especially those touching Office child processes and scripts.
3. 3Review the events in Defender, identify the affected line-of-business apps and add targeted exclusions if needed.
4. 4Gradually move the audited rules to block mode, one rule at a time rather than all at once.
5. 5Finally, verify the real enforcement state in the Intune reports.

In Intune, ASR rules are deployed through an Attack Surface Reduction profile (Endpoint Security), assigned to a group of Windows devices. Each rule exposes its own state, allowing a granular rollout instead of all-or-nothing. You can therefore run several rules at different paces depending on their false-positive risk.

Common mistakes to avoid

Most ASR headaches come not from the rules themselves but from the deployment method. A few pitfalls come up again and again.

• Enabling every rule in block mode at once across the fleet with no audit phase: the surest way to break a line-of-business app on a Monday morning.
• Disabling a whole rule for everyone because of a single stubborn app, when a targeted exclusion would have been enough.
• Forgetting to enable user notifications, which turns a legitimate block into an app that "crashes" with no explanation.
• Not reading the audit logs before switching to block, and so discovering false positives in production.

Handling false positives and exclusions

Some legitimate line-of-business apps, particularly older accounting software or in-house script-based tools, can trip an ASR rule. Rather than disabling the rule for everyone, add a precise exclusion scoped to the specific file or folder. You keep protection across the whole fleet while unblocking the edge case, and you retain a record of the exceptions granted, which is useful at audit time.

It is also worth enabling end-user notifications so that, when a rule blocks an action, the user sees a clear message instead of an app silently failing. That single setting cuts down on help-desk tickets and helps you spot which rules need tuning during the audit phase. Document each exclusion with its business justification so you can reassess it later.

Why it matters for compliance

Blocking credential theft and macro execution maps directly to hardening requirements in ISO 27001 and NIS2. These rules reduce the chance that a single email turns into a full compromise, at no extra licence cost since they ship with Defender. Above all, a centralised rollout through Intune provides the evidence, at audit time, that the control is applied uniformly rather than left to each device's discretion.

How AuPoint simplifies the ASR rollout

The tricky part is the fine-tuning: which rules to enable outright, which to audit, and how to read the logs. AuPoint is a SaaS that makes Microsoft Intune security and compliance easy, with no PowerShell. The platform ships a recommended ASR rule set with the right default mode, an impact preview before deployment and one-click reversibility. You connect your Microsoft tenant, preview what will change, then apply in a few clicks.

Frequently asked questions

Do ASR rules need a special licence?

ASR rules are part of Microsoft Defender and require no third-party antivirus. Their centralised management via Intune and full reporting do, however, assume Defender is the active antivirus and that your devices are managed by Intune.

Does audit mode slow devices down?

No. Audit mode simply logs the event that would have been blocked, without preventing anything or adding any noticeable load. That is exactly why it makes a safe observation phase before real blocking.

What if a rule breaks a line-of-business app?

You add a targeted exclusion on the specific file or folder, without disabling the rule for the rest of the fleet. With AuPoint, one-click reversibility also lets you roll back to the previous state if a setting causes trouble.

Connect your Microsoft tenant to AuPoint and harden your Windows endpoints with ASR rules in minutes, with an impact preview and guaranteed rollback, without writing a single line of PowerShell. Start free at aupoint.io.