Disable Office Macros

What the Microsoft Office macro blocker does

This Automox Worklet™ enforces the Microsoft Office 16.0 "Block macros from running in Office files from the Internet" policy on Windows endpoints. The Worklet writes the blockcontentexecutionfrominternet DWORD value to 1 under the Word, Excel, and PowerPoint Security keys in each user's policy hive. Office then refuses to execute any macro inside a document carrying the Mark of the Web (MOTW) attribute.

The remediation script applies the policy per user, not per machine. It enumerates every profile under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, filters for real account SIDs with the pattern S-1-5-21-*, and loads each user's ntuser.dat hive into HKEY_USERS when the profile is not already mounted. For each loaded SID it creates the three Security subkeys under Software\Policies\Microsoft\Office\16.0\<app>\Security, sets blockcontentexecutionfrominternet to 1, and then unloads any hive it mounted so it leaves no orphaned handles behind.

The evaluation script is intentionally a one-line Exit 1. The Worklet always reports non-compliant, so the remediation phase runs on every Automox policy execution. That keeps the policy in place for new user profiles created after the first run and re-enforces the setting if a user removes the registry key out of the policy hive.

Why block macros from the internet on Microsoft Office

Macro-borne malware remains one of the top initial access vectors against Windows fleets. Phishing emails deliver Word, Excel, or PowerPoint attachments containing weaponized VBA code disguised as invoices, shipping notices, HR forms, or legal documents. A single click on Enable Content executes a downloader that pulls Emotet, Qakbot, IcedID, TrickBot, or a ransomware loader straight onto the endpoint. The blockcontentexecutionfrominternet policy enforced here aligns with CIS Microsoft Office Benchmark control 1.1.1, NIST 800-53 SI-3, and the Microsoft Secure Configuration Baseline; it is the same registry value that GPO and Microsoft Endpoint Manager apply through the Office ADMX templates.

Remote and infrequently-online laptops that drift out of GPO scope still pick up the block on their next Automox check-in. Because the Worklet writes to each user hive directly under HKEY_USERS rather than relying on Group Policy refresh, the setting takes effect on the next Office application launch without waiting for gpupdate. The Automox activity log captures the per-SID registry writes for the change-control record.

How Microsoft Office macro blocking works

1. Evaluation phase: The evaluation script exits with code 1 on every run, so the endpoint is always treated as non-compliant. This intentional force-run pattern keeps the policy applied for new user profiles and re-asserts the registry values after any local change. If you prefer drift-based reporting instead, replace the Exit 1 line with a Get-ItemProperty check against HKEY_USERS\<SID>\Software\Policies\Microsoft\Office\16.0\Word\Security\blockcontentexecutionfrominternet for each profile and exit 0 only when every SID returns 1.

2. Remediation phase: The remediation script enumerates user profiles from HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList using the SID regex S-1-5-21-\d+-\d+-\d+-\d+. It compares the profile list against the currently loaded HKEY_USERS hives, then runs reg load HKU\<SID> <path-to-ntuser.dat> for any unloaded profile. For each SID it executes New-Item and Set-ItemProperty against Software\Policies\Microsoft\Office\16.0\Word\Security, Excel\Security, and Powerpoint\Security, writing blockcontentexecutionfrominternet=1. After the writes, it forces [gc]::Collect() and reg unload HKU\<SID> for any hive it mounted.

Microsoft Office macro policy requirements

• Windows endpoint with Microsoft Office 2016 or newer installed under the 16.0 registry path (Office 2019, Office 2021, and Microsoft 365 Apps all use 16.0)

• PowerShell 2.0 or later (the Automox agent runs scripts under SYSTEM, which meets this by default)

• SYSTEM-level rights to call reg load and write into HKEY_USERS hives for offline profiles

• At least one interactive user profile present at C:\Users\<name>\ntuser.dat; the script silently skips profiles whose hive cannot be loaded

• No conflicting GPO writing the same registry value with the opposite setting; group policy will override any per-user write if Office macros from the internet are explicitly enabled in a higher-precedence GPO

Expected Microsoft Office behavior after macro blocking

After remediation, every Word, Excel, and PowerPoint user on the endpoint sees the red Microsoft Office security risk notification stating that macros have been blocked because the source of the file is untrusted, whenever they open a macro-enabled document carrying the Mark of the Web attribute. There is no Enable Content button on that notification, so the social-engineering step that ransomware operators rely on is removed. Documents from trusted internal locations – SharePoint sites added to Trusted Locations, files copied off a mapped network drive, locally created spreadsheets – still run macros normally.

Validate by inspecting the registry directly. Run reg query HKEY_USERS\<SID>\Software\Policies\Microsoft\Office\16.0\Word\Security /v blockcontentexecutionfrominternet for each active profile and confirm the value is REG_DWORD 0x1. Repeat for Excel and Powerpoint. End-to-end, download a macro-enabled test document from an external location and confirm Office opens it with the red security risk notification and no path to execute the VBA. Capture both the registry export and a screenshot of the notification for audit evidence and attach them to the Automox policy run identifier.

New user profiles inherit the block only when the policy is re-asserted, and a manual registry edit by an end user can quietly reopen the gap. A recurring Automox policy run re-writes the keys across every active profile so a missing value cannot become the foothold for a phishing payload.