Attack Surface Reduction: How to Stop Common Attack Techniques with Intune

Most people who've heard of Attack Surface Reduction know it as "a list of toggles under Endpoint Security." What actually makes it powerful is that it isn't looking for known-bad files the way an antivirus signature does. It's looking for behaviour, specific technique patterns that legitimate software almost never needs and that a huge share of real-world attacks depend on completely. The Windows hardening baseline post covers ASR as one of nine controls. This one goes deep on ASR specifically, plus the three capabilities Intune groups alongside it: application control, device control, and exploit protection.

Office
  ↓
Script / Macro
  ↓
Malicious Behaviour
  ↓
ASR Rule
  ↓
BLOCK

That's the pattern behind an enormous share of real attacks: a Word or Excel document arrives by email, a macro inside it runs, and that macro tries to do something no ordinary spreadsheet formula would ever need to do, launch a script, spawn a shell, reach out to the internet for a second payload. ASR rules exist specifically to break that chain at the "malicious behaviour" step, regardless of whether the specific file has ever been seen before.

The Four Capabilities, Not Just ASR Rules

Microsoft groups four distinct hardening capabilities under Intune's Endpoint Security → Attack surface reduction area, and it's worth understanding all four as one toolkit rather than treating "ASR" as a single feature:

ASR Rules, Explained Individually

Each rule targets one specific technique. Understanding the technique is what makes the rule make sense, rather than it just being a name on a checklist.

Block all Office applications from creating child processes

The technique: A macro inside Word, Excel, or PowerPoint calls out to cmd.exe, powershell.exe, or another executable as a child process of the Office app itself. This is one of the single most common malware delivery patterns because it needs nothing exotic, just a user opening a document and enabling macros.

How the rule stops it: Office applications are allowed to do everything a document legitimately needs, calculations, formatting, embedded objects, but they're blocked at the OS level from spawning any child process at all. A macro can still run its own logic; it just can't hand off to a shell to do the actual damage.

Block Office applications from creating executable content

The technique: Instead of launching a process directly, a malicious macro writes a new .exe or .dll file to disk, intending to execute it in a second stage, or have another mechanism launch it later.

How the rule stops it: Office is blocked from writing files with executable extensions to disk in the first place, closing off the "drop now, run later" variant of the same underlying attack.

Block Office applications from injecting code into other processes

The technique: Rather than spawning a new visible process (which might draw attention), a macro injects malicious code directly into the memory space of an already-running, trusted process, letting the malicious code execute under that trusted process's identity.

How the rule stops it: Blocks the specific process-injection APIs Office applications have no legitimate reason to call, cutting off a technique specifically chosen by attackers to blend in.

Block Office communication applications from creating child processes

The technique: The same child-process spawning pattern as the first rule, but targeting Outlook specifically, since a malicious email attachment or an embedded object opened directly from the mail client is a common entry point that doesn't always go through a "download and open" step a user might pause on.

Block Win32 API calls from Office macros

The technique: VBA macros can call the Win32 API directly, low-level Windows functions that go far beyond anything a spreadsheet or document should need, including functions used for process manipulation and memory allocation, the building blocks of more sophisticated malware.

How the rule stops it: Blocks macros from reaching the Win32 API at all, restricting them to the much narrower set of operations Office's own object model exposes.

Block execution of potentially obfuscated scripts

The technique: Attackers heavily obfuscate PowerShell and JScript, random variable names, string concatenation tricks, base64-encoded payloads, specifically to evade both human review and simple pattern-matching detection.

How the rule stops it: Uses heuristics to recognise the structure of obfuscation itself, not a specific known-bad script, catching a huge range of otherwise-unseen malicious scripts because heavy obfuscation is itself a strong signal, legitimate scripts are rarely written this way.

Block JavaScript or VBScript from launching downloaded executable content

The technique: A script running in the context of a downloaded file (from an email attachment or a browser download) tries to launch another executable it just fetched, chaining a script-based first stage into a binary second stage.

How the rule stops it: Specifically blocks scripts marked as coming from an untrusted, downloaded source from being able to launch executable content, breaking the handoff between stages.

Block credential stealing from the Windows local security authority subsystem (lsass.exe)

The technique: Tools like Mimikatz read the memory of lsass.exe, the process that holds authentication secrets, cached password hashes and Kerberos tickets, to extract credentials for reuse elsewhere on the network. This is the same underlying risk Credential Guard defends against through hardware isolation; this ASR rule defends against it by directly blocking the memory-read attempt itself.

How the rule stops it: Blocks non-authorised processes from opening a handle to lsass.exe with the specific access rights needed to dump its memory, regardless of what tool is attempting it.

Block process creations originating from PSExec and WMI commands

The technique: Once attackers have a foothold on one machine, PsExec and WMI are two of the most common built-in tools used for lateral movement, remotely executing commands on other machines using already-compromised credentials, all using legitimate, signed Windows components that a signature-based AV has no reason to flag.

How the rule stops it: Blocks the specific process-creation pattern these tools produce when used for remote execution, without blocking their legitimate administrative uses entirely.

Use advanced protection against ransomware

The technique: Ransomware's defining behaviour, rapidly reading, encrypting, and rewriting large numbers of files in a short window, is distinct enough from normal application behaviour to detect directly, independent of whether the specific ransomware family has ever been seen before.

How the rule stops it: Uses cloud-based machine learning models specifically trained on this behavioural pattern, giving it a real chance at catching a brand-new ransomware variant on day zero, when signature-based detection has nothing to match against yet.

Rolling Out ASR Rules Without Breaking Line-of-Business Tools

DeviceEvents
| where ActionType startswith "Asr"
| summarize Hits = count() by ActionType, InitiatingProcessFileName, DeviceName
| order by Hits desc

Application Control: Deciding What's Allowed to Run, in Advance

ASR rules block specific bad behaviours from applications that are otherwise allowed to run. Application control, built on Windows Defender Application Control (WDAC), works the opposite way: nothing runs unless it's explicitly on the allowed list, based on publisher certificate, file hash, or trusted path.

Deploy WDAC policies through Intune in Audit mode first, exactly the same discipline as ASR rules, review what would have been blocked, then move to Enforce once the allowed-application list genuinely reflects what the fleet needs.

Device Control: What's Allowed to Physically Connect

Device control governs removable storage and peripherals, USB drives, external hard disks, sometimes Bluetooth and other removable media classes, and it exists because a fully hardened software stack doesn't help if anyone can plug in a USB drive and copy every file off the device, or plug in a compromised USB device designed to impersonate a keyboard and inject commands (a "BadUSB" style attack).

Configure this under Endpoint Security → Attack surface reduction → Device control, and consider it alongside the local admin controls covered in the hardening baseline, both are about limiting what a device, or the person holding it, can do once they already have physical access.

Exploit Protection: Mitigating Vulnerabilities You Haven't Patched Yet

Exploit protection, the direct successor to the older standalone EMET toolkit, applies memory-safety mitigations at the process level, independent of whether the specific vulnerability being exploited has been patched yet.

Configure per-application exceptions under Endpoint Security → Attack surface reduction → Exploit protection, since some older or specialised software genuinely breaks under specific mitigations and needs a scoped exception rather than disabling protection system-wide.

Summary

Four different capabilities, four different threat models, and the same underlying discipline running through all of them: know what "normal" looks like in your specific environment before you start blocking what looks abnormal, because the rule that stops a real attacker and the rule that breaks your finance team's macro-driven spreadsheet are sometimes closer together than they look.

Which ASR rule has caused you the most false positives in a real environment? The Office child-process rules and the obfuscated-script rule are the two I hear about most, usually from exactly the kind of legacy macro tooling this whole toolkit exists to eventually replace. Drop a comment with what you've hit.