Attack Surface Reduction rules: which ones to turn on, and the one that cries wolf
ASR is the best free hardening Windows offers. Here is a sane starting set, and why one rule fires constantly on a perfectly healthy machine.
Attack Surface Reduction rules are the highest-value hardening available on a standard Windows install. They are free, they are built in, and they block techniques rather than signatures — which means they stop attacks that no one has catalogued yet.
They are also under-used, largely because the documentation is a flat list of nineteen rules with no guidance on which matter.
A sane starting set
These block real, common techniques and rarely break anything:
- Block credential stealing from LSASS — shuts down the standard credential-dumping step
- Block abuse of exploited vulnerable signed drivers — the "bring your own vulnerable driver" technique behind much modern ransomware
- Block executable content from email and webmail — the oldest delivery route there is
- Block all Office applications from creating child processes — breaks the macro-to-payload chain
- Block Office applications from creating executable content
- Block JavaScript and VBScript from launching downloaded executable content
- Block execution of potentially obfuscated scripts
- Block persistence through WMI event subscription — a favourite because it survives reboots and hides well
- Use advanced ransomware protection
Two worth enabling in audit mode first, because they generate real friction:
- Block executable files unless they meet a prevalence, age or trusted-list criterion — will block legitimate in-house and niche software
- Block process creations originating from PSExec and WMI commands — breaks many management and deployment tools
Audit mode logs what would have happened without blocking, so you can see the damage before you cause it.
The rule that cries wolf
Enable the LSASS rule and you will start seeing block events constantly — dozens a week — naming C:\Windows\System32\svchost.exe.
This is a well-known false positive. Legitimate Windows components open handles to LSASS for entirely ordinary reasons, and the rule reports them. On one machine we audited, all 57 ASR blocks in a month were this single rule firing on svchost, with nothing else in the log.
The correct response is to leave the rule enabled and understand the noise. Disabling it to quiet the log removes one of the most valuable protections in the list to fix a cosmetic problem. If you are shipping these events to a SIEM, filter that specific combination rather than the rule.
The broader lesson: a control that produces known benign noise is not a broken control. It is a control whose output needs interpreting. Tuning it away is the reflex to resist.
Check what is actually configured
$mp = Get-MpPreference
for ($i = 0; $i -lt $mp.AttackSurfaceReductionRules_Ids.Count; $i++) {
'{0} = {1}' -f $mp.AttackSurfaceReductionRules_Ids[$i], $mp.AttackSurfaceReductionRules_Actions[$i]
}
Action 1 is Block, 2 is Audit, 6 is Warn, 0 is Disabled. A rule that is not in the list at all is not configured.
Review the audit log before you switch to Block
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-Windows Defender/Operational'; Id=1122 } |
Select-Object -First 40 TimeCreated, Message
Event 1122 is an audit-mode match — what would have been blocked. Event 1121 is a real block. Spend a fortnight in audit, read the 1122s, then promote the rules that are quiet.
That sequence is the difference between hardening a machine and breaking someone's workflow on a Monday morning.