How do you detect malicious child processes spawned by Microsoft Office applications?

What makes child-process monitoring effective for Office?

Office child-process telemetry is useful because the abuse is often visible at the process boundary before it becomes obvious in network or endpoint signals. A Word or Excel document normally should not need to launch cmd.exe, powershell.exe, mshta.exe, script hosts, or downloaders to display content. That makes parent-child relationships a strong first-pass indicator, especially when combined with document origin and macro activity.

The practical goal is not to block every child process, but to separate document-initiated workflows from execution paths that create code execution, staging, or persistence opportunities. That means looking at which Office application launched the child, what the child did next, and whether the execution was consistent with a legitimate add-in, automation workflow, or embedded object.

For defenders, this is most valuable when the telemetry preserves the full chain, not just an alert on a single process name. A chain such as Office opening a document, spawning a scripting host, and then launching a network-capable utility is much more informative than any one event in isolation.

Which Office behaviors should raise suspicion?

The highest-value signals are Office spawning dual-use tooling that sits far outside normal document rendering. That includes shells, scripting engines, HTML application hosts, PowerShell, and other utilities that can execute commands, fetch payloads, or decode embedded content. The Living off the Land Guide is useful here because many malicious Office chains rely on trusted binaries rather than obvious malware.

It is also important to watch for Office starting a process that immediately opens a remote URL, writes a file to a user-writable path, or spawns another child process in a short sequence. Those patterns often indicate staged execution rather than a benign document feature. If the document arrived by email or download, treat the file origin as part of the detection context, not as separate enrichment.

Macros, add-ins, embedded objects, and template abuse matter because they provide the execution path that lets Office launch the next stage. If those features were present and the resulting child process is not clearly tied to a sanctioned business workflow, the chain deserves escalation even when the parent process itself is a trusted Microsoft application.

How do you reduce false positives without missing real abuse?

Good detection uses context, not just process names. Review whether the Office parent was a user-initiated local document open, whether the file came from an untrusted source, whether the child process is consistent with approved automation, and whether the endpoint has known productivity tooling that legitimately uses scripting or helper binaries. The Persistence Techniques Guide helps distinguish one-off document abuse from chains that are trying to establish lasting access after initial execution.

Allowlisting should be narrow and explicit. If a business unit truly depends on Office launching a helper binary, that approval should be documented, scoped to the specific host group or application path, and monitored for drift. Otherwise, broad exceptions create blind spots that attackers can reuse with minimal modification.

Also look for repetition. A single suspicious child process may be noisy, but repeated Office-to-shell or Office-to-script launches across multiple hosts, users, or documents is a stronger indicator of malicious tradecraft than one isolated event.

Risk and Threat Considerations

Office spawning child processes is risky because it turns a trusted productivity application into a launchpad for code execution, staging, and follow-on compromise. Attackers often abuse this trust boundary to hide malicious activity inside normal user workflows, where defenders are less likely to treat the parent process as hostile.

Failure mechanism: The detection fails when telemetry is too shallow to preserve parent-child chains, when child-process rules are too broad or too narrow, or when approved business exceptions are not governed tightly enough to distinguish legitimate automation from abuse.

Impact: Missed Office-originated execution can lead to payload delivery, lateral movement, credential theft, or persistence, especially when the spawned process is a script host or shell that can extend the compromise beyond the original document.

Practitioner Guidance

What to verify: Confirm that your telemetry captures the Office parent, full command line, document source, and child tree. If you cannot reconstruct the chain after the fact, the control is too weak for reliable investigation.

Decision rule: Treat Office spawning shells or scripting engines as suspicious by default, then downgrade only when the document, user action, and process path clearly match a documented business use. If any of those three are missing, keep the alert open.

What good looks like: Analysts can quickly answer four questions from the event stream: which Office app launched it, what child process started, what document triggered it, and whether the behavior matches an approved workflow. That is the difference between useful detection and generic noise.

Practitioner takeaway: The best detections do not rely on “Office is trusted” or “the process name looks bad” alone, they preserve the execution chain so you can judge whether the child process is a legitimate document helper or an attacker’s next stage.

Related resources from NHI Mgmt Group

• Guide: Endpoint Security Guide
• How do you detect applications using the ROPC authentication flow in Microsoft Entra ID?
• How do you detect sign-ins from malicious IP addresses in Microsoft Entra ID?
• How do you detect applications assigned to privileged Azure RBAC or Microsoft Entra roles?
• How do you detect new owners being added to Microsoft Entra applications?