Execution of File Written or Modified by Microsoft Office

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Execution of File Written or Modified by Microsoft Office

Identifies an executable created by a Microsoft Office application and subsequently executed. These processes are often launched via scripts inside documents or during exploitation of Microsoft Office applications.

Rule type: eql

Rule indices:

logs-endpoint.events.process-*
logs-endpoint.events.file-*
endgame-*

Severity: high

Risk score: 73

Runs every: 60m

Searches indices from: now-120m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References: None

Tags:

Domain: Endpoint
OS: Windows
Use Case: Threat Detection
Tactic: Execution
Resources: Investigation Guide
Data Source: Elastic Endgame
Data Source: Elastic Defend

Version: 115

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Execution of File Written or Modified by Microsoft Office

Possible investigation steps

Which source events matched the Office write-to-execute sequence?
Why: this sequence can merge fields from different file and process events, so source events are the evidence for writer and executed-process identity.
Focus: open Investigate in Timeline for the alert window on the same host; compare written file.path with executed process.executable, then record source process.name, process.entity_id, and stable user.id.
Implication: escalate when Office creates an executable that later starts from the same path; lower suspicion when the recovered sequence resolves to a recognized signed add-in or helper updater in a controlled product tree. Signed Microsoft NewOutlookInstaller.exe and Citrix ShareFileForOutlook helpers are excluded, so a generic updater label is not closure.
Is the Office writer the expected Office component and parent context?
Focus: writer process.executable, signer/trust, process.parent.executable, and process.parent.command_line.
Implication: escalate when WINWORD.EXE, EXCEL.EXE, OUTLOOK.EXE, POWERPNT.EXE, MSPUB.EXE, MSACCESS.EXE, eqnedt32.exe, or fltldr.exe is renamed, untrusted, user-writable, or launched by an unusual parent; lower suspicion when writer path, signer, and parent chain match the user’s recognized Office integration. Writer identity never clears the executed file by itself.
Does the written executable look staged for payload delivery?
Focus: file.path, original path/extension, file.Ext.header_bytes, file.Ext.windows.zone_identifier, and same-host file activity on the written path. !{investigate{"description":"","label":"File events for the written executable path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}}
Implication: escalate for Temp, Downloads, AppData, mail cache, startup, unrelated product paths, Internet Zone evidence, or executable content after rename; lower suspicion when the artifact stays in a recognized add-in or update tree and path history fits that workflow.
Does the executed file’s identity and command line fit the same workflow?
Focus: executed process.executable, process.hash.sha256, signer, process.command_line, and process.Ext.relative_file_creation_time.
Hint: use prior endpoint process starts or related alerts for process.hash.sha256 only after identity and command line fit the suspected workflow. !{investigate{"description":"","label":"Alerts associated with the executed file hash","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
Implication: escalate when the executable is newly created, unsigned, user-writable, mismatched to signer or path, or launched with script, LOLBin, unpacking, or self-extracting arguments; lower suspicion only when signer, hash history, path, age, and arguments all fit the same recognized helper workflow.
What document, email, archive, or integration source caused Office to write the executable?
Focus: file events from writer process.entity_id; review file.path, file.origin_url, file.origin_referrer_url, and file.Ext.windows.zone_identifier.
Hint: if records are incomplete or the entity pivot returns none, use the same host, writer process.pid, and tight write-time window.
Implication: escalate when the write follows a downloaded document, email attachment, archive extraction, or web referrer outside the same recognized workflow; lower suspicion when provenance points to a recognized deployment package or Office integration source. Missing provenance is inconclusive, not benign.
Did the executed file produce malicious follow-on process or file activity?
Focus: process and file events scoped to executed process.entity_id: child process.parent.entity_id, child process.command_line, and new file.path values.
Hint: if records are incomplete or the entity pivot returns none, use the same host, executed process.pid, and post-start window.
Implication: escalate when the payload launches script interpreters, LOLBins, unpackers, or additional binaries, or stages files outside the recognized product tree; lower urgency when follow-on activity stays limited to expected local install or update actions. Preserve Office-written DLLs, scripts, or shortcut launchers in the same scope as adjacent payload variants.
If local findings remain suspicious or unresolved, do related alerts show the same delivery chain or spread?
Focus: related alerts for host.id, then pivot on recovered stable user.id; prioritize document delivery, script execution, persistence, and outbound connection alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
Implication: broaden scope when related alerts connect the same host or user to delivery, scripting, persistence, or beaconing; keep scope local when the sequence is isolated and local evidence supports one recognized workflow.
Escalate when sequence, artifact, identity, delivery, behavior, or related-alert evidence supports suspicious Office write-to-execute activity; close only when all categories align with one recognized add-in, updater, or integration workflow and no contradictory artifacts remain; if evidence is mixed or incomplete, preserve artifacts and escalate.

False positive analysis

Office add-in, repair, updater, document-management, e-signature, DLP, or collaboration integrations can write and launch helper executables. Confirm that writer identity, written path, executed hash or signer, parent context, provenance, command line, and follow-on activity all point to the same product or integration workflow. If records are unavailable, require telemetry-only recurrence of the same writer, path tree, signer/hash pattern, and host.id or user.id cohort across prior alerts.
Before creating an exception, validate that the same Office writer, path tree, executed signer or process.hash.sha256, provenance pattern, and host.id/user.id cohort recur across prior alerts from this rule. Build the exception from that minimum workflow pattern; avoid exceptions on Office process names, process.name, or file.extension alone.

Response and remediation

If confirmed benign, reverse temporary containment and document the writer identity, written path tree, executed hash and signer, parent/delivery context, and recurrence evidence. Create an exception only for the same stable workflow pattern.
If suspicious but unconfirmed, preserve Timeline source events, copies of the written executable and source document/archive, process tree details, recovered entity IDs, command line, hash, path, and provenance URLs before containment. Apply reversible containment first: quarantine the lure or executable, block the confirmed hash/path temporarily where controls support it, or increase monitoring on the affected host.id and user.id. Isolate the host only if follow-on process/file evidence shows malicious staging or execution and the host can tolerate interruption.
If confirmed malicious, isolate the host and terminate the executed payload after preserving the source events, process tree, written executable, lure document or archive, hash, signer, and provenance evidence. Block the confirmed hash or path where controls support it, then remove the malicious executable, lure, archive, and staged files identified during the investigation.
Review related hosts and users for the same written path pattern, executed hash, signer, and provenance evidence before deleting artifacts. Then remediate the delivery path, such as the phishing message, archive, or malicious Office document, that led to the write-execute sequence.
Post-incident hardening: restrict Office-driven writes and launches of executable content in user-writable paths, retain endpoint file-provenance and process-start telemetry, and record confirmed adjacent variants, such as Office-written DLLs, scripts, or shortcut launchers, in the case history for future triage.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Rule query

edit

sequence with maxspan=2h
  [file where host.os.type == "windows" and event.type != "deletion" and file.extension : "exe" and
    process.name : (
      "WINWORD.EXE", "EXCEL.EXE", "OUTLOOK.EXE", "POWERPNT.EXE",
      "eqnedt32.exe", "fltldr.exe", "MSPUB.EXE", "MSACCESS.EXE"
    )
  ] by host.id, file.path
  [process where host.os.type == "windows" and event.type == "start" and
   not (process.name : "NewOutlookInstaller.exe" and process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true) and
   not (process.name : "ShareFileForOutlook-v*.exe" and process.code_signature.subject_name : "Citrix Systems, Inc." and process.code_signature.trusted == true)
  ] by host.id, process.executable

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Execution
- ID: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: Exploitation for Client Execution
- ID: T1203
- Reference URL: https://attack.mitre.org/techniques/T1203/
Technique:
- Name: User Execution
- ID: T1204
- Reference URL: https://attack.mitre.org/techniques/T1204/
Sub-technique:
- Name: Malicious File
- ID: T1204.002
- Reference URL: https://attack.mitre.org/techniques/T1204/002/
Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
Technique:
- Name: Phishing
- ID: T1566
- Reference URL: https://attack.mitre.org/techniques/T1566/
Sub-technique:
- Name: Spearphishing Attachment
- ID: T1566.001
- Reference URL: https://attack.mitre.org/techniques/T1566/001/
Sub-technique:
- Name: Spearphishing Link
- ID: T1566.002
- Reference URL: https://attack.mitre.org/techniques/T1566/002/

« WPS Office Exploitation via DLL Hijack Suspicious Execution with NodeJS »