Detect it by alerting when Microsoft Office applications spawn shells, scripts, downloaders, or other non-document processes on macOS. Office should normally open files, not launch command interpreters or helper binaries that reach the network. Investigate the document source, macro or script execution, and whether the child process is consistent with approved automation or add-ins.
What suspicious Office child processes look like on macOS
On macOS, the signal is not that Microsoft Office starts a child process, but that it starts the wrong kind of child process. Normal document handling stays within Office or the expected document viewer path. Suspicious behavior appears when Word, Excel, or PowerPoint launches shells, script interpreters, downloaders, archive tools, or other utility binaries that are not needed to open the document.
That distinction matters because Office is often the parent process that malware uses to bridge from a user-opened document into code execution. A useful detection rule is to watch for Office spawning processes such as sh, bash, zsh, osascript, Python, Perl, Ruby, curl, wget, curl-like downloaders, or other non-document helpers, especially when the child process then reaches the network or launches additional children.
Context is essential. A child process is more suspicious when it appears immediately after a document open, comes from an attachment, SharePoint, email, or downloaded file, or is inconsistent with approved automation, add-ins, or managed macros. If the same activity occurs from a known business workflow, you still want telemetry, but you may tune the alert differently than for an unknown document source.
Process lineage and document context are the core detection signals
Use process lineage to answer two questions: did Office start the process, and did that process behave like code execution instead of document rendering? A child process alone is not enough. Pair parent-child telemetry with file provenance, quarantine status, user action, and whether the document was expected to invoke any helper logic. For a broader macOS hunting playbook, the macOS Detection and Response Guide provides the telemetry patterns that usually separate normal activity from malware tradecraft.
Look for chains, not just single events. Office launching a shell that then downloads a payload, writes a file, marks it executable, or spawns another interpreter is much higher risk than Office opening a local document helper. If your tooling supports it, correlate parent process, child process, command line, working directory, file hash, and network destination so you can distinguish a legitimate add-in from a staged execution chain.
On macOS, process names are not enough on their own because adversaries can rename binaries or embed scripts inside seemingly benign wrappers. The more reliable triage path is to combine process ancestry, code-signing status, launch arguments, and the file path of the parent document. That gives you a practical way to separate document-centric behavior from an execution chain that Office should never have started.
How to tune the alert so it stays useful
The best alerting logic is usually allowlist-first, not blocklist-only. Start by defining the small set of Office child processes that are expected in your environment, then alert on everything else. That lets you preserve approved automation while still catching suspicious launch patterns from Office apps.
Make the rule more specific by adding behavior constraints. Prioritise child processes that invoke a shell or script engine, use unusual command lines, access temporary directories, contact external hosts, or spawn further children. If you also monitor the document origin, give higher severity to documents opened from email, browser downloads, or untrusted collaboration channels than to files from managed internal repositories.
For Microsoft 365 environments, it is also worth mapping the event back to the surrounding tenant and endpoint controls. Microsoft 365 Security Guide is useful for understanding how audit logs, Defender controls, and app-consent decisions can help you decide whether the activity is a real compromise path or an approved workflow.
If you need a general detection baseline, NIST’s Cybersecurity Framework 2.0 aligns well with this use case because the problem spans detection, response, and recovery, not just process monitoring. The practical goal is to catch suspicious execution early enough to contain the endpoint before a document-delivered payload expands its foothold.
Risk and Threat Considerations
Suspicious Office child processes are a common sign that a document has crossed from content handling into code execution. That creates exposure because the user’s trust in the document becomes a launch path for payload delivery, credential theft, persistence, or lateral movement, especially when the child process can access the network or user context.
Failure mechanism: A malicious or compromised document abuses Office as the initial parent process, then launches a shell, script engine, or downloader to execute attacker-controlled logic outside normal document handling.
Impact: The endpoint may move from a single suspicious document open to full compromise, with download, persistence, and follow-on activity that is harder to detect once the child process is already running.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Detecting abnormal Office child processes depends on continuous endpoint monitoring. |
| DE.AE-01 — Anomalies and events are detected and analyzed | Suspicious Office children are endpoint anomalies that require analysis for malicious execution. | |
| Recommendation — Monitor Office process trees and flag anomalous child-process behavior for investigation. Analyze Office-spawned shells and downloaders as anomalous execution events. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Process lineage and command-line telemetry must be reviewed to spot suspicious child processes. |
| SI-4 — System Monitoring | Endpoint monitoring is required to detect malicious child processes launched by Office. | |
| Recommendation — Review endpoint audit records for Office parent-child process chains and suspicious command lines. Deploy monitoring that detects Office spawning interpreters, shells, or downloaders. | ||
| MITRE ATT&CK | T1204 — User Execution | Office child-process abuse commonly starts when a user opens a weaponized document. |
| T1059 — Command and Scripting Interpreter | Shells and script engines spawned by Office are the core suspicious behavior described. | |
| Recommendation — Hunt for Office process trees that begin after user-opened documents or attachments. Alert when Office launches command interpreters or script engines on macOS. | ||
Practitioner Guidance
What to verify: Confirm whether the child process was spawned by a genuine Office application, whether the document source was trusted, and whether the command line matches an approved macro, add-in, or automation path. If any of those are unclear, treat the event as suspicious rather than assuming it is benign.
Decision rule: If the child process is a shell, script interpreter, downloader, or any binary whose job is not document rendering, escalate immediately. If it is an approved helper, require an allowlist entry tied to a specific business workflow, not a broad process-name exception.
Common mistake: Teams often alert only on obviously malicious filenames or macro flags and miss the process chain that follows. The child process is often the stronger indicator, because attackers can hide the document itself while using Office to start the real payload.
Practitioner takeaway: The most reliable signal is not “Office spawned something,” but “Office spawned something it should never need to open a document.” Build detections around lineage, behavior, and document origin, then keep a small, explicit exception set for known automation.
Related resources from NHI Mgmt Group
- How do you detect malicious child processes spawned by Microsoft Office applications?
- How do you detect suspicious Java child processes on Linux?
- What should you monitor to detect suspicious device activity in Microsoft Entra ID?
- How do you detect Microsoft 365 activity from anonymous or suspicious IP addresses?