Defenders should treat Excel.exe as suspicious when it opens documents and then spawns unusual child processes, especially scripts, command shells, or network-connected loaders. Monitor for macro-enabled files, abnormal add-ins, and unexpected external connections. Correlate document origin, process tree, and file writes, because Excel is commonly abused to launch malicious code or stage payloads.
What Excel.exe abuse looks like in telemetry
The most reliable signal is not “Excel is open,” but Excel behaving like a launcher. Defenders should look for document opens followed by child processes that Excel does not normally need, especially living off the land binaries, command shells, script hosts, or download-and-execute behavior. That process-chain view is usually stronger than any single alert because malicious use often starts with a legitimate spreadsheet and then pivots into execution.
Process ancestry matters because attackers frequently hide in routine user activity. A spreadsheet that spawns PowerShell, cmd.exe, wscript.exe, mshta.exe, rundll32.exe, or a network-enabled loader deserves much more scrutiny than a spreadsheet that simply opens a workbook and exits. Correlating parent process, command line, loaded add-ins, and network activity helps distinguish normal office automation from staging and execution.
File context is equally important. Macro-enabled files, unexpected external references, newly dropped files in temp locations, and repeated writes to user-writable paths can indicate that Excel is being used to stage code rather than perform document work. When those writes are followed by execution, defenders should treat the chain as a probable intrusion path, not an isolated office artifact.
How to separate normal Excel automation from malicious execution
Not every child process is bad. Excel can legitimately interact with other processes through add-ins, automation, or enterprise integrations, so the question is whether the behavior matches the workstation’s normal baseline. MITRE ATT&CK Enterprise Matrix is useful here because it helps defenders map suspicious Office spawning behavior to known execution and defense-evasion patterns instead of treating every anomaly as equal.
Focus on combinations rather than single indicators. A trusted business document that triggers a script host, reaches out to an unfamiliar domain, and then writes an executable or script to disk is much more suspicious than any one of those events alone. If the same user, host, or mailbox repeatedly generates that pattern, the case for malicious use becomes stronger.
Network telemetry can sharpen the distinction. Excel rarely needs to make unusual outbound connections to unknown hosts, and it should not normally act as the first process in a chain that fetches payloads from the internet. Watch for DNS lookups, HTTP or HTTPS requests, and proxy events that line up with the document open and the subsequent child-process start.
What defenders should hunt for first
Start with macro-enabled documents, unexpected add-ins, and suspicious command lines because they give the fastest path to confirmation. Then pivot to process trees, file-system writes, and network connections so you can see whether the activity stayed inside Excel or turned into a broader execution chain. The most useful hunts are the ones that connect document origin, process creation, and post-launch behavior into one timeline.
For teams building detections, the highest-value rule is often simple: alert when Excel spawns a shell, script interpreter, or LOLBin and the parent document is not part of a known business workflow. The Living off the Land Guide is a good reference for the tool classes attackers commonly abuse after a spreadsheet foothold.
Risk and Threat Considerations
Excel is attractive to attackers because it sits inside normal business workflow, so malicious activity can blend into routine document handling. The main risk is that a benign-looking spreadsheet becomes the launch point for code execution, payload staging, credential theft, or later movement inside the endpoint and beyond.
Failure mechanism: A malicious workbook, add-in, or embedded object causes Excel to invoke an unexpected child process or fetch an external payload, turning document trust into execution trust.
Impact: Defenders may miss the initial compromise if they only monitor the document and not the follow-on process tree, allowing the attacker to run code, persist, or expand access from a trusted office application.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Excel abuse often leads to script or shell execution. |
| T1204 — User Execution | Malicious Excel commonly relies on a user opening a weaponized document. | |
| T1105 — Ingress Tool Transfer | Excel-launched activity often fetches payloads after initial execution. | |
| Recommendation — Map Excel-spawned shells and script hosts to T1059 and hunt the parent-child chain. Correlate document opens and follow-on execution to validate T1204-style activity. Inspect outbound connections and downloads for tool-transfer behavior after Excel starts. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitor for Unauthorized Personnel, Connections, Devices, and Software | Detecting suspicious Excel behavior depends on endpoint and process monitoring. |
| DE.AE-01 — Anomalies and Events Are Analyzed | Excel abuse is identified by correlating document, process, and network anomalies. | |
| Recommendation — Instrument endpoint monitoring to spot anomalous Excel process trees and connections. Analyze suspicious Office process chains together instead of treating each alert separately. | ||
Practitioner Guidance
What to verify: Confirm whether the Excel process tree matches an approved business pattern, including the document source, macro status, add-ins, child processes, and outbound destinations. If any one of those elements is unexplained, treat the event as suspicious until you can account for it.
Decision rule: If Excel launches a script host, shell, or downloader and the workbook is not from a known trusted workflow, prioritise containment and triage over trying to explain the user action first. If the same pattern appears across multiple hosts, treat it as a hunt lead rather than a one-off alert.
Practitioner takeaway: The strongest detections tie Excel to what it does next, not just to the file it opened, because malicious use usually becomes visible at process creation, network activity, and file writes rather than at launch.