How to Block Office Applications from Creating Executable Content Using Intune

Start by signing into the Microsoft Intune admin center where you'll configure the ASR policy. This is your central hub for managing endpoint security policies across your organization.

Open your web browser and navigate to https://endpoint.microsoft.com. Sign in with your Global Administrator or Intune Administrator credentials.

Once logged in, navigate to Endpoint security in the left navigation pane, then select Attack surface reduction. This section contains all ASR-related policies and configurations.

Now you'll create a new ASR policy specifically designed to block Office applications from creating executable content. This policy will use the dedicated ASR rule with GUID 3B576869-A4EC-4529-8536-B80A7769E899.

Click Create policy in the Attack surface reduction section. You'll be presented with platform and profile options.

Select the following configuration:

• Platform: Windows 10, Windows 11, and Windows Server
• Profile: Attack surface reduction rules

Click Create to proceed to the policy configuration wizard.

Proper naming and documentation of your ASR policy is crucial for ongoing management and troubleshooting. Use descriptive names that clearly indicate the policy's purpose and scope.

Fill in the following fields on the Basics tab:

• Name: ASR - Block Office Executable Content Creation
• Description: Prevents Office applications (Word, Excel, PowerPoint) from creating executable content to mitigate macro-based malware attacks. Applies to Windows 10 1709+ and Windows 11 devices.

The description should be detailed enough that other administrators understand the policy's purpose without needing to examine the configuration.

Click Next to proceed to the configuration settings.

This is the core configuration step where you'll enable the specific ASR rule that prevents Office applications from creating executable files. The rule targets common attack vectors used by macro-based malware.

In the Configuration settings section, locate the rule "Block Office applications from creating executable content". This corresponds to GUID 3B576869-A4EC-4529-8536-B80A7769E899.

Configure the rule with one of these modes:

• Block: Recommended for production environments - completely prevents the action
• Audit: Recommended for initial testing - logs events but allows the action
• Warn: Available on Windows 10 1809+ and Windows 11 - prompts users before blocking

For initial deployment, select Audit to monitor potential impacts. You can change this to Block after testing.

Consider enabling these complementary rules for comprehensive protection:

• Block Office applications from injecting code into other processes (GUID: 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)
• Block Office child processes (GUID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A)

Click Next to proceed to assignments.

Proper group assignment ensures your ASR policy reaches the right devices while avoiding disruption to critical systems. Start with a pilot group before full deployment.

On the Assignments tab, configure the following:

Included groups: Click Add groups and select your pilot group first. This should be a small group of test devices or users who can validate the policy's impact.

Example pilot group selection:

Group Name: IT-Pilot-Devices-ASR-Testing
Description: 10-15 devices for ASR policy validation
Members: Mix of different Office usage patterns

Excluded groups: Consider excluding:

• VIP users or executives (initially)
• Devices running critical business applications
• Servers with automated Office processing

Click Next to proceed to the review step.

The final review step ensures all configurations are correct before deployment. Take time to verify each setting as policy changes can take several hours to propagate.

On the Review + create tab, verify the following settings:

• Policy name: ASR - Block Office Executable Content Creation
• Platform: Windows 10, Windows 11, and Windows Server
• Profile: Attack surface reduction rules
• Rule configuration: Block Office applications from creating executable content = Audit (or your chosen mode)
• Assignments: Your pilot group is included

If everything looks correct, click Create to deploy the policy.

The policy will begin deploying to assigned devices. Deployment typically takes 1-8 hours depending on device check-in frequency and network conditions.

Tracking deployment progress helps identify devices that haven't received the policy and troubleshoot any assignment issues before testing begins.

Navigate back to Endpoint security > Attack surface reduction and click on your newly created policy name.

Review the following sections:

Device status: Shows how many devices have successfully received the policy:

• Succeeded: Policy applied successfully
• Error: Policy failed to apply (investigate these devices)
• Conflict: Multiple conflicting policies detected
• Not applicable: Device doesn't meet requirements

User status: Shows per-user deployment status if using user-based assignments.

Click on individual status categories to see detailed device lists and error messages.

Event Viewer provides the most reliable method to confirm that ASR rules are active and functioning on target devices. This verification step is crucial before proceeding to testing.

On a test device that received the policy, open Event Viewer by pressing Windows + R, typing eventvwr.msc, and pressing Enter.

Navigate to the following path:

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

Look for these specific Event IDs related to your ASR rule:

• Event ID 1121: ASR rule triggered in Audit mode
• Event ID 1122: ASR rule triggered in Block mode
• Event ID 5007: ASR configuration change detected

Filter the log to show only ASR-related events by right-clicking the Operational log, selecting Filter Current Log, and entering Event IDs: 1121,1122,5007.

Controlled testing validates that your ASR rule correctly identifies and handles Office applications attempting to create executable content. This step confirms the policy is working as expected.

On a test device with the policy applied, create a test scenario:

Method 1 - Word Macro Test:

1. Open Microsoft Word
2. Create a new document
3. Press Alt + F11 to open the VBA editor
4. Insert a new module and add this test code:

Sub TestExecutableCreation()
    Dim fso As Object
    Set fso = CreateObject("Scripting.FileSystemObject")
    
    ' Attempt to create a .exe file (this should be blocked)
    Dim testFile As Object
    Set testFile = fso.CreateTextFile("C:\temp\test.exe", True)
    testFile.WriteLine "This is a test executable"
    testFile.Close
    
    MsgBox "Test completed"
End Sub

5. Run the macro by pressing F5

Expected Results:

• Audit mode: Macro runs but Event ID 1121 is logged
• Block mode: Macro is prevented and Event ID 1122 is logged
• Warn mode: User receives a warning prompt

After testing reveals any legitimate applications being blocked, configure appropriate exclusions before transitioning from Audit to Block mode for full protection.

Adding Exclusions (if needed):

Return to your ASR policy in the Intune admin center. Click Properties, then Edit next to Configuration settings.

For the "Block Office applications from creating executable content" rule, you can add exclusions for:

• File paths: C:\Program Files\TrustedApp\*
• File names: legitimate-tool.exe
• Process names: trusted-process.exe

Example exclusion configuration:

Exclusion Type: File Path
Path: C:\Program Files\RemoteManagement\winagent.exe
Reason: Legitimate RMM tool blocked by ASR rule

Transitioning to Block Mode:

Once testing is complete and exclusions are configured:

1. Edit the policy configuration settings
2. Change the rule mode from Audit to Block
3. Expand assignment to broader user groups
4. Monitor for 48-72 hours before full deployment