ASD ISM 1673 Prevent Win32 API calls by Office macros
What it says
Microsoft Office macros are blocked from making Win32 API calls.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishMicrosoft Office macros cannot make direct calls to Windows APIs.
This control means Microsoft Office macros can't directly communicate with the core parts of Windows that handle tasks like opening programs or accessing files. This is important because if macros could do this, they might be used by bad actors to spread viruses or steal data from your computer systems.
Free. Save your status, tasks and notes.
Why it matters
If Office macros can call Win32 APIs, attackers can run native code, bypass protections and deliver malware or steal data.
How to implement
IT team should configure Microsoft Office settings: Adjust the settings in Microsoft Office applications to disable direct calls to Windows APIs by macros.
This can typically be done through group policy settings in the network management tools they use.
Office manager to inform and educate staff: Ensure all staff are aware that Office macros will have restricted capabilities and this is for their security.
Use a short email or a meeting to explain that macros won't be able to perform risky operations that could harm the computer system.
System administrator should implement updates: Regularly check for and apply Microsoft Office updates that may be required to enforce this control.
Make use of the automatic update feature where possible to ensure all Office applications are up to date.
The security team should perform regular checks: Conduct periodic reviews of policy settings to ensure that the macro security settings remain enforced.
This can be done through audits of system configurations.
Procurement should verify software compatibility: Before purchasing or updating software that integrates with Office, ensure it is compatible with this restriction on macros.
Discuss with software vendors about how their applications work with restricted macro functionality.
Keep it running
Configure Office policy to block Win32 API calls from VBA/macros, and validate via GPO/registry settings and audit logs.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The Office macro policy settings documentation: Request evidence of current Microsoft Office macro settings being enforced.
Look at
The group policy or configuration files for entries that block API calls.
Good evidence
Is policies showing settings that restrict macro API usage.
- Check 2 of 5What an auditor asks for
Ask for
A demonstration of restricted macro behaviour: Request an IT staff member to show how a macro's attempt to make API calls is blocked during operation.
Look at
How the application responds and logs errors.
Good evidence
Would be real-time logs showing blocked API call attempts.
- Check 3 of 5What an auditor asks for
Ask for
A recent security test report on Office macros: Obtain a report on security test results concerning blocked macro actions.
Look at
Any mention of penetration tests attempting to use API calls.
Good evidence
Is a report showing no successful attempts to exploit APIs.
- Check 4 of 5What an auditor asks for
Ask for
Training records regarding macro policy: Check records of staff training sessions that cover Microsoft Office restrictions on macros.
Look at
The topics covered and attendance lists.
Good evidence
Includes completed training records with dates and attendees.
- Check 5 of 5What an auditor asks for
Ask for
Update logs or schedules for Office software: Request the update logs or schedules showing regular software updates are applied.
Look at
Specific entries related to macro security updates.
Good evidence
Is a documented update routine ensuring the latest security patches are applied.
Mappings
Closest match in ASD Essential Eight: E8-RM-ML2.1, Microsoft Office macros are blocked from making Win32 API calls, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.9.
ISM-1673 requires implementing a specific security configuration: blocking Win32 API calls from Microsoft Office macros. ISO/IEC 27001:2022 Annex A 8.9 requires establishing, documenting, implementing, monitoring and reviewing system configurations in general, including security configurations. ISM-1673 is a single, prescriptive configuration item that would sit within the broader configuration management discipline required by Annex A 8.9.
ASD Essential Eight: 8 mappings
This control is equivalent to E8-RM-ML2.1.
E8-RM-ML2.1 requires blocking Microsoft Office macros from making Win32 API calls, which aligns with ISM-1673's equivalent mandate. Both controls directly address the same macro-to-Win32 API interaction and have matching scope and intent, ensuring that implementing one satisfies the other.
This control partially overlaps E8-AH-ML2.2.
E8-AH-ML2.2 requires Microsoft Office to be blocked from creating child processes to reduce Office-based malware execution and living-off-the-land activity. ISM-1673 specifically blocks Microsoft Office macros from making Win32 API calls, which is another common technique used by malicious macros to execute payloads or evade controls. Both reduce macro-enabled attack paths in Office, but E8-AH-ML2.2 focuses on process creation, while ISM-1673 focuses on API-level macro capabilities and does not necessarily prevent non-macro Office components from spawning processes.
This control partially overlaps E8-AH-ML2.3.
ISM-1673 requires that Office macros cannot directly call Win32 APIs, limiting low-level system interaction from macro code. E8-AH-ML2.3 blocks Microsoft Office from creating executable content, reducing the likelihood that a macro-driven workflow can drop or generate binaries. The controls intersect in reducing macro-enabled malware execution paths, but ISM-1673 is focused on API call capability whereas E8-AH-ML2.3 is focused on preventing a particular payload creation behaviour.
This control partially overlaps E8-AH-ML2.4.
E8-AH-ML2.4 requires Microsoft Office to be blocked from injecting code into other processes. ISM-1673 blocks Office macros from making Win32 API calls, which can be used to perform or facilitate process injection and related malicious behaviours. ISM-1673 is broader in constraining macro capabilities, while E8-AH-ML2.4 is a specific mitigation focused on the injection technique regardless of how it is initiated.
This control partially overlaps E8-AH-ML2.5.
ISM-1673 requires blocking Win32 API calls by Office macros to constrain macro capability. E8-AH-ML2.5 requires configuring Office to prevent activation of OLE packages, addressing a different Office abuse vector commonly used to execute embedded or linked content. Both reduce Office-borne code execution pathways, but they address different technical mechanisms (macro API calls versus OLE activation).
This control partially overlaps E8-RM-ML1.2.
ISM-1673 requires that Office macros are blocked from making Win32 API calls regardless of origin, limiting what macros can do if they run. E8-RM-ML1.2 blocks macros in files originating from the internet, reducing the likelihood of untrusted macros executing in the first place. E8-RM-ML1.2 is about trust/origin-based prevention, while ISM-1673 is about capability restriction for macros that may execute.
- E8-RM-ML3.1Restrict Microsoft Office macros to only trusted or sandboxed environmentsPartially overlaps
This control partially overlaps E8-RM-ML3.1.
ISM-1673 requires that Office macros are blocked from making Win32 API calls, limiting macro capability even when execution is permitted. E8-RM-ML3.1 restricts macro execution to sandboxed environments, Trusted Locations, or trusted signatures, controlling where and under what trust conditions macros can run. Both reduce macro-driven compromise, but E8-RM-ML3.1 is about execution allow-listing/trust boundaries while ISM-1673 is a specific runtime restriction on API access.
This control supports E8-RM-ML1.4.
ISM-1673 requires enforcing a specific macro hardening setting: blocking Win32 API calls from Office macros. E8-RM-ML1.4 requires preventing users from changing macro security settings, which helps ensure the ISM-1673 protection remains enabled and cannot be bypassed by end users. E8-RM-ML1.4 is broader about configuration integrity, whereas ISM-1673 is one particular macro restriction.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.