ASR Rule Blocking EXE Installs – How to Identify Which Rule Is Responsible

Problem

Attack Surface Reduction (ASR) rules are designed to block malicious behaviour, but in real-world Intune environments they frequently block legitimate EXE installers.

Common symptoms include:

• Win32 apps failing silently
• EXE installers never launching
• Intune reporting “Installing” indefinitely
• No visible error in Company Portal

From the Intune admin side, everything looks correct — assignments, packaging, detection rules — yet the application simply never installs.

This guide walks through how to definitively identify which ASR rule caused the block and how to fix it without weakening security.

Why ASR Blocks Legitimate Installers

ASR rules trigger on behaviour, not intent.

Legitimate installers are often blocked when they:

• Launch child processes
• Use PowerShell or command-line execution
• Drop files into protected locations
• Execute from user-writable paths
• Are unsigned or poorly signed

The core problem is visibility:
Intune does not clearly surface which ASR rule caused the block.

You must check the device directly.

Step-by-Step: Identifying the Blocking ASR Rule

Step 1: Check Defender ASR Events on the Device

On the affected endpoint:

1. Open Event Viewer
2. Navigate to:

Applications and Services Logs
→ Microsoft
→ Windows
→ Windows Defender
→ Operational

Look specifically for:

• Event ID 1121
• Event ID 1122

These indicate ASR enforcement.

Step 2: Extract the Rule ID from the Event

Open the event details and note:

• Rule ID (GUID)
• Blocked process name
• Target file path
• Action taken

Example (simplified):

RuleId: D4F940AB-401B-4EFC-AADC-AD5F3C50688A
Process: installer.exe
Action: Blocked

The Rule ID is the key — everything else is secondary.

Step 3: Map the Rule ID to the ASR Rule Name

Microsoft ASR rules are identified internally by GUIDs.

Use Microsoft’s official ASR documentation to map the GUID to the rule name.

Common offenders include:

• Block process creations originating from PSExec and WMI
• Block executable content from email and webmail clients
• Block Office applications from creating child processes
• Block credential stealing from LSASS

Once you know the exact rule, you can fix the problem surgically instead of guessing.

Optional: Confirm Using Defender Advanced Hunting

If you have Defender for Endpoint (Plan 2), Advanced Hunting provides confirmation.

Filter for:

• ActionType = ASRBlocked
• Affected device name
• Installer file name

This removes all doubt about which rule triggered.

Fixing the Issue Safely (Do NOT Disable ASR)

Disabling ASR rules globally is the wrong fix.

Instead, use a controlled approach.

Step 4: Create a Targeted ASR Exclusion

Preferred exclusion methods:

• File hash (most secure)
• Specific installer path
• Specific process

Avoid:

• Folder-wide exclusions
• Global exclusions
• Disabling the rule tenant-wide

Create the exclusion, then re-test the installation.

Step 5: Validate and Remove Temporary Exclusions

Once the install succeeds:

• Confirm the application functions correctly
• Remove temporary exclusions if possible
• Document the behaviour for future deployments

Many ASR exclusions are only needed during install.

Common ASR False Positive Scenarios

In production environments, ASR false positives most often involve:

• Scripted installers wrapped in EXEs
• Vendor installers using PowerShell internally
• Legacy applications with poor signing
• EXEs extracted to %TEMP% or user profile paths

Understanding these patterns helps you predict issues before rollout.

Preventing ASR Install Blocks in the Future

Before deploying applications:

• Test installers on ASR-enabled devices
• Prefer signed installers
• Avoid script-heavy wrappers where possible
• Document known ASR conflicts internally

This dramatically reduces firefighting later.

When ASR Is the Silent Failure

ASR blocks do not always surface in:

• Company Portal
• Intune app status
• Compliance reports

If an installer fails silently, always check ASR logs early.

Final Notes

ASR is effective, but blunt.

Once you know:

• Where to look
• Which events matter
• How to map Rule IDs

ASR troubleshooting becomes predictable instead of frustrating.

Quick Reference Checklist

If an EXE installer fails silently:

• ✔ Check Defender Event IDs 1121 / 1122
• ✔ Extract ASR Rule ID
• ✔ Map GUID to rule name
• ✔ Add targeted exclusion
• ✔ Re-test install
• ✔ Remove exclusion if possible