7.3 Attack Surface Reduction (ASR) Rules

75 minutes · Module 7

Attack Surface Reduction (ASR) Rules

By the end of this subsection, you will understand what ASR rules prevent, know which rules to enable first, operate the audit-to-block workflow, and monitor ASR events with KQL.

ASR rules are preventive controls, not detection rules. They block specific high-risk behaviors at the endpoint level before malware can execute. A blocked Office macro never generates an incident to investigate — the attack chain is broken at the first step.

ASR vs EDR — different layers, complementary

Feature	ASR rules	EDR
Function	Prevents execution (blocks the behavior)	Detects and alerts during/after execution
Timing	Before the attack chain begins	During or after the attack chain
Output	Block event (logged, optional alert)	Alert, incident, investigation timeline
Value	Reduces the volume of incidents SOC handles	Enables investigation of incidents that bypass prevention
Failure mode	False positive = legitimate software blocked	False negative = attack not detected

The 10 ASR rules ranked by impact

Priority	ASR rule	Attack technique blocked	False positive risk
Critical	Block Office apps from creating child processes	Macro malware (winword.exe → powershell.exe chain)	Medium — Office plugins
Critical	Block executable content from email/webmail	Email-delivered malware	Low
Critical	Block credential stealing from LSASS	Mimikatz, credential dumping tools	Medium — backup agents, monitoring tools
Critical	Block all Office apps from creating executable content	Office apps writing .exe/.dll to disk	Low
High	Block process creations from WMI and PSExec	Lateral movement via remote execution	Medium — admin tools
High	Block JavaScript/VBScript from launching downloads	Drive-by downloads, script-based malware	Low
High	Block Win32 API calls from Office macros	Advanced macro techniques bypassing child process rule	Low
Medium	Block untrusted/unsigned processes from USB	USB-delivered malware	Low (may affect USB tools)
Medium	Block persistence through WMI event subscription	WMI-based persistence (advanced attacker technique)	Low
Medium	Block abuse of exploited vulnerable signed drivers	BYOVD attacks	Low

Enable in audit mode first — always, no exceptions

ASR rules in block mode stop any software that triggers the rule pattern — legitimate or malicious. A third-party accounting plugin that launches PowerShell from Excel will break. An IT monitoring tool that reads LSASS for credential validation will fail. Audit mode logs what would have been blocked without disrupting users. Run audit for 2-4 weeks, analyze, create exclusions, then enforce.

The audit-to-block workflow

Week 1-2: Enable all ASR rules in audit mode. No user impact. Events flow to the DeviceEvents table.

Week 2-3: Analyze audit events with KQL. Identify legitimate software that triggers rules. Create path-based or hash-based exclusions.

Week 4: Switch to block mode for rules with zero or low audit hits. Keep rules with many legitimate triggers in audit while you refine exclusions.

Ongoing: Monitor block events weekly. New software installations may trigger rules — add exclusions as needed.

Monitoring ASR in audit mode

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
DeviceEvents
| where TimeGenerated > ago(14d)
| where ActionType startswith "Asr"
| extend RuleName = replace_string(replace_string(ActionType, "Audited", ""), "Blocked", "")
| extend Mode = iff(ActionType endswith "Blocked", "Block", "Audit")
| summarize
    AuditCount = countif(Mode == "Audit"),
    BlockCount = countif(Mode == "Block"),
    UniqueDevices = dcount(DeviceName),
    TriggeredBy = make_set(FileName, 5)
    by RuleName
| sort by AuditCount desc

Expected Output

RuleName	AuditCount	UniqueDevices	TriggeredBy
AsrOfficeChildProcess	247	45	["powershell.exe","cmd.exe"]
AsrLsassCredentialTheft	12	3	["backupagent.exe"]
AsrExecutableEmailContent	0	0	[]
AsrScriptExecutableDownload	2	1	["wscript.exe"]

What to look for: Rules with 0 audits (AsrExecutableEmailContent) are safe to switch to block — nothing would break. Rules with high audit counts (AsrOfficeChildProcess at 247) need investigation: the TriggeredBy field shows which processes triggered it. If it is all powershell.exe from Office, investigate whether those are legitimate macros. LSASS credential theft triggered by backupagent.exe is almost certainly a legitimate backup tool — create an exclusion for its path or hash.

Block-readiness decision

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
DeviceEvents
| where TimeGenerated > ago(30d)
| where ActionType startswith "Asr" and ActionType endswith "Audited"
| extend RuleName = replace_string(ActionType, "Audited", "")
| summarize
    TotalAudits = count(),
    UniqueDevices = dcount(DeviceName),
    UniqueProcesses = dcount(FileName),
    Processes = make_set(FileName, 10)
    by RuleName
| extend ReadyToBlock = iff(TotalAudits == 0 or (TotalAudits < 5 and UniqueDevices < 3), "YES", "NEEDS EXCLUSIONS")
| sort by ReadyToBlock asc, TotalAudits desc

Expected Output

RuleName	TotalAudits	UniqueDevices	Processes	ReadyToBlock
AsrOfficeChildProcess	247	45	["powershell.exe","cmd.exe"]	NEEDS EXCLUSIONS
AsrLsassCredentialTheft	12	3	["backupagent.exe"]	NEEDS EXCLUSIONS
AsrExecutableEmailContent	0	0	[]	YES
AsrScriptExecutableDownload	2	1	["wscript.exe"]	YES

What to look for: Switch "YES" rules to block immediately. For "NEEDS EXCLUSIONS" rules: create exclusions for the identified processes, wait another week, re-run the query. When audits drop to near-zero, switch to block. This systematic approach prevents business disruption while maximizing protection.

Try it yourself

"Block credential stealing from LSASS" shows 12 audits on 3 devices, all from backupagent.exe. Should you create an exclusion and switch to block? What is the security trade-off?

Yes — create the exclusion and switch to block. backupagent.exe is a known legitimate process that needs LSASS access for credential-based backup operations. Create a hash-based exclusion (more specific than path-based) for the verified backup agent binary.

Trade-off: If an attacker replaces or DLL-hijacks the backup agent, the exclusion allows credential theft via that specific binary. Mitigate with: file integrity monitoring on the backup agent, restricted permissions on the installation directory, and alert-on-change for the agent binary hash.

Risk assessment: Leaving LSASS unprotected (no block mode) exposes every device to credential dumping. The risk of a targeted backup agent compromise is far lower than the risk of unrestricted LSASS access.

Check your understanding

1. You enable "Block Office apps from creating child processes" in block mode without audit testing. What happens Monday morning?

Every Office macro and plugin that launches PowerShell, cmd.exe, or any other child process is blocked. Finance users cannot run their approved reporting macros. HR cannot run their mail merge plugin. The help desk receives dozens of tickets. Always audit first.

Only malicious macros are blocked

Nothing — block mode only logs

ASR rules are behavior-based, not intent-based. They block the pattern regardless of whether the software triggering it is legitimate or malicious. Audit mode reveals the legitimate cases so you can exclude them before enforcement.

2. AsrExecutableEmailContent shows 0 audits over 30 days. What does this mean?

No legitimate email attachments contain executables in your environment. Switching to block mode will not disrupt any user workflow — it is safe to enforce immediately. This is the ideal outcome: zero noise, maximum protection.

The rule is not working

No attacks have occurred

Zero audits means zero false positives. The rule can be enforced without risk of business disruption. This is common for email executable blocking — modern organizations rarely send .exe files via email intentionally.

← 7.2 Sensor and Client Configuration 7.4 EDR and Automated Investigation Configuration →