Windows Defender Attack Surface Reduction (ASR) rules are a critical component of the Microsoft Defender for Endpoint security stack. ASR rules operate at the kernel level to block malicious behaviours commonly employed by malware and ransomware, such as office macros launching child processes, USB drives executing unsigned payloads, or credentials being dumped from the LSASS process.
While ASR rules are typically deployed via Microsoft Intune or Group Policy (GPO), administrators managing standalone servers, hyper-v hosts, or automated infrastructure often need to enforce these rules programmatically. This tutorial explains how to manage, deploy, and audit ASR rules directly using PowerShell.
Understanding ASR Rule GUIDs
ASR rules are not enabled by name; they are enabled using specific Globally Unique Identifiers (GUIDs). Microsoft maintains a standard list of ASR GUIDs. For example:
- Block credential stealing from the Windows local security authority subsystem (lsass.exe):
9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 - Block executable files from running unless they meet a prevalence, age, or trusted list criterion:
01443614-cd74-433a-b99e-2ecdc07bfc25 - Block Office applications from creating child processes:
d4f040a8-d4a0-4cb6-af86-81525a74e1d5 - Block process creations originating from PSExec and WMI commands:
d1e49aac-8f56-4280-b9ba-993a6d77406c
Each rule can be set to one of four states:
- 0 = Disabled (Off)
- 1 = Block (Enabled and actively blocking)
- 2 = Audit Mode (Logs the event but allows the action)
- 6 = Warn (Prompts the user but allows them to bypass)
Step 1: Querying the Current ASR Configuration
Before applying new rules, you should audit the current configuration of the machine. Launch an elevated PowerShell session (Run as Administrator) and execute the Get-MpPreference cmdlet.
Get-MpPreference | Select-Object -Property AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
If the output is blank or null, no ASR rules are currently configured on the system. If rules are active, you will see two corresponding arrays: one containing the GUIDs and another containing the numerical action states (0, 1, 2, or 6).
Step 2: Enabling ASR Rules in Audit Mode
It is a critical best practice to deploy ASR rules in Audit Mode (2) before enforcing them in Block Mode. Audit mode allows you to monitor event logs to ensure the rule will not break legitimate business applications.
To enable the “Block credential stealing from lsass.exe” rule in Audit Mode, use the Add-MpPreference cmdlet:
Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions 2
You can deploy multiple rules simultaneously by passing an array of GUIDs and a corresponding array of actions:
$ASR_Guids = @(
"9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2", # Block LSASS credential stealing
"d4f040a8-d4a0-4cb6-af86-81525a74e1d5" # Block Office child processes
)
$ASR_Actions = @(2, 2) # Both in Audit Mode
Add-MpPreference -AttackSurfaceReductionRules_Ids $ASR_Guids -AttackSurfaceReductionRules_Actions $ASR_Actions
Step 3: Reviewing ASR Audit Logs
Once the rules have been in Audit Mode for several days, you must review the Windows Event Logs to identify what actions would have been blocked. ASR events are logged in the Windows Defender Operational log.
You can query these logs using PowerShell. Event ID 1122 indicates an Audit mode event (an action that would have been blocked), while Event ID 1121 indicates an actual Block event.
Get-WinEvent -ProviderName "Microsoft-Windows-Windows Defender" | Where-Object { $_.Id -eq 1122 } | Format-List TimeCreated, Message
Carefully analyze the processes generating these events. If a legitimate line-of-business application is triggering an ASR rule, you must create an exclusion before moving to Block Mode.
Step 4: Configuring ASR Exclusions
If you identify a false positive, you can exclude a specific file or folder path from ASR enforcement. ASR exclusions apply globally to all ASR rules on the machine; you cannot exclude a file from just one specific ASR rule.
To exclude a specific directory (e.g., a custom internal application folder):
Add-MpPreference -AttackSurfaceReductionOnlyExclusions "C:\Program Files\InternalCorpApp\"
Step 5: Enforcing Block Mode
Once you are confident that no legitimate applications will be disrupted, you can convert the rules from Audit Mode (2) to Block Mode (1).
To overwrite the existing configuration, use Set-MpPreference (which replaces the array) rather than Add-MpPreference (which appends to it).
$ASR_Guids = @(
"9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2",
"d4f040a8-d4a0-4cb6-af86-81525a74e1d5"
)
$ASR_Actions = @(1, 1) # Set to Block Mode
Set-MpPreference -AttackSurfaceReductionRules_Ids $ASR_Guids -AttackSurfaceReductionRules_Actions $ASR_Actions
Any malicious or non-compliant actions will now be hard-blocked by the Windows kernel, providing a robust, automated defense layer against modern cyber threats.