Back to The Controls Desk
// Controls Desk · 30 April 2026 · Endpoint

Block Office macros from any document originating outside the organisation

VBA macros in inbound Office documents have been the preferred ransomware delivery vehicle for a decade. Microsoft now blocks them by default. Reverse the default at your peril.

Quadrant
Quick win
Ease
5 / 5
Impact
4 / 5
Control family
Endpoint
Cost band
none
Catalogued incidents
7

What the control is

Office macros — Visual Basic for Applications code embedded inside Word, Excel and PowerPoint documents — execute in the security context of the user that opens the document. Macros are extremely powerful: they can write files to disk, make network connections, instantiate COM objects, and call out to PowerShell or cmd.exe. For two decades they were the most reliable code-execution-in-userland primitive available to attackers via email-borne lures.

The control is to disable macro execution for any document with the Mark-of-the-Web attribute — that is, any document originating from outside the organisation, downloaded from the internet, or attached to inbound email. Macros remain available for genuinely-internal Office documents stored in trusted locations, signed by approved internal certificates, or explicitly admin-allowlisted. The default for inbound, internet-origin documents is “blocked, no user override available.”

Microsoft made this the application-level default in 2022 across Microsoft 365 Apps and the supported Office release channels. The control is now whether your organisation has reverted to the older permissive behaviour via Group Policy, registry override, or tenant-wide Cloud Policy.

Why it matters

The major commodity-ransomware delivery families — Emotet, Trickbot, Qakbot, Dridex, IcedID, Bumblebee — relied on macro-enabled inbound Office documents for the better part of a decade. Phishing email arrives with a Word or Excel attachment; user is socially engineered into clicking “Enable Editing” and “Enable Content”; macro fires and pulls down the second-stage payload from the internet. The pattern was so reliable that the entire ransomware affiliate ecosystem standardised on it.

The catalogue’s worked examples cluster on this technique. Norsk Hydro’s March 2019 LockerGoga starting point traced back to a macro-enabled phishing document. The HSE Ireland Conti attack of May 2021 began the same way. Travelex’s December 2019 Sodinokibi event sat downstream of a macro-led phishing campaign. The British Library’s Rhysida ransomware of October 2023, and a long tail of less famous mid-tier ransomware events, share the lineage. Even older, pre-ransomware-economy incidents in the catalogue — Hannaford Brothers (2008), the Bangladesh Bank SWIFT heist’s reconnaissance phase — used macro-borne malware as part of the chain. NotPetya itself was not macro-delivered, but Maersk’s first compromised endpoint sat in a network where macro hardening had not been applied tenant-wide and so the broader macro-attack surface was open in the same period.

Since Microsoft’s 2022 default, the macro-led commodity-malware ecosystem has visibly degraded. Affiliates have moved to ISO and ZIP-with-LNK delivery, container-format abuse, and HTML-smuggling — none of which is as reliable as the previous macro chain. The control is genuinely a step-change in delivery economics.

Where the regulators sit

NCSC’s “Macro security for Microsoft Office” guidance is the cleanest national-agency statement and recommends blocking macros from internet-origin documents by default with no user override, allowlisting only via Trusted Locations or signed macros. The Australian Cyber Security Centre’s Essential Eight makes user-application macro hardening one of its eight pillars and specifies progressive maturity levels: at level three, macros are disabled for all users with no user-overrideable bypass. CIS Controls v8 Control 9 (“Email and Web Browser Protections”) includes the same recommendation. CISA’s joint advisories on ransomware delivery have repeatedly highlighted macro-blocking as one of the highest-impact prevention controls. Microsoft’s own published default — backed by their telemetry on macro-borne malware — is the same.

The standards-body and vendor view converge here, which is unusual.

Where it usually breaks

The single failure mode is the legitimate macro-using business process. Most large enterprises have a handful of internal teams — finance, controlling, treasury — using Excel macros for genuinely valuable purposes. The objection is that blocking macros breaks those processes. The fix is the allowlist, not the loosening: Trusted Locations for internal SharePoint or file-share paths where the legitimate documents live, or signed-macro policy with an internal code-signing certificate. Both are well-documented in the Microsoft and ACSC guidance. The temptation to leave macros enabled tenant-wide because allowlisting is fiddly is the temptation to keep an open door for the entire ransomware affiliate ecosystem. Don’t.

What good looks like

Tenant-wide Cloud Policy or Group Policy setting Office to block macros from the internet with no user override. A documented and reviewed allowlist of Trusted Locations for genuinely-internal macro documents. Internal code-signing for any macro that needs to run from non-Trusted-Locations. Quarterly review of the allowlist. Mark-of-the-Web removal disabled at the file-system level so users cannot strip the MOTW to bypass the control.

The cost is configuration time. The benefit is removing the most-used commodity-malware delivery vehicle of the last decade.

Where this control would have changed the outcome

Sources

Back to The Controls Desk