Which logs show evidence of malicious Office macros?

What logs are most useful when you suspect malicious Office macros?

Look first in Office application logs, endpoint telemetry, and process creation data, because macro abuse is usually visible when a document launches a script host, command shell, or downloader. Those records help you distinguish normal document activity from macro-triggered execution and show whether the macro came from an external source or tried to bypass user prompts and macro restrictions.

Office-native logging is useful when it captures document open events, macro execution traces, or security prompt behaviour. On its own it is rarely enough, so the practical test is whether the log line can be tied to a specific document, user action, and follow-on process chain. If you cannot connect those three, treat the finding as incomplete rather than proof of maliciousness.

Endpoint telemetry adds the missing execution context. The strongest signals are child processes spawned from Word, Excel, or PowerPoint, especially when the child process is mapped against common ATT&CK techniques such as script interpreter use, shell launch, or staged payload download. That same process tree often shows the moment the document moved from “opened” to “executed,” which is the key pivot for triage.

Which process and behaviour patterns matter most?

The highest-value patterns are document-to-process chains, unexpected script execution, and attempts to hide the original source of execution. A macro that starts PowerShell, cmd.exe, wscript.exe, mshta.exe, or similar tooling is more suspicious than a macro that only updates content or interacts with the document itself. Download activity, encoded command lines, or unusual network connections immediately after document open make the case stronger.

Behavioural context matters as much as the process name. A macro-enabled file arriving from email, a shared drive, or a browser download deserves more scrutiny than a trusted internal template. If your telemetry can correlate the attachment hash, email gateway metadata, user session, and endpoint process tree, you can often separate benign automation from a real intrusion path without waiting for a second alert.

For broader hunting and containment logic, Persistence Techniques Guide is useful because macro-delivered activity often stops being “just a macro” once it creates follow-on execution, startup changes, or staged access on the host. That helps you look beyond the initial child process and ask whether the document was used to establish a durable foothold.

How do you separate macro abuse from legitimate Office automation?

Not every macro warning is malicious. Legitimate automation usually comes from known files, expected business workflows, signed templates, or controlled shared locations. Malicious macro activity is more likely when the file is external, newly seen, unsigned, renamed, or delivered in a way that depends on social engineering to get the user to enable content.

Investigation should focus on what changed after the document opened. If the macro immediately attempted to evade macro protections, spawn a shell, or chain into a downloader, that is a materially different pattern from a macro that performs spreadsheet calculations or internal document formatting. This distinction is critical because defenders sometimes overfit on “macro present” and miss the more important question: what execution path did the macro trigger?

For a detection workflow that starts with lures and moves toward malicious execution, the Phishing Guide helps connect the delivery side to the host-side evidence. In many cases the macro is only the final step in a larger phishing chain, so the attachment provenance can explain why the Office logs look suspicious in the first place.

Risk and Threat Considerations

Malicious Office macros are risky because they turn a trusted file format into a launch point for code execution on the endpoint. Once a macro crosses into child-process creation, the same document can be used to stage payloads, steal data, or create persistence, and the visible document often looks harmless after the initial click.

Failure mechanism: The macro abuses user trust and Office process behaviour to spawn external interpreters or shells, then chains into download, execution, or post-compromise activity before defenders review the document itself.

Impact: Organisations can miss the real compromise path if they only inspect the file and ignore endpoint telemetry, allowing credential theft, lateral movement, or persistence to continue from a seemingly ordinary document open event.

Practitioner Guidance

What to verify: Confirm the parent-child process chain, the file origin, and whether macro prompts or policy restrictions were bypassed. If the telemetry shows only a document open event with no suspicious descendants, keep the alert low priority; if it shows a script host or shell, escalate immediately.

Decision rule: If the document is external and the macro launches anything beyond normal Office behaviour, treat it as a potential intrusion path, not a simple user mistake. Prioritise containment of the host and review of adjacent user activity before spending time classifying the macro’s intent.

Practitioner takeaway: The most reliable evidence is not “a macro existed,” but “a macro caused unexpected execution.” Build your triage around the process tree and source context, because that is where malicious intent becomes observable.

Related resources from NHI Mgmt Group

• How should teams reduce risk from malicious npm package installs?
• What are the signs that a malicious Office document is using DDE instead of macros?
• Which logs show evidence of fast-flux DNS?
• Which logs show evidence of Modify Cloud Compute Infrastructure?