Harden Microsoft Office: macros, OLE and add-ins
Lock down Microsoft 365 Apps: block internet macros, disable XLM, scan VBA with AMSI, keep Protected View on, require signed add-ins, stop OLE and DDE.
Office documents are still one of the most common first stages of an intrusion. Macros get most of the attention, but attackers also use Excel 4.0 (XLM) macros, embedded OLE packages, DDE fields, malicious add-ins and anything that tempts a user out of Protected View. Microsoft has tightened the defaults a lot since 2022. The job now is to turn those defaults into enforced policy and close the side doors.
This guide is about the Office side. The ASR rules guide covers the Defender rules that contain Office when something does run, and the Attack Surface Reduction topic ties the area together.
Prerequisites
- Microsoft 365 Apps (or Office 2019/2021/2024) on a supported channel. Settings below use the
16.0registry path shared by all current versions. - Office administrative templates (ADMX/ADML) from the Microsoft Download Center, copied to the central store. Most settings are under User Configuration, because Office policy is per user.
- Alternatively, the Cloud Policy service (config.office.com) or the Intune settings catalog, which expose the same settings and follow the user to unmanaged devices.
The Microsoft 365 Apps security baseline in the Security Compliance Toolkit contains most of what follows; compare it with your current state before importing.
Step 1: block macros from the internet, explicitly
For each of Word, Excel, PowerPoint, Access and Visio, set:
User Configuration > Policies > Administrative Templates > Microsoft Word 2016 > Word Options > Security > Trust Center > Block macros from running in Office files from the Internet = Enabled
The paths are the same for the other apps (Microsoft Excel 2016 > Excel Options > Security > Trust Center, and so on). The registry value is:
HKCU\Software\Policies\Microsoft\Office\16.0\<app>\Security
blockcontentexecutionfrominternet REG_DWORD 1The block depends on the Mark of the Web, the Zone.Identifier alternate data stream set by browsers and mail clients. Two consequences:
- Don't add broad domains, your SharePoint tenant or file servers to the Trusted sites zone just to make an app work. Files from trusted zones are exempt.
- Files reached over a UNC path by IP or FQDN may be treated as Internet zone. Fix the Local intranet zone site list instead of weakening the policy.
Step 2: set a strict VBA default
Trust Center > VBA Macro Notification Settings = Enabled, Disable all except digitally signed macros (or Disable all without notification where nobody needs macros). Registry VBAWarnings:
| Value | Meaning |
|---|---|
| 1 | Enable all macros (never) |
| 2 | Disable all with notification (user can click Enable) |
| 3 | Disable all except digitally signed macros |
| 4 | Disable all without notification |
For signed macros to run, sign them with a code-signing certificate and deploy it to the Trusted Publishers store via Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Publishers. Also set Trust Center > Turn off trusted documents = Enabled, so a user who once clicked Enable Content does not permanently trust that file.
Step 3: kill XLM macros and scan VBA with AMSI
Excel 4.0 macros predate VBA, live in hidden sheets, and bypassed many controls for years. Set:
Microsoft Excel 2016 > Excel Options > Security > Trust Center > Prevent Excel from running XLM macros = Enabled (registry XL4MacroOff = 1 under ...\16.0\Excel\Security).
Then let Defender (or any AMSI-aware antivirus) see macro behaviour at runtime:
Microsoft Office 2016 > Security Settings > Macro Runtime Scan Scope = Enable for all documents (registry MacroRuntimeScanScope = 2 under HKCU\Software\Policies\Microsoft\Office\16.0\Common\Security).
Without this, AMSI scanning of VBA applies only to lower-trust documents. See AMSI for how the interface works.
Step 4: keep Protected View on
Protected View opens risky files read-only in a sandbox. Every setting under Trust Center > Protected View is phrased as "Do not..." or "Turn off...", so the secure value is Disabled:
| Setting | Secure value |
|---|---|
| Do not open files from the Internet zone in Protected View | Disabled |
| Do not open files in unsafe locations in Protected View | Disabled |
| Turn off Protected View for attachments opened from Outlook | Disabled |
| Set document behavior if file validation fails | Enabled, Open in Protected View, do not allow edit |
Under Trust Center > File Block Settings, block opening of legacy binary formats nobody uses (Word 2 and earlier documents, Excel 4 workbooks and macro sheets, and similar pre-97 formats). They exist mostly for attackers now.
Step 5: add-ins, trusted locations and ActiveX
- Require that application add-ins are signed by Trusted Publisher = Enabled, together with Disable Trust Bar Notification for unsigned application add-ins and block them = Enabled. Inventory COM and VSTO add-ins first (File > Options > Add-ins on a sample of machines, or your software inventory); unsigned in-house add-ins need signing before you enforce.
- Trusted Locations: set Allow Trusted Locations on the network = Disabled and remove user-writable locations. A macro in a trusted location runs with no prompt and no Mark of the Web check, so a trusted location that users can write to is a bypass.
- Disable All ActiveX under Microsoft Office 2016 > Security Settings = Enabled where no ActiveX controls are used in documents.
Step 6: OLE packages and DDE
Embedded OLE Package objects let a document carry a script or executable that runs when double-clicked. Block activation per app:
HKCU\Software\Microsoft\Office\16.0\Word\Security
PackagerPrompt REG_DWORD 2 (0 = run without prompt, 1 = prompt, 2 = do not run)Set the same value for Excel and PowerPoint. Deploy with Group Policy Preferences or Intune if your template version has no ADMX setting for it.
For DDE, set Don't allow Dynamic Data Exchange (DDE) server launch in Excel and Don't allow Dynamic Data Exchange (DDE) server lookup in Excel to Enabled. In Word, set AllowDDE = 0 (REG_DWORD under HKCU\Software\Microsoft\Office\16.0\Word\Security), which disables DDE and has been the default since the December 2017 update; 1 allows DDE only to already running programs and 2 fully allows it. Enforce 0 so nobody re-enables it.
Outlook has its own macro setting (Microsoft Outlook 2016 > Security > Trust Center > Security setting for macros). Set it to warn for signed and disable unsigned, or never warn and disable all.
Step 7: find macro dependence before you enforce
Most of the pain in this project comes from not knowing who uses macros. Before enforcing signed-only VBA, look for macro-enabled files on the shares and in the OneDrive or SharePoint libraries that business teams actually use:
Get-ChildItem -Path \\fs01\Departments -Recurse -Include *.xlsm, *.xlam, *.xls, *.docm, *.dotm, *.pptm -ErrorAction SilentlyContinue |
Group-Object { $_.Directory.FullName } |
Sort-Object Count -Descending |
Select-Object Count, Name -First 50Sort the results by folder and by last write time. Files untouched for years are archive material, not a blocker. Active folders give you the names of the teams to talk to: they either get their macros signed, move them to a controlled trusted location, or replace them with a supported tool. Note that .xls files can contain VBA too, so the extension alone does not prove anything; the list is a starting point for conversations, not an inventory.
While this runs, enforce the internet-macro block and XLM disablement straight away. They almost never break legitimate work and they close the most common delivery path.
What breaks
- Workbooks from partners that rely on macros now open without them. Have the owner sign them or open them from a controlled trusted location.
- Legacy Excel models with XLM functions stop calculating. Search file shares for
.xlmand for workbooks with macro sheets before enforcing. - Unsigned COM add-ins (CRM connectors, PDF tools) are blocked once signing is required. Get signed versions first.
- Document templates on a network share used as trusted locations stop working when network trusted locations are disabled. Move them to SharePoint or a local, admin-only path.
- ActiveX controls in forms stop loading.
Pilot with IT and one business team for two weeks, collect the complaints, fix them at source, then widen.
Verify it
On a pilot device, as the user:
$base = "HKCU:\Software\Policies\Microsoft\Office\16.0"
foreach ($app in "Word","Excel","PowerPoint") {
Get-ItemProperty "$base\$app\Security" -ErrorAction SilentlyContinue |
Select-Object @{n='App';e={$app}}, blockcontentexecutionfrominternet, VBAWarnings, RequireAddinSig
}
Get-ItemProperty "$base\Excel\Security" -Name XL4MacroOff -ErrorAction SilentlyContinue
Get-ItemProperty "$base\Common\Security" -Name MacroRuntimeScanScope -ErrorAction SilentlyContinueIf you use Cloud Policy, values land under HKCU\Software\Policies\Microsoft\Cloud\Office\16.0 instead. Then test functionally: download a harmless macro-enabled document from the internet and confirm the red Security risk banner appears with no Enable Content button. On the Defender side, AMSI detections of macro content appear as normal detections (event 1116) in the Defender Operational log.
Checklist
- Office ADMX templates current, or Cloud Policy / Intune settings catalog in use
- Block macros from the Internet enabled for Word, Excel, PowerPoint, Access and Visio
- VBA set to signed-only or disabled; trusted documents off
- XLM macros disabled; Macro Runtime Scan Scope = all documents
- Protected View settings all at their secure values; legacy formats blocked
- Add-ins require signing; no user-writable or network trusted locations
- OLE Package activation and DDE blocked
- Office ASR rules enforced alongside
Frequently asked questions
Doesn't Microsoft already block macros from the internet by default?
Yes, current Microsoft 365 Apps block VBA macros in files carrying the Mark of the Web for Word, Excel, PowerPoint, Access and Visio. The default is a behaviour, not a policy, so users and older builds can still end up allowing them. Setting the policy explicitly makes the block enforceable, reportable and consistent across channels.
Our finance team needs macros. What is the safest way to allow them?
Sign the macros with a code-signing certificate, deploy that certificate as a trusted publisher, and set VBA macro notification to disable all except digitally signed macros. If signing is impossible, use a single tightly controlled trusted location on a share that ordinary users cannot write to, rather than allowing macros everywhere.
Do these settings replace ASR rules for Office?
No, they complement them. Office policy stops a macro from running at all; ASR rules limit what a macro that does run can do, such as spawning child processes or calling Win32 APIs. Configure both, because users and attackers regularly find ways around one layer.
Harden Microsoft Office: macros, OLE and add-ins