Why an ASR Rule Blocking Win32 API Calls From Office Macros Breaks Add-Ins

When you enable the ASR rule “Block Win32 API calls from Office macros” in Microsoft Defender for Endpoint, you may find that legitimate Office add-ins stop working or fail to load. This happens because many add-ins rely on Win32 API calls through macros to perform routine tasks such as accessing files, interacting with the operating system, or integrating with other applications. This article explains why the rule causes add-in failures, describes the technical mechanism behind the block, and provides steps to identify and allow legitimate add-ins without disabling the entire security rule.

How the ASR Rule Blocks Win32 API Calls From Office Macros

The Attack Surface Reduction rule “Block Win32 API calls from Office macros” is designed to prevent malicious macros from using Windows API functions to execute code, download payloads, or modify system settings. When enabled, the rule intercepts any attempt by a VBA macro to call a Win32 API function, such as CreateProcess, WriteFile, or RegSetValue. The rule then terminates the macro execution and logs the event in Microsoft 365 Defender.

This rule uses a GUID identifier: 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B. It applies to all Office applications that support VBA macros, including Excel, Word, PowerPoint, and Outlook. The rule does not differentiate between a malicious macro and a legitimate macro embedded in a signed add-in. It blocks the API call regardless of the macro’s origin or digital signature.

Why Legitimate Add-Ins Depend on Win32 API Calls

Many third-party Office add-ins, including those from reputable vendors, use VBA macros to call Win32 API functions for core functionality. For example, an add-in that integrates with a CRM system might call InternetOpenUrl to fetch data. A document management add-in might use CreateFile to save files to a network share. A compliance add-in could call RegQueryValueEx to read configuration settings from the registry. When the ASR rule blocks these calls, the add-in cannot complete its operation and may display an error, crash, or fail to load entirely.

Steps to Identify Which Add-Ins Are Affected by the ASR Rule

Before making changes to the ASR rule configuration, you need to determine which add-ins are being blocked. Use the following steps to collect this information.

1. Enable audit mode for the rule
   In the Microsoft 365 Defender portal, go to Endpoints > Attack surface reduction rules. Locate the rule “Block Win32 API calls from Office macros” and set it to Audit mode. This logs blocked calls without actually preventing them, allowing add-ins to function normally while you collect data.
2. Review the audit logs
   After 24–48 hours of normal business use, go to Microsoft 365 Defender > Hunting > Advanced hunting. Run the following KQL query:
   DeviceEvents | where ActionType == "AsrWin32ApiCallsFromOfficeMacroAudited" | project Timestamp, DeviceName, FileName, ProcessName, RemoteUrl, InitiatingProcessFileName
   This query returns all events where the rule would have blocked a call.
3. Identify the add-in or macro source
   In the query results, examine the ProcessName and FileName columns. The ProcessName shows the Office application (e.g., EXCEL.EXE). The FileName shows the macro file or add-in DLL that attempted the API call. Cross-reference this with your list of installed add-ins.
4. Test each add-in individually
   For each identified add-in, disable all other add-ins and test the affected functionality. If the add-in works correctly in audit mode but fails when the rule is set to Block, you have confirmed the cause.

How to Allow Legitimate Add-Ins Without Disabling the Rule

Once you have identified which add-ins are blocked, you have two options: create an exclusion for the specific add-in file or use a custom indicator to allow the add-in’s publisher.

Option 1: Add a File Exclusion for the Add-In

1. Obtain the exact file path
   From the audit log, note the full path of the add-in file, such as C:\Program Files\Vendor\Addin.dll or %AppData%\Microsoft\AddIns\Addin.xlam.
2. Create an exclusion in the ASR rule
   In the Microsoft 365 Defender portal, go to Endpoints > Attack surface reduction rules. Edit the rule “Block Win32 API calls from Office macros”. Under Exclusions, add the file path. You can use environment variables and wildcards, for example: C:\Program Files\Vendor\.
3. Apply the change and test
   Set the rule back to Block mode. Test the add-in to confirm it now functions correctly. Check the audit logs again to ensure no new blocks appear for that file path.

Option 2: Use a Custom Indicator for the Publisher

1. Get the certificate details
   Right-click the add-in DLL or macro file, select Properties > Digital Signatures, and note the publisher name and certificate thumbprint.
2. Create an allow indicator
   In the Microsoft 365 Defender portal, go to Settings > Endpoints > Indicators. Add a new indicator of type Certificate. Paste the thumbprint and set the action to Allow.
3. Verify the indicator is applied
   Test the add-in. The ASR rule will skip the block for any macro signed by that certificate. This method is safer than excluding a folder path because it relies on the publisher’s identity.

If Add-Ins Still Fail After Configuring Exclusions

Add-In Fails to Load Even After Adding a File Exclusion

The exclusion may not cover all API calls if the add-in uses multiple macro files or dynamically loads code from a different location. Check the audit logs again for new events where the FileName differs from the excluded path. Add additional exclusions for those files. Also verify that the exclusion path uses the correct syntax. For example, use %ProgramFiles%\Vendor\ instead of a hardcoded drive letter if the add-in is installed on multiple machines.

ASR Rule Still Blocks Macros in Signed Add-Ins

The certificate indicator may not work if the add-in is signed with a timestamp that has expired or if the certificate chain cannot be verified. Ensure that the root certificate is trusted on the device. If the add-in is self-signed or uses an internal CA, you may need to deploy the root certificate via Group Policy or Intune. As a workaround, you can add a file exclusion for the specific add-in file instead of relying on the certificate indicator.

Multiple Add-Ins From Different Vendors Are Blocked

If many add-ins are affected, consider using a group policy or Microsoft Intune to deploy the ASR rule in audit mode to a test group first. Evaluate each add-in and create exclusions as needed. After testing, switch the rule to Block mode for the production group. This phased approach prevents widespread disruption while maintaining security.

Item	File Exclusion	Certificate Indicator
Scope	Allows a specific file or folder path	Allows all files signed by a specific publisher
Setup complexity	Low — requires only the file path	Medium — requires certificate thumbprint and trust chain
Security risk	Higher — any file in the excluded folder bypasses the rule	Lower — only files signed by the trusted publisher are allowed
Maintenance	Update path if add-in is moved or updated	Update indicator if publisher renews certificate
Best for	Single add-in from an internal or untrusted source	Multiple add-ins from a well-known vendor

The ASR rule “Block Win32 API calls from Office macros” is a powerful security feature that prevents macro-based malware from executing system-level commands. However, it can break legitimate add-ins that rely on Win32 API calls for routine operations. By using audit mode to identify the blocked add-ins and then creating targeted exclusions or certificate allow indicators, you can restore add-in functionality without weakening your overall security posture. For ongoing management, periodically review the audit logs to catch any new add-ins that may be affected after updates or new installations.