Eighteen behavioral controls that shut down the techniques intrusions actually depend on, three of which are safe to switch on this week.
These rules stop Word spawning a command prompt, scripts running whatever they just downloaded, and code reading credentials straight out of memory. Three of the eighteen are grouped as standard protection and can go on quickly. The remaining fifteen need an audit program behind them first, because in any real estate at least one of them will block something the business depends on.
- 18 rulesThree standard protection, fifteen others
- Audit firstThen warn, then block
- Any Windows editionThe rules are a Defender Antivirus feature
- Central reportingComes from Defender for Endpoint
Eight things worth understanding before you enable anything.
Three standard protection rules, and fifteen others
The published set divides into standard protection rules and everything else. Three sit in the first group: blocking abuse of vulnerable signed drivers, blocking credential theft from the local security authority subsystem, and blocking persistence established through WMI event subscription. That division is genuinely the most useful thing in the documentation, because it hands you a starting point without requiring a discovery exercise to find one.
The Office rules are the ones that bite
Five rules cover Office alone: no child processes from any Office application, no executable content created, no code injected into other processes, no child processes from the communication applications, and no Win32 API calls out of macros. The documentation is candid that legitimate business software does spawn child processes for perfectly benign reasons, opening a command prompt or calling PowerShell to set a registry value. Anyone running an older ERP front end will recognize that description immediately.
Whether you ever hear about a block is decided by a setting most teams never look at
Three rules behave differently from the rest on reporting, covering Adobe Reader child processes, executable content arriving by email or webmail, and scripts launching downloaded executables. Detection alerts from those three only appear when the cloud protection level is set to High plus or Zero tolerance, and the pop-up a user sees only appears at High or above. Run them at a lower level and they block exactly as intended while producing none of the reporting you were counting on.
The LSASS rule may not apply to you at all
Where Local Security Authority protection is already enabled, which is recommended anyway alongside Credential Guard, this rule becomes unnecessary. It adds nothing, because the two mechanisms work in much the same way, and it is reported as not applicable in the Defender portal for exactly that reason. We have watched organizations spend weeks chasing a rule that had already been superseded on their own machines before the project started.
Several rules do nothing without cloud-delivered protection
Two rules, the one blocking executables that fail a prevalence, age or trusted-list test and the advanced ransomware protection, both carry the same precondition: cloud-delivered protection has to be on. The obfuscated-script rule additionally depends on the antimalware scan interface. Switch any of them on while the prerequisite is missing and you get the worst possible outcome, a configuration that reports as enabled in every console while protecting nothing at all.
Two rules have no warn mode
Four states exist for most rules: not configured, audit, block, and warn, where warn stops the action but lets the person override it. Two rules break that pattern, namely the credential-theft rule and the one preventing Office injecting code elsewhere. Both go straight from audit to block with no warn state in between, so there is no gentle middle phase where users can let themselves through while you watch what happens.
Not every rule reaches every device the same way
There is a published matrix showing which rules are deployable through Intune, Configuration Manager, the MDM configuration service provider and centralized Group Policy, and a number of rules simply cannot be delivered through Configuration Manager at all. Worth knowing alongside that: the Defender portal uses the same endpoint security policies as Intune, so whatever the Intune column shows applies there too. Anywhere two management planes coexist, this catches people repeatedly.
Servers are a separate conversation
Reaching Windows Server 2016 and 2012 R2 requires onboarding through the modern unified solution, and even then four rules are documented as unsupported when pushed to those two operating systems that way. Separately, the webshell rule applies to Exchange servers and nowhere else. The mistake we see most often is assuming server coverage mirrors workstation coverage, which produces a gap nobody notices because the console shows the policy assigned.
The configuration says protected. The alert queue stays empty for twelve months and nobody asks why.
Three rules out of the eighteen carry a documented dependency on the cloud protection level setting, and the value most tenants ship with falls below what those three require.
- Microsoft documents the threshold plainly. Three rules, the one covering Adobe Reader child processes, the one covering executable content arriving by mail client or webmail, and the one covering downloaded executables launched by JavaScript or VBScript, raise EDR alerts on a device only where that device sits at High plus or Zero tolerance.
- The pop-up the person at the keyboard would have seen is gated the same way, appearing only from High upward, so neither your analysts nor your staff learn that anything happened.
- Protection continues working. The configuration reports as compliant. What disappears is every signal that would have told you a block occurred, so nobody ever investigates the email that arrived carrying an executable, because as far as your team knows it never arrived.
- Fixing it means treating the cloud protection level as a decision rather than a default, taken deliberately and with open eyes about the additional false positives that come with the higher settings. What you want to avoid is the current situation in most estates, where the level is whatever it happened to be and nobody chose it.
The four disciplines that keep a rules rollout alive past its first month.
We check prerequisites before we enable a single rule
We establish five things up front: whether cloud-delivered protection is on, what the cloud protection level is set to, whether LSA protection and Credential Guard are deployed, and whether the antimalware scan interface is available. Several rules do nothing without one of these, and one is classified as not applicable the moment LSA protection is enabled. Checking first prevents two failures at once, a false sense of coverage and weeks spent on a rule that was never going to apply to you.
We audit on the awkward machines, not the easy ones
Auditing a ring of standard office laptops teaches you almost nothing, because standard laptops behave in standard ways. Everything you need to learn lives on the finance workstation carrying a twenty year old Excel add-in, the engineering machine compiling unsigned binaries, and the reception kiosk running software nobody in the building can name. Audit those three and the unpleasant surprises in block mode largely stop happening.
We treat exclusions as debt, with an owner and a date
Understand what an exclusion actually is: a hole in a control, hopefully documented. Since several rules have limited exclusion support in any case, the honest answer is frequently to fix or replace the offending application rather than carve out an exception for it. Where one is genuinely warranted it carries a reason, a named owner and a review date, which is the only thing preventing the list growing quietly until the rules protect nothing at all.
We make sure the blocks are actually visible
Blocking silently means nobody in your organization ever learns anything from the block. Two things change that: setting the cloud protection level high enough that the three dependent rules actually generate alerts, and ensuring those alerts land in a queue a human being works through. Do both and this stops being a compliance checkbox and becomes a genuine source of detection.
A four phase route, because switching eighteen rules to block on day one is how these programs die.
- 01Week 1
Prerequisites and the three standard rules
Four things get established before anything is enabled. Cloud-delivered protection has to be confirmed on, since several rules are inert without it. The cloud protection level gets chosen deliberately, because three rules only produce alerts at High plus or Zero tolerance. We check whether LSA protection and Credential Guard are already deployed, which would make the credential rule redundant. Then the three standard rules go on, and the credential rule can skip audit entirely on a small device group as the documentation permits.
- Cloud-delivered protection verified on every in-scope device
- Cloud protection level chosen, not inherited
- LSA protection and Credential Guard status established
- Standard protection rules rolled to a pilot ring
- 02Weeks 2 to 4
Everything else in audit mode
The other fifteen go into audit across a genuinely representative sample, and representative has to include the awkward machines rather than a tidy pilot group. The finance workstation running an add-in older than the person using it. The engineering laptop compiling unsigned binaries. The reception kiosk running software nobody can identify. Audit records what would have been blocked without blocking anything, and it is the only honest way to discover what your Office estate is really doing.
- Representative rings rather than a convenient sample
- The Office rules get the closest attention, since they surface more findings than the rest combined
- Where Configuration Manager is in play, the two WMI rules are handled with extra caution
- We use advanced hunting to tie each event back to a named application rather than tallying totals
- 03Weeks 5 to 6
Exclusions, and only where they are justified
Every finding from that audit gets one of three decisions: block anyway because the behavior was never necessary, exclude it with a written reason and an owner, or fix the application properly. Note that several rules have limited exclusion support, so the exclusion route is sometimes simply unavailable and fixing becomes the only path. This is the phase where the program either stays honest or quietly degrades into a list of holes.
- No exclusion goes in without a named owner, a written justification and a date it gets revisited
- Limited-exclusion rules identified before promises are made
- Where the real fix sits inside another vendor product, we bring that owner into the conversation
- Anything with no owner defaults to block, not to exclude
- 04Weeks 7 onward
Promote to block, then keep the discipline
Rules graduate from audit into block ring by ring, using warn as a halfway house wherever the rule supports one. The two that have no warn state make the jump directly. Once that is done it settles into a rhythm: new software gets tested against the rule set before it is deployed, exclusions are reviewed on a schedule instead of accumulating quietly, and rule state is reported alongside everything else in your endpoint posture rather than being forgotten.
- Ring-based promotion with a defined rollback
- Warn mode where supported, direct block where not
- Exclusions reviewed on a schedule, not left permanently
- Rule state becomes a standing posture metric rather than a document filed at project close
Six US situations where the rules earn their place quickly.
A finance function that lives in email attachments
Invoices, statements and remittance advice landing all day from senders who are genuinely external and cannot simply be blocked. Two rules earn their place here: stopping executable content arriving through the mail client or webmail, which covers the executables, scripts and archives named in the documentation, and stopping the communication applications spawning child processes, which closes the Outlook route specifically. Both matter most in businesses that genuinely cannot stop opening attachments.
A company with an inherited line of business application
If anything is going to break, it will be the Office child process rules, and any estate running an older front end that shells out to a command prompt discovers this within minutes. That is precisely what audit mode is for. Learning which of your applications behaves this way before you reach block mode is the entire difference between a planned fix and an emergency rollback on a Monday morning.
An operation where USB is still part of daily work
The rule blocking untrusted and unsigned processes from USB is the relevant one, and the documentation is careful about its scope. Copying a file off the drive onto local disk is not prevented. What is prevented is that copied file then running. In plants and yards where removable media travels between machines that never touch the corporate network, that distinction shapes how you have to design the whole control.
A professional services firm worried about ransomware
This rule applies client and cloud heuristics to judge whether a file resembles ransomware, and the documentation is explicit about something people miss: it blocks files that have not yet established a positive reputation, not merely files already known to be bad. That is a deliberately cautious stance with real false-positive implications, it does nothing unless cloud-delivered protection is enabled, and it happens to be exactly the control insurance carriers now ask about by name.
A healthcare estate with clinical software nobody can change
Clinical software is routinely unsigned, installed on very few machines worldwide, and impossible for you to modify because the vendor controls it. That combination puts the prevalence and age rule directly in conflict with your estate, so it needs a longer audit period than anywhere else and an explicit permitted list agreed before anything moves into block mode.
A school or university with shared and lab devices
Shared machines attract more script activity, more removable media and more unmanaged software than any corporate fleet ever does. Three rules repay the effort quickly in that setting: blocking obfuscated scripts, blocking scripts that launch downloaded executables, and blocking copied or impersonated system tools. All three assume the antimalware scan interface and cloud protection prerequisites are genuinely in place rather than assumed.
How organizations actually run attack surface reduction.
| Feature | Managed ASR program | Enabled once, never reviewed | Antivirus only |
|---|---|---|---|
Standard protection rules in block mode | Yes | Usually | No |
Remaining rules assessed in audit first | Yes | Rarely | Not applicable |
Cloud protection level chosen deliberately | Yes | No | No |
Alert dependency understood | Yes | No | Not applicable |
Exclusions documented and reviewed | Yes | No | Not applicable |
Server rules handled separately | Yes | No | No |
Warn mode used where supported | Yes | Rarely | Not applicable |
Rule drift detected | Yes | No | Not applicable |
New applications tested against the rules | Yes | No | Not applicable |
Blocks investigated rather than ignored | Yes | Sometimes | No |
Rule by rule: the behavior it stops, and the thing in your estate it takes down if you skip the audit.
Rule
Block abuse of exploited vulnerable signed drivers
- What it blocks
- Applications saving vulnerable signed drivers to the machine
- Deployment note
- In the standard group. Drivers already resident on the machine keep loading, so treat it as protection against what arrives next
Rule
Block credential stealing from the local security authority subsystem
- What it blocks
- Access to LSASS process memory, not the processes themselves
- Deployment note
- In the standard group, though it drops to not applicable once LSA protection is running. Very noisy in audit, and warn mode is unavailable
Rule
Block persistence through WMI event subscription
- What it blocks
- Malware using WMI event subscriptions to survive reboots
- Deployment note
- In the standard group. Configuration Manager estates need a long audit here, because that client leans on WMI constantly
Rule
Block all Office applications from creating child processes
- What it blocks
- Word, Excel, PowerPoint, OneNote and Access spawning processes
- Deployment note
- Takes effect only where Office sits under Program Files. More line of business software breaks on this one than on any other
Rule
Block Office applications from creating executable content
- What it blocks
- Office writing executable components to disk for persistence
- Deployment note
- Unaffected by Office install location. Limited exclusion support
Rule
Block Office applications from injecting code into other processes
- What it blocks
- Code injection from Word, Excel, OneNote and PowerPoint
- Deployment note
- Warn mode is unavailable and Office has to restart before it applies. Microsoft lists BeyondTrust Privilege Guard and Heimdal security products as incompatible
Rule
Block Office communication application from creating child processes
- What it blocks
- Outlook spawning processes, including rules and forms exploits
- Deployment note
- Applies only where the Office install lives under Program Files, and exclusion support is limited
Rule
Block Win32 API calls from Office macros
- What it blocks
- Visual Basic for Applications calling Win32 APIs
- Deployment note
- Even estates that depend on macros rarely find they need this one. It rests on the antimalware scan interface being present
Rule
Block executable content from email client and webmail
- What it blocks
- Executables, scripts and archives propagating from mail
- Deployment note
- Covers Outlook and the mainstream webmail clients. You will only see alerts if cloud protection sits at High plus or Zero tolerance
Rule
Block JavaScript or VBScript from launching downloaded executable content
- What it blocks
- Script downloaders fetching and running further payloads
- Deployment note
- Alerting again requires High plus or Zero tolerance, and Intune cannot deliver this rule to Server 2012 R2 or Server 2016
Rule
Block execution of potentially obfuscated scripts
- What it blocks
- Scripts with suspicious obfuscation properties, PowerShell included
- Deployment note
- Needs both cloud-delivered protection and the antimalware scan interface. Ordinary commercial packers generate false findings
Rule
Stop executables running unless they clear a prevalence, age or trusted list bar
- What it blocks
- Unknown and low-prevalence executables
- Deployment note
- Cloud-delivered protection is a prerequisite. Any team compiling its own binaries will feel this one immediately
Rule
Block process creations originating from PSExec and WMI commands
- What it blocks
- Remote execution through PsExec and WMI
- Deployment note
- Microsoft is explicit that Configuration Manager estates should not turn this on through any other deployment channel
Rule
Block Adobe Reader from creating child processes
- What it blocks
- Reader spawning processes after a document exploit
- Deployment note
- High plus or Zero tolerance again for alerting, and exclusion support here is limited
Rule
Block untrusted and unsigned processes that run from USB
- What it blocks
- Unsigned executables running from removable media
- Deployment note
- Copying off the drive is allowed. Execution of what was copied is what gets stopped
Rule
Block use of copied or impersonated system tools
- What it blocks
- Duplicated or imposter copies of Windows system binaries
- Deployment note
- Rarely breaks anything, and it is one of the better catches available against living off the land tradecraft
Rule
Block rebooting machine in Safe Mode
- What it blocks
- Utilities like bcdedit and bootcfg being used to force a reboot into Safe Mode
- Deployment note
- Nobody is locked out. Safe Mode is still reachable by hand through the Windows Recovery Environment
Rule
Use advanced protection against ransomware
- What it blocks
- Files that resemble ransomware by client and cloud heuristics
- Deployment note
- Cloud-delivered protection has to be on. Files that have not yet earned a positive reputation are caught too
Five steps, and the audit period is not negotiable.
- 1
Establish the prerequisites and the current state
Seven data points: is cloud-delivered protection on, what level is it set to, is LSA protection deployed, is Credential Guard deployed, is the antimalware scan interface available, where does Office live on disk, and does Configuration Manager manage any of these machines. We also inventory rules that are already set, because nearly every estate carries a half-finished configuration from a project nobody wrote up.
- 2
Enable the three standard protection rules
Three: the vulnerable signed driver rule, the LSASS credential theft rule where it still applies to you, and the WMI event subscription persistence rule, that last one handled carefully anywhere Configuration Manager is running. That trio gives you the most protection for the least disruption.
- 3
Run the remaining fifteen in audit
On a device population chosen to include the difficult machines rather than avoid them, and running long enough to span a complete business cycle with month end inside it. We map every finding to the application that caused it, since a raw event count says nothing about whether the behavior was legitimate.
- 4
Decide each finding, then promote in rings
One of three outcomes per finding: block regardless, write an exclusion with a justification and a review date, or repair the application. Promotion then proceeds ring by ring, stopping at warn wherever the rule offers it and moving directly to block on the two that do not. The rollback path is agreed before promotion starts, never invented halfway through it.
- 5
Hand over as an operational control
Four habits: rule state shown next to the rest of your endpoint posture, block events landing in a queue a human actually works, exclusions revisited on a fixed cadence, and an ASR check built into how new software gets onboarded. Skip that fourth one and the whole configuration erodes silently inside a year and a half.
What organizations ask about attack surface reduction rules.
Fifteen checks that prevent a reverted rollout.
Prerequisites
- Is cloud-delivered protection enabled everywhere?Three rules explicitly require it.
- What is your cloud protection level?Three rules only alert at High plus or Zero tolerance.
- Is LSA protection already on?It makes the credential stealing rule not applicable.
- Is Credential Guard deployed?Microsoft recommends it alongside LSA protection.
- Is the antimalware scan interface functioning?Two script rules depend on it.
Estate reality
- Is Office installed under Program Files?Two rules are enforced only if it is.
- Do you run Configuration Manager?Its client relies heavily on WMI.
- Any BeyondTrust Privilege Guard or Heimdal?Named incompatible with the Office injection rule.
- Any Quest Dirsync Password Sync?Microsoft documents an issue with the LSASS rule.
- Are Server 2012 R2 or 2016 machines in scope?They need modern unified solution onboarding.
Operations
- Who reviews audit-mode findings weekly?Unreviewed audit data is just storage.
- How does a user report a block?Warn mode changes what they see, where supported.
- Who approves an exclusion?And who reviews it six months later.
- Are rule states reported to anyone?Otherwise drift goes unnoticed.
- What is the rollback if a ring breaks?Decided before promotion, not during an incident.
The pages around this one.
Defender for Endpoint
Where the central management, reporting and alerting for these rules actually lives.
Intune security baselines
The usual home for the rule configuration itself, and the place drift against your baseline shows up.
Defender Vulnerability Management
The weaknesses the rules make harder to reach, prioritized for remediation.
Two questions worth answering: are your rules stopping anything, and would anybody find out if they were?
Three findings turn up in most environments we examine: a half-finished configuration with no documentation behind it, one or more rules that cannot raise an alert at the cloud protection level currently set, and a list of exclusions nobody has revisited since the day they were added. None of the three takes long to confirm, and all three change what you do next.
Related Services
Explore more solutions that work great with this service
Intune Endpoint Security Antivirus Policy
Intune antivirus policy consolidation for US organizations: every
Learn moreIntune Security Baselines
Security baseline design and management for US organizations: stating
Learn moreMicrosoft Defender for Endpoint Services
EDR plan selection, onboarding and zero-gap AV migration
Learn moreMicrosoft Defender Vulnerability Management Services
Defender Vulnerability Management deployment for US organizations:
Learn moreMicrosoft Defender XDR Services
One incident queue across endpoint, email and identity
Learn moreRansomware Protection
Layered ransomware protection for US businesses covering prevention
Learn more