2.3 Attack Surface Reduction Rules

Attack Surface Reduction Rules

Introduction

Attack Surface Reduction rules are preventive controls that block specific software behaviors commonly exploited by attackers. They operate at the operating system level, intercepting process creation, script execution, and application behavior before malicious actions complete. When properly configured, ASR rules stop entire attack chains at the first step — the macro that would have launched PowerShell never executes, the credential-dumping tool that would have accessed LSASS is blocked, the ransomware that would have encrypted files is prevented from writing.

In Module 1.4, you saw the process chain winword.exe → cmd.exe → powershell.exe → mimikatz.exe and learned that this is the textbook macro malware delivery pattern. ASR rule “Block Office applications from creating child processes” prevents this chain at the first arrow — Word is blocked from spawning cmd.exe, and the entire attack chain collapses. That is the power of ASR: it eliminates categories of attack techniques, not individual malware samples.

This subsection teaches you every ASR rule category, the three-phase deployment methodology (audit → warn → block), how to configure rules via Intune and Group Policy, how to monitor ASR events using Advanced Hunting, how to manage exclusions without creating security gaps, and the critical relationship between ASR and investigation — even blocked attacks generate telemetry that you investigate.

What ASR rules protect against

ASR rules target specific software behaviors that attackers exploit. They do not replace antivirus — antivirus identifies malicious files by signature and behavior. ASR rules block categories of actions regardless of whether the specific executable is known to be malicious. A zero-day malware sample that no antivirus has ever seen is still blocked by ASR if it attempts a behavior that a rule covers — because the rule targets the behavior, not the file.

The rules fall into five categories based on what they protect:

Office application rules prevent the most common initial access technique — macro-based malware delivery. These rules block Office applications from creating child processes (the winword.exe → cmd.exe chain), from creating executable content (dropping an .exe to disk), from injecting code into other processes, and from creating Win32 API calls that enable macro-based attacks. These are the highest-priority rules for most organizations because email-delivered Office documents are the number one initial access vector for targeted attacks.

Script execution rules block obfuscated scripts, JavaScript and VBScript that download payloads, and potentially obfuscated macros. Attackers routinely obfuscate PowerShell commands (Base64 encoding, string concatenation, variable substitution) to evade string-based detection. The script obfuscation rule detects and blocks these patterns at execution time, before the deobfuscated command runs.

Credential theft rules block processes from accessing the LSASS (Local Security Authority Subsystem Service) memory, where Windows stores credential material including NTLM hashes and Kerberos tickets. Tools like Mimikatz, ProcDump, and Cobalt Strike’s credential harvesting module access LSASS to extract credentials. The “Block credential stealing from the Windows local security authority subsystem” rule prevents this access. This is one of the most impactful rules because credential theft is the pivot point between initial access and lateral movement — blocking LSASS access stops the attacker from escalating their compromise.

Email and web download rules block executable content launched from email clients and webmail, and block execution of downloaded files that meet specific risk criteria. These rules add a layer of protection beyond Defender for Office 365’s email scanning — even if a malicious attachment bypasses email filtering, the ASR rule blocks its execution on the endpoint.

Ransomware and lateral movement rules include advanced protection against ransomware encryption behaviors, WMI and PsExec abuse (common lateral movement tools), and persistence via WMI event subscriptions. The “Use advanced protection against ransomware” rule applies reputation-based blocking to executable files, checking whether files are known-good (prevalent, signed, on allowlists) before allowing execution — files that are unknown and suspicious are blocked even if no antivirus signature matches.

The three-phase deployment methodology

ASR rules affect legitimate software. An Office macro that generates reports by calling a PowerShell script is functionally identical to a malicious macro that launches PowerShell to download malware — both are Office spawning a child process. If you deploy ASR rules in block mode without testing, you will break legitimate business processes and face an immediate backlash from users and management that may result in the rules being permanently disabled.

The correct deployment approach uses three phases: audit, warn, and block.

Phase 1: Audit mode (minimum 30 days). Configure all rules in audit mode. In this mode, the rules evaluate every action against the rule criteria but do not block anything. Instead, they generate audit events that record what would have been blocked. These events appear in the Windows Event Log (Event ID 1122 for audit) and in the DeviceEvents table in Advanced Hunting.

During the audit phase, your goal is to identify false positives — legitimate business processes that trigger rules. Run a weekly report query against the audit events to identify the top triggered rules and the applications responsible.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// ASR Rule Audit Report — identify false positives before enabling block mode
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| where ActionType endswith "Audited"
| extend RuleName = tostring(AdditionalFields.RuleName)
| summarize AuditCount = count(),
    AffectedDevices = dcount(DeviceName),
    AffectedUsers = dcount(AccountName),
    TopProcesses = make_set(InitiatingProcessFileName, 5)
    by RuleName
| order by AuditCount desc

Phase 2: Warn mode (optional, 14-30 days). For rules with few false positives, you can skip directly from audit to block. For rules with moderate false positive rates, warn mode provides a middle ground: the user sees a warning that the action is blocked, with an option to click “Allow” to unblock it for 24 hours. This lets users self-service for legitimate actions while collecting data about which rules generate the most user overrides. Rules with high override rates need additional exclusions before moving to block mode.

Phase 3: Block mode (permanent). After tuning false positives in audit and warn modes, move rules to block mode. In block mode, the action is silently blocked and an event is recorded. The user sees a notification that content was blocked, but they cannot override it. Blocked events generate alerts in the Defender portal (configurable) and populate the DeviceEvents table with ActionType ending in “Blocked.”

Configuring ASR rules

Via Intune (recommended). Navigate to Endpoint security → Attack surface reduction → Create policy. Select Windows 10/11 as the platform. Each rule has three settings: Disabled, Audit, and Block (some also support Warn). Configure each rule according to your deployment phase. You can create multiple policies for different device groups — for example, a “Standard” policy for workstations and a “Server” policy with different rule settings for servers (servers often need different exclusions because they run different software).

Via Group Policy. Navigate to Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → Attack Surface Reduction. Each rule is configured using its GUID — Microsoft publishes the complete GUID list in the ASR rules reference documentation. Set each GUID to value 0 (Disabled), 1 (Block), 2 (Audit), or 6 (Warn).

Via PowerShell. Use Set-MpPreference -AttackSurfaceReductionRules_Ids <GUID> -AttackSurfaceReductionRules_Actions <Mode> where Mode is 0 (Disabled), 1 (Block), 2 (Audit), or 6 (Warn). This method is useful for quick testing in lab environments but should not be the primary management method in production.

Managing exclusions

Exclusions are necessary but dangerous. Every exclusion creates a gap in protection — if you exclude a folder or process from an ASR rule, an attacker who places malware in that folder or injects into that process bypasses the rule. The goal is minimum necessary exclusions: exclude only the specific process, path, or file that causes the false positive, not broad categories.

Per-rule exclusions apply to a specific ASR rule only. If chrome.exe triggers the LSASS credential theft rule (a known false positive), exclude chrome.exe from that specific rule only — it remains protected by all other rules. This is safer than a global exclusion.

Path exclusions should be as specific as possible. Exclude C:\Program Files\CompanyApp\reportgen.exe rather than C:\Program Files\CompanyApp\*. The wildcard exclusion would allow malware placed anywhere in that directory to bypass the rule.

Never exclude temp directories, user profile directories, or download folders. These are the primary locations where malware lands. Excluding them from ASR rules negates the most important protection the rules provide.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Monitor ASR exclusion usage — are exclusions being exploited?
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType startswith "Asr"
| where ActionType endswith "Blocked"
| extend RuleName = tostring(AdditionalFields.RuleName)
| extend WasExcluded = tostring(AdditionalFields.IsExcluded)
| where WasExcluded == "true"
| summarize ExcludedBlocks = count() by RuleName, InitiatingProcessFileName,
    FolderPath
| order by ExcludedBlocks desc

ASR and investigation: blocked attacks still generate telemetry

A critical concept for SOC analysts: ASR blocking an attack does not mean the investigation is over. The blocked event tells you that an attack was attempted. You still need to investigate: how did the malicious content reach the device (phishing email? drive-by download? USB?), are other devices affected, was any part of the attack chain successful before the ASR rule triggered, and does the attack pattern indicate a targeted campaign?

When ASR blocks a process chain, the blocked event appears in DeviceEvents with the ASR rule name, the initiating process, the blocked action, and the user account. Use this data to trace the attack backward — if Office tried to spawn PowerShell and was blocked, the Office document is malicious. Find the document: where did it come from? Was it an email attachment? If so, who else received it? Run a phishing campaign scope query (Pattern 5 from Module 6.5) to determine the blast radius.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Find the email that delivered the document that triggered ASR
let asrDevice = "DESKTOP-NGE042";
let asrTime = datetime(2026-03-18 09:14:00);
let asrUser = "j.morrison";
// Step 1: Find the ASR block event
DeviceEvents
| where Timestamp between ((asrTime - 1h) .. (asrTime + 1h))
| where DeviceName =~ asrDevice
| where ActionType startswith "Asr"
| project Timestamp, ActionType, FileName,
    InitiatingProcessFileName, FolderPath, AccountName

The ASR event tells you the file name and folder path of the blocked document. Search EmailAttachmentInfo for that file name to find the email that delivered it. Then search EmailEvents for the sender domain to scope the campaign. This investigation flow — ASR block → file identification → email trace → campaign scope — is a common operational pattern you will use in Modules 11 and 12.

The essential ASR rules for SOC operations

Not all ASR rules are equally important. The following five rules provide the highest security value for the most common attack techniques and should be your priority for block mode deployment:

Block Office applications from creating child processes. Prevents macro malware from launching command interpreters. This single rule blocks the most common initial access technique used in targeted attacks.

Block credential stealing from the Windows local security authority subsystem. Prevents LSASS credential dumping. This blocks the pivot from initial access to lateral movement — without credentials, the attacker cannot move to other systems.

Block executable content from email client and webmail. Prevents execution of attachments directly from Outlook, OWA, and other mail clients. Adds a layer beyond email filtering.

Block all Office applications from creating child processes. The broader version that covers all Office applications, not just the common ones.

Use advanced protection against ransomware. Applies reputation-based execution control that blocks unknown executables. Particularly effective against ransomware because encryption binaries are novel (not seen before) and unsigned.

Knowledge check