Essential Eight AH-ML2.4 Block Microsoft Office from injecting code into other processes
What it says
Microsoft Office is blocked from injecting code into other processes.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishStop Microsoft Office from putting code into other programs to prevent security risks.
Imagine you're working on your computer and a sneaky virus uses Microsoft Office, like Word or Excel, to spread to other parts of your system. This control stops that from happening by making sure Office can't slide its code into other programs, which helps keep your whole system safer.
Free. Save your status, tasks and notes.
Why it matters
If Office can inject code into other processes, attackers can run payloads in trusted apps, steal credentials and persist silently.
How to implement
IT team: Ensure Microsoft Office is configured so it cannot inject code into other processes.
Use endpoint security solutions or group policy settings to enforce this.
System administrator: Regularly update Microsoft Office and related security policies to prevent manual bypasses.
Use automatic updates to keep systems up to date.
Security officer: Conduct regular training for employees on recognising potential phishing attempts within Office documents.
Use educational sessions and resources.
Network administrator: Monitor and limit permissions that Office applications have on user machines.
Use tools like AppLocker to define what Office can and cannot do.
Keep it running
Enable the ASR rule 'Block Office apps from injecting into other processes' via GPO/Intune and review Defender alerts for blocked injections.
Evidence and audit
- Check 1 of 2What an auditor asks for
Ask for
Can you show me how Microsoft Office's ability to inject code into other processes is controlled?
Look at
Examine the policy settings in the group policy management console or documentation from security software solutions.
Good evidence
There should be a documented policy or setting that shows Microsoft Office is prevented from injecting code into other processes, evidenced by screenshots or policy settings.
- Check 2 of 2What an auditor asks for
Ask for
How are updates and patches managed for Microsoft Office?
Look at
Check update logs or automated update settings.
Good evidence
Automatic updating should be enabled, and logs should show recent updates applied to Office applications.
Mappings
Closest match in ASD Information Security Manual: ISM-1601, Implement Microsoft Attack Surface Reduction rules, which asks for the same thing.
ASD Information Security Manual: 6 mappings
This control is equivalent to ISM-1601.
ISM-1601 requires organisations to implement Microsoft Attack Surface Reduction rules. E8-AH-ML2.4 maps directly because one of Microsoft's ASR rules is to block Office applications from injecting code into other processes, which is exactly the behaviour described. Implementing the relevant ASR rule to satisfy ISM-1601 would largely satisfy E8-AH-ML2.4 for that requirement.
This control is equivalent to ISM-1669.
E8-AH-ML2.4 requires Microsoft Office to be blocked from injecting code into other processes to reduce macro-driven and exploit-driven post-compromise behaviour. ISM-1669 states the same requirement, targeting the same Office-to-process injection technique (commonly implemented via Microsoft Defender Attack Surface Reduction rules or equivalent controls). The scope and implementation intent align closely, so satisfying ISM-1669 would largely satisfy E8-AH-ML2.4.
This control partially meets ISM-1858.
ISM-1858 mandates hardening of IT equipment using ASD and vendor guidance, with the most restrictive guidance taking precedence. E8-AH-ML2.4 requires a specific Microsoft Office hardening setting (blocking Office from injecting code into other processes) that reduces exploit and lateral execution techniques. This candidate is narrower because it is one prescriptive configuration control within the broader equipment hardening program required by ISM-1858.
This control partially overlaps ISM-1667.
E8-AH-ML2.4 requires blocking Microsoft Office from injecting code into other processes. ISM-1667 instead requires blocking Microsoft Office from creating child processes, which mitigates a related but different Office abuse path (process spawning rather than process injection). Both reduce Office's ability to launch or control other programs, but E8-AH-ML2.4 targets injection specifically while ISM-1667 targets process creation.
This control partially overlaps ISM-1668.
E8-AH-ML2.4 requires blocking Microsoft Office from injecting code into other processes to prevent in-memory execution and tampering. ISM-1668 requires blocking Microsoft Office from creating executable content, addressing a different persistence/execution pathway (dropping or generating executables) rather than injection. They commonly co-exist as Office hardening measures, but each control targets a distinct attacker technique.
This control partially overlaps ISM-1673.
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.
ASD Essentials for enterprise IT: 1 mapping
- IT.PRO-04.1Define approved hardening baselines disabling unneeded services, insecure settings and weak protocolsPartially overlaps
This control partially overlaps IT.PRO-04.1.
IT.PRO-04.1 requires approved configuration baselines that disable or remove unnecessary services, insecure settings and weak protocols; E8-AH-ML2.4 requires Microsoft Office to be blocked from injecting code into other processes, an Office restriction such a baseline would set.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.