This chapter covers Microsoft Defender for Endpoint Attack Surface Reduction (ASR) rules, a critical component of the Defender XDR suite. ASR rules are a set of built-in policies that block common attack techniques such as Office apps creating child processes, script execution from email clients, and USB-based threats. For the SC-200 exam, ASR rules appear in roughly 10-15% of questions across multiple domains, making them a high-yield topic. You must understand the rule list, modes (audit, block, warn, disable), configuration methods, and how to handle false positives.
Jump to a section
Imagine a large office building with many employees and visitors. The building has a single main entrance with a security guard. The guard does not just check IDs at the door; instead, they observe every action: they ensure no one brings in weapons (block executables from email), they prevent visitors from entering restricted areas without an escort (block Office apps from creating child processes), they stop people from using suspicious tools like lockpicks (block PSExec and WMI attacks), and they prevent employees from running unauthorized scripts from USB drives (block untrusted USB scripts). The guard has a list of rules (ASR rules) that describe exactly what behavior is forbidden. When someone tries to do something forbidden, the guard stops them immediately and logs the incident. The guard can also be configured to just warn and log (audit mode) or to block entirely (block mode). The guard does not rely on signatures; instead, they look at the behavior itself. For example, if a normally quiet employee suddenly tries to copy sensitive files to a USB drive, the guard may block that action because it matches a suspicious pattern. This is exactly how ASR rules work: they monitor process creation, script execution, and other behaviors, and block or audit based on predefined rules that target common attack techniques.
What Are Attack Surface Reduction (ASR) Rules?
Attack Surface Reduction (ASR) rules are a feature of Microsoft Defender for Endpoint (MDE) that proactively reduces the attack surface of Windows devices by blocking specific behaviors commonly used by malware and exploits. Unlike traditional antivirus that relies on signatures, ASR rules are behavior-based and focus on preventing the execution of malicious code at the earliest stage. They are part of the broader Microsoft Defender XDR (formerly Microsoft 365 Defender) ecosystem.
ASR rules are designed to block actions such as:
Office applications (Word, Excel, PowerPoint) launching child processes (e.g., cmd.exe, powershell.exe) – a common technique for macro-based malware.
Scripts (JavaScript, VBScript, PowerShell) downloaded from email or web browsers from executing.
Untrusted and unsigned processes that attempt to run from USB drives.
Process injection and credential theft via LSASS.
Use of LOLBins (Living Off the Land Binaries) like PsExec and WMI for lateral movement.
ASR rules are not enabled by default; they must be configured via Group Policy, Intune, Microsoft Endpoint Configuration Manager, or Microsoft 365 Defender portal. They operate in one of four modes: - Disabled (0): Rule is off. - Block (1): Rule blocks the behavior and generates an alert. - Audit (2): Rule logs the behavior but does not block it. Useful for testing. - Warn (6): A prompt appears asking the user if they want to allow the action (available only for some rules).
How ASR Rules Work Internally
ASR rules are implemented as Windows Defender Advanced Threat Protection (WDATP) sensor extensions that hook into kernel-level process creation and script execution events. When a process attempts to create a child process, execute a script, or perform other monitored actions, the WDATP filter driver evaluates the action against the active ASR rules. The evaluation includes: 1. Rule matching: The action is checked against the rule's criteria (e.g., parent process is an Office app, child process is cmd.exe). 2. Mode evaluation: If the rule is set to Block, the action is terminated immediately. If Audit, the action is allowed but logged. If Warn, a toast notification is shown to the user. 3. Alert generation: If the action is blocked or warned, an alert is sent to the Microsoft 365 Defender portal with details such as the process, user, and file path.
The rules are applied per device and can be targeted to specific users or device groups. The rules themselves are defined by GUIDs, each corresponding to a specific behavior. For example, the rule "Block Office applications from creating child processes" has GUID D4F940AB-401B-4EFC-AADC-AD5F3C50688A.
Key Components and Defaults
There are currently 19 ASR rules (as of Windows 10 20H2 and later). The most exam-relevant rules include: - Block Office applications from creating child processes (GUID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A) - Block Office applications from creating executable content (GUID: 3B576869-A4EC-4529-8536-B80A7769E899) - Block execution of potentially obfuscated scripts (GUID: 5BEB7EFE-FD9A-4556-801D-275E5FFC04CC) - Block JavaScript or VBScript from launching downloaded executables (GUID: D3E037E1-3EB8-44C8-A917-57927947596D) - Block credential stealing from the Windows local security authority subsystem (lsass.exe) (GUID: 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2) - Block executable files from running unless they meet a prevalence, age, or trusted list criterion (GUID: 01443614-CD74-433A-B99E-2ECDC07BFC25) - Block untrusted and unsigned processes that run from USB (GUID: B2B3F03D-6A65-492F-8B4A-BD4D1A9B1A6B) - Block Win32 API calls from Office macros (GUID: 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B) - Use advanced protection against ransomware (GUID: C1DB55AB-C21A-4637-AF3F-31B9C45B6E11) - Block persistence through WMI event subscription (GUID: E6DB77E5-3DF2-4CF1-B95A-636979351E5B)
Default mode for all rules is Disabled (0). Microsoft recommends enabling rules in Audit mode first to measure impact, then switching to Block.
Configuration and Verification
ASR rules can be configured via:
- Microsoft Intune: Device configuration > Endpoint protection > Attack Surface Reduction.
- Group Policy: Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction.
- Microsoft 365 Defender portal: Endpoints > Configuration management > Endpoint security policies > Attack surface reduction.
- PowerShell: Using Set-MpPreference -AttackSurfaceReductionRules_Ids and -AttackSurfaceReductionRules_Actions.
Example PowerShell commands to enable a rule in block mode:
Set-MpPreference -AttackSurfaceReductionRules_Ids "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" -AttackSurfaceReductionRules_Actions EnabledTo enable in audit mode:
Add-MpPreference -AttackSurfaceReductionRules_Ids "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" -AttackSurfaceReductionRules_Actions AuditModeTo verify current configuration:
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_ActionsEvent logs for ASR rules are found under: - Windows Event Log > Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational. - Event ID 1121: Blocked action. - Event ID 5007: Configuration change. - Event ID 5001: Real-time protection disabled.
Interaction with Related Technologies
ASR rules work in conjunction with other Defender for Endpoint features: - Microsoft Defender Antivirus (MDAV): ASR rules complement real-time scanning. While MDAV scans files for malware, ASR rules block behavioral patterns that may precede infection. - Exploit Guard: ASR rules are part of Exploit Guard, which also includes network protection, controlled folder access, and exploit protection. - Microsoft Defender for Office 365: ASR rules on endpoints complement email-level protections by blocking malicious payloads that bypass email filters. - Microsoft 365 Defender: Alerts from ASR rules are correlated with other signals to provide a unified incident view.
Performance Considerations
ASR rules have minimal performance impact because they operate at the kernel level and only evaluate specific events. However, enabling many rules in Audit mode can generate large volumes of logs, which may impact SIEM ingestion costs. In Block mode, false positives can disrupt legitimate workflows, so testing in Audit mode is critical.
Exam Tips
Memorize the GUIDs of the most tested rules: Office child processes, obfuscated scripts, USB untrusted processes, and credential theft from LSASS.
Know the four modes: 0=Disabled, 1=Block, 2=Audit, 6=Warn.
Understand that ASR rules are per-device policies, not per-user.
Be aware that ASR rules require Windows 10 Pro or Enterprise (version 1709 or later) and Microsoft Defender for Endpoint P1 or P2.
False positives are handled by adding file or folder exclusions via the Microsoft 365 Defender portal or Group Policy.
Identify the Attack Technique
The first step in deploying ASR rules is to identify the specific attack techniques you want to block. Common techniques include macro-based malware (Office apps launching PowerShell), script-based attacks (JavaScript from email), lateral movement (PsExec), and credential theft (LSASS dumping). Microsoft provides a list of 19 rules, each targeting a specific technique. For example, rule GUID D4F940AB-401B-4EFC-AADC-AD5F3C50688A blocks Office apps from creating child processes, which is a classic indicator of malicious macros. You should prioritize rules that address the most common threats in your environment.
Enable Rules in Audit Mode
Before enabling any ASR rule in Block mode, you must first enable it in Audit mode. This allows you to monitor the rule's impact on legitimate business applications without disrupting operations. In Audit mode, the rule logs events (Event ID 1121) but does not block the action. You should run audit mode for at least 30 days to collect sufficient data. Use PowerShell `Add-MpPreference -AttackSurfaceReductionRules_Ids <GUID> -AttackSurfaceReductionRules_Actions AuditMode` for each rule. Review logs in the Microsoft 365 Defender portal or using Microsoft Sentinel to identify false positives.
Analyze Audit Logs for False Positives
After collecting audit logs, analyze them to identify legitimate applications that would be blocked if the rule were set to Block mode. For example, the rule blocking Office child processes might block a legitimate add-in that launches a helper process. You can use the Microsoft 365 Defender portal to view ASR events under "Endpoints > Hunting > Advanced hunting" with the query `DeviceEvents | where ActionType startswith "Asr"`. For each false positive, determine whether to add an exclusion (file path, file hash, or certificate) or adjust the rule's scope. Exclusions can be configured via Group Policy or Intune. Note that exclusions for ASR rules are separate from antivirus exclusions.
Switch Rules to Block Mode
Once you are confident that the rule will not disrupt critical business processes, switch it to Block mode. Use PowerShell `Set-MpPreference -AttackSurfaceReductionRules_Ids <GUID> -AttackSurfaceReductionRules_Actions Enabled` to enable blocking. Alternatively, use Group Policy or Intune. In Block mode, the rule will prevent the action and generate an alert. The user may see a notification depending on the rule. For example, the rule blocking untrusted USB processes will show a toast notification if the action is blocked. Monitor the Microsoft 365 Defender portal for alerts and fine-tune as needed.
Monitor and Fine-Tune Continuously
ASR rules are not a set-and-forget configuration. Continuously monitor alerts and logs for new false positives or missed attacks. Use the Microsoft 365 Defender portal to review ASR events and adjust exclusions or rule modes as necessary. For example, if a new line-of-business application triggers a rule, add an exclusion. Also, stay updated on new ASR rules released by Microsoft. The SC-200 exam expects you to know that ASR rules should be tested in audit mode first and that false positives are handled via exclusions. You should also understand how to use advanced hunting to query ASR events.
Enterprise Scenario 1: Blocking Macro-Based Malware
A large financial institution with 10,000 Windows 10 devices experienced frequent malware outbreaks originating from malicious macros in Office documents received via email. The security team enabled the ASR rule "Block Office applications from creating child processes" (GUID D4F940AB-401B-4EFC-AADC-AD5F3C50688A) in Audit mode for two weeks. During that time, they identified that a legitimate internal tool used by the accounting department launched a PowerShell script from Excel. They added an exclusion for that specific tool using its file hash. After switching to Block mode, the number of malware incidents dropped by 80%. The team also enabled the rule "Block Win32 API calls from Office macros" (GUID 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B) to further harden Office apps. Performance impact was negligible; the only challenge was managing exclusions for a few legacy applications.
Enterprise Scenario 2: Preventing Lateral Movement with PsExec and WMI
A healthcare organization with a mix of on-premises and cloud workloads wanted to block lateral movement techniques used by ransomware. They enabled ASR rules "Block process creations originating from PSExec and WMI commands" (GUID d1e49aac-8f56-4280-b9ba-993a6d77406c) and "Block persistence through WMI event subscription" (GUID e6db77e5-3df2-4cf1-b95a-636979351e5b). Initially, the PsExec rule blocked legitimate IT administrative scripts that used PsExec for remote management. The team switched to Audit mode, identified the affected scripts, and added exclusions based on the source IP addresses and script paths. After fine-tuning, they enabled Block mode. The number of lateral movement alerts decreased significantly. They also used advanced hunting to monitor for WMI persistence events.
Common Pitfalls
Not testing in Audit mode: Enabling rules directly in Block mode can break critical applications. Always test first.
Overlooking exclusions: Exclusions are essential for maintaining productivity. Ensure you have a process to request and approve exclusions.
Ignoring event logs: ASR events are logged in the Windows Defender Operational log. Use SIEM integration to correlate with other security events.
Assuming all rules are equally important: Prioritize rules that address your top threat vectors. The exam often tests the most common rules like Office child processes and USB untrusted processes.
What SC-200 Tests on ASR Rules
The SC-200 exam objectives under Domain 1 (Defender XDR) include Objective 1.1: "Manage attack surface reduction rules." You will be tested on:
Identifying the correct ASR rule for a given scenario (e.g., which rule blocks Office apps from creating child processes).
Understanding the four modes: Disabled (0), Block (1), Audit (2), Warn (6).
Knowing how to deploy ASR rules via Group Policy, Intune, and PowerShell.
Handling false positives using exclusions (file path, file hash, certificate).
Interpreting ASR events in the Microsoft 365 Defender portal and Windows Event Log (Event ID 1121).
Common Wrong Answers and Why Candidates Choose Them
Choosing "Audit mode" when the question asks for the most secure configuration: Candidates often select Audit because they think it's safer, but the question explicitly asks for maximum security — that is Block mode. Audit only logs, it does not stop the attack.
Mistaking ASR rules for Microsoft Defender Antivirus exclusions: ASR exclusions are separate from antivirus exclusions. A file excluded from antivirus scanning is not automatically excluded from ASR rules. Candidates confuse the two and choose the wrong exclusion method.
Assuming ASR rules apply per user instead of per device: ASR rules are device-level policies. If a question describes a user-based scenario (e.g., "only block for users in the Finance group"), the correct answer may involve targeted deployment via Intune or Group Policy to specific device groups, not user groups.
Selecting the wrong rule GUID for a given attack: For example, choosing the rule that blocks JavaScript from launching executables when the scenario involves Office macros. Memorize the mapping of techniques to GUIDs.
Specific Numbers and Terms That Appear Verbatim
Event ID 1121 for blocked actions, Event ID 5007 for configuration changes.
GUIDs: D4F940AB-401B-4EFC-AADC-AD5F3C50688A (Office child processes), 5BEB7EFE-FD9A-4556-801D-275E5FFC04CC (obfuscated scripts), B2B3F03D-6A65-492F-8B4A-BD4D1A9B1A6B (USB untrusted), 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 (LSASS credential theft).
Modes: 0=Disabled, 1=Block, 2=Audit, 6=Warn.
ASR rules require Windows 10 version 1709 or later and Microsoft Defender for Endpoint P1 or P2.
Edge Cases and Exceptions
Warn mode (6): Available only for some rules. If a rule does not support Warn, the option is ignored.
Exclusions: Can be based on file path, file hash, or certificate. They are configured per rule, not globally.
Multiple rules: If multiple rules apply to the same action, the most restrictive mode takes effect (Block overrides Audit).
PowerShell execution policy: ASR rules that block scripts (e.g., obfuscated scripts) work regardless of the PowerShell execution policy.
How to Eliminate Wrong Answers
If the question asks for "maximum protection," select Block mode (1).
If the question mentions "testing without disruption," select Audit mode (2).
If the question describes a false positive, look for an answer that involves adding an exclusion.
If the question lists multiple rules, match the technique to the correct GUID.
ASR rules are behavior-based and block specific attack techniques, not signatures.
There are 19 built-in ASR rules, each identified by a unique GUID.
Four modes: Disabled (0), Block (1), Audit (2), Warn (6).
Always test rules in Audit mode before enabling Block mode to identify false positives.
False positives are handled by adding exclusions (file path, hash, certificate) per rule.
ASR rules are device-level policies, not user-level.
Event ID 1121 indicates a blocked action; Event ID 5007 indicates a configuration change.
ASR rules require Windows 10 version 1709+ and Microsoft Defender for Endpoint P1 or P2.
Memorize key GUIDs: Office child processes (D4F940AB...), obfuscated scripts (5BEB7EFE...), USB untrusted (B2B3F03D...), LSASS (9E6C4E1F...).
ASR rules are part of Exploit Guard, which also includes network protection, controlled folder access, and exploit protection.
These come up on the exam all the time. Here's how to tell them apart.
ASR Rules
Behavior-based: blocks actions like process creation, script execution.
No signature updates required; rules are built into the OS.
Modes: Disabled, Block, Audit, Warn.
Targets specific attack techniques (e.g., Office child processes).
Exclusions are per-rule and separate from MDAV exclusions.
Microsoft Defender Antivirus (MDAV)
Signature-based and heuristic: scans files for known malware patterns.
Requires regular signature updates (cloud-delivered or manual).
Modes: Real-time protection on/off, passive mode.
Targets any file that matches malware definitions.
Exclusions are global for all scans (real-time, scheduled, etc.).
Mistake
ASR rules are enabled by default in Windows 10.
Correct
ASR rules are disabled by default. They must be explicitly configured via Group Policy, Intune, or PowerShell. Only Microsoft's recommended baseline configurations may enable some rules in audit mode.
Mistake
ASR rules work like antivirus signatures and block known malware.
Correct
ASR rules are behavior-based, not signature-based. They block specific actions (e.g., Office apps launching cmd.exe) regardless of whether the file is known malware. This allows them to stop zero-day exploits.
Mistake
Adding a file exclusion in Windows Defender Antivirus also excludes it from ASR rules.
Correct
ASR exclusions are separate from antivirus exclusions. You must configure ASR exclusions explicitly via the same policies that manage ASR rules. Antivirus exclusions do not affect ASR.
Mistake
ASR rules can be applied to individual users.
Correct
ASR rules are device-level policies. They apply to all users on a device. To target specific users, you must deploy the policy to device groups that those users use, but the rule itself is per-device.
Mistake
Warn mode is available for all ASR rules.
Correct
Warn mode (6) is only supported for a subset of ASR rules. For unsupported rules, setting Warn mode defaults to Disabled. Always check the documentation for each rule's supported modes.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
ASR rules block specific behaviors like Office apps creating child processes or scripts executing from email. Controlled folder access (CFA) protects files in specific folders from unauthorized changes by untrusted applications. CFA is part of Exploit Guard but is a separate feature. ASR rules focus on process execution and script actions, while CFA focuses on file integrity. Both can be configured via the same policies but have different purposes.
Exclusions for ASR rules are added per rule using Group Policy (Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction > Exclude files and paths from Attack Surface Reduction Rules) or via Intune (Endpoint security > Attack surface reduction > ASR rules > Exclusions). You can exclude by file path, file hash, or certificate. Exclusions apply only to the specific rule they are configured for.
Yes, ASR rules are supported on Windows Server 2016, 2019, and 2022 with Microsoft Defender for Endpoint installed. However, some rules may not be applicable or may behave differently. Always check the documentation for server-specific considerations. The SC-200 exam focuses on Windows 10/11 but may include server scenarios.
If multiple rules apply, the most restrictive mode takes precedence. For example, if one rule is set to Audit and another to Block, the action is blocked. If both are Audit, the action is allowed and logged. If one is Disabled, the other rule's mode applies. This is important for troubleshooting unexpected blocks.
You can view ASR events by going to the Microsoft 365 Defender portal (security.microsoft.com) > Endpoints > Hunting > Advanced hunting. Use a query like: `DeviceEvents | where ActionType startswith "Asr" | project Timestamp, DeviceName, ActionType, FileName, FolderPath, ProcessCommandLine`. You can also filter by event ID 1121 in the Windows Event Log on the device.
Microsoft recommends the following order: 1) Enable rules in Audit mode, 2) Monitor for false positives for at least 30 days, 3) Add exclusions for legitimate applications, 4) Switch rules to Block mode, 5) Continuously monitor and adjust. This minimizes disruption while maximizing security.
No, ASR rules require Windows 10 Pro, Enterprise, or Education editions. Windows 10 Home does not support ASR rules. This is a common exam trap: a question may assume a Home edition device, and the correct answer is that ASR rules cannot be applied.
You've just covered Defender for Endpoint ASR Rules — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?