Microsoft Build Engine Started by an Office Application
An instance of MSBuild, the Microsoft Build Engine, was started by an Office application. This is unusual behavior for the Build Engine and could have been caused by a malicious document executing a script payload.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/03/25"
3integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
4maturity = "production"
5updated_date = "2026/04/29"
6
7[rule]
8author = ["Elastic"]
9description = """
10An instance of MSBuild, the Microsoft Build Engine, was started by an Office application. This is unusual behavior for
11the Build Engine and could have been caused by a malicious document executing a script payload.
12"""
13false_positives = [
14 """
15 The Build Engine is commonly used by Windows developers but use by non-engineers is unusual. It is quite unusual for
16 this program to be started by an Office application like Word or Excel.
17 """,
18]
19from = "now-9m"
20index = [
21 "endgame-*",
22 "logs-crowdstrike.fdr*",
23 "logs-endpoint.events.process-*",
24 "logs-m365_defender.event-*",
25 "logs-sentinel_one_cloud_funnel.*",
26 "logs-system.security*",
27 "logs-windows.forwarded*",
28 "logs-windows.sysmon_operational-*",
29 "winlogbeat-*",
30]
31language = "eql"
32license = "Elastic License v2"
33name = "Microsoft Build Engine Started by an Office Application"
34references = ["https://blog.talosintelligence.com/building-bypass-with-msbuild/"]
35risk_score = 73
36rule_id = "c5dc3223-13a2-44a2-946c-e9dc0aa0449c"
37severity = "high"
38tags = [
39 "Domain: Endpoint",
40 "OS: Windows",
41 "Use Case: Threat Detection",
42 "Tactic: Defense Evasion",
43 "Resources: Investigation Guide",
44 "Data Source: Elastic Endgame",
45 "Data Source: Elastic Defend",
46 "Data Source: Windows Security Event Logs",
47 "Data Source: Microsoft Defender XDR",
48 "Data Source: Sysmon",
49 "Data Source: SentinelOne",
50 "Data Source: Crowdstrike",
51]
52timestamp_override = "event.ingested"
53type = "eql"
54
55query = '''
56process where host.os.type == "windows" and event.type == "start" and
57 process.name : "MSBuild.exe" and
58 process.parent.name : ("eqnedt32.exe",
59 "excel.exe",
60 "fltldr.exe",
61 "msaccess.exe",
62 "mspub.exe",
63 "outlook.exe",
64 "powerpnt.exe",
65 "winword.exe" )
66'''
67
68note = """## Triage and analysis
69
70### Investigating Microsoft Build Engine Started by an Office Application
71
72#### Possible investigation steps
73
74- What Office-to-MSBuild path did the alert capture?
75 - Focus: `process.parent.name`, `process.parent.executable`, `process.executable`, and `process.command_line`.
76 - Implication: escalate when Office launches MSBuild from a user-writable path or against a project, response, or import path unrelated to document work; lower suspicion only when the Office parent, working directory, project argument, and user-host pair align to one add-in, template-packaging, or test case.
77- Is the MSBuild binary the expected Microsoft Build Engine instance?
78 - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
79 - Implication: escalate when MSBuild is renamed, unsigned, recently introduced, user-writable, or not signed by the expected Microsoft publisher; lower suspicion when path, original name, signer, and hash history fit the installed Microsoft Build Engine. Identity alone does not clear the Office launch.
80- Do the MSBuild arguments indicate inline-task or staged-project abuse?
81 - Why: MSBuild can execute project-defined tasks, making project or response-file paths the alert-local clue for developer tooling versus payload staging.
82 - Focus: `process.command_line` and same-process file activity for project or response artifacts. $investigate_0
83 - Implication: escalate when arguments point to XML, project, response, or imported files in temp, downloads, archive, cache, mail, or relative paths, or when targets do not fit user compilation; lower suspicion when the same project path, target set, and working directory match a recognized developer or packaging workflow.
84- Does the parent and user context explain this Office-launched build?
85 - Focus: `process.parent.command_line`, `user.id`, `host.id`, and `host.name`.
86 - Implication: escalate when a standard Office user, shared workstation, or unusual parent command line triggers MSBuild without a matching project path and child helper pattern; lower suspicion when `user.id`, `host.id`, parent command line, project path, and child helpers converge on developer packaging or authorized testing.
87- Did MSBuild spawn compiler helpers only, or did it hand off to payload tooling?
88 - Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, then child `process.executable` and `process.command_line`. $investigate_1
89 - Hint: if `process.entity_id` is absent, recover child starts with `host.id` + `process.pid` + a tight alert window; treat the result as weaker than exact lineage.
90 - Implication: escalate when MSBuild launches shells, scripting engines, browsers, LOLBins, installers, or children from unexpected paths; lower suspicion when telemetry shows no child starts or only expected compiler helpers such as csc.exe and cvtres.exe for the same recognized project path. Missing child-process telemetry is unresolved, not benign.
91- If local evidence is suspicious or unresolved, is this part of a broader Office proxy-execution pattern?
92 - Focus: related alerts for the same `user.id`, especially Office-to-script, Office-to-LOLBin, persistence, or credential-access activity. $investigate_2
93 - Hint: check whether the same `host.id` shows Office-launched rundll32.exe, regsvr32.exe, mshta.exe, PowerShell, or suspicious child-process alerts. $investigate_3
94 - Implication: broaden scope and raise priority when either pivot shows related proxy execution or follow-on alerts; keep localized when related alerts are absent and local evidence points to one stable Office parent, MSBuild project path, child helper pattern, and user-host pair.
95
96- Escalate when identity, arguments, parent context, child behavior, or related alerts show abnormal Office-launched MSBuild execution; close only when the same signer, parent command line, project path, child helper pattern, `host.id`, and `user.id` support a recognized workflow with no contradictory findings; preserve evidence and escalate when visibility or answers remain mixed.
97
98### False positive analysis
99
100- Office add-in, template, document-packaging, or controlled testing workflows can legitimately trigger this rule. Confirm from process evidence that `process.executable`, `process.code_signature.subject_name`, the project or response-file pattern in `process.command_line`, `process.parent.executable`, `process.parent.command_line`, child `process.executable`, and the `user.id` plus `host.id` pair align to the same workflow. When telemetry cannot prove purpose, require outside confirmation before closing; use recurrence only after confirmation to judge exception stability.
101- Before creating an exception, validate that the same user-host cohort shows a stable recognized workflow across prior alerts. Keep `process.code_signature.subject_name`, `process.executable`, `process.parent.executable`, the project or response-file pattern in `process.command_line`, `user.id`, and `host.id` stable; allow `process.hash.sha256` changes only when signer, path, and workflow remain consistent with normal updates. Avoid exceptions on `process.name`, Office parent name, or `user.name` alone.
102
103### Response and remediation
104
105- If confirmed benign, reverse temporary containment and record the evidence that validated the workflow: MSBuild signer and path, project-path pattern in `process.command_line`, Office parent context, child-process pattern, and the `user.id` plus `host.id` cohort. Create an exception only after the same pattern recurs consistently across prior alerts.
106- If suspicious but unconfirmed, preserve the alert record, process tree, `process.entity_id`, recovered child entity IDs, `process.command_line`, Office parent command line, and project or response-file paths named in the command line before containment. Apply reversible controls first, such as heightened monitoring, temporary delivery blocks, or endpoint isolation when host criticality allows; avoid process termination or file deletion until lineage and scope are clearer.
107- If confirmed malicious, preserve the same process and project evidence, then contain the affected `host.id` or `user.id` based on the child-process chain, payload handoff, or related alerts. Block confirmed malicious indicators recovered during the case, collect suspicious project or response files before deletion, and terminate malicious processes only after recording their entity IDs and command lines.
108- Eradicate only artifacts tied to the investigated process chain: malicious Office content, MSBuild project or response files, scripts, build outputs, and follow-on payloads identified from child-process execution. Remediate the delivery path that let Office launch the build chain, then scope other `host.id` and `user.id` values for the same project-path pattern or child-process sequence before broader cleanup.
109- Post-incident hardening: restrict Office macro, add-in, and template paths that can invoke developer utilities; retain the process evidence that supported the case; record adjacent Office-launched proxy-execution variants in the case notes for future triage.
110"""
111
112setup = """## Setup
113
114This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
115
116Setup instructions: https://ela.st/install-elastic-defend
117
118### Additional data sources
119
120This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
121
122- [CrowdStrike](https://ela.st/crowdstrike-integration)
123- [Microsoft Defender XDR](https://ela.st/m365-defender)
124- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
125- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
126- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
127"""
128
129[rule.investigation_fields]
130field_names = [
131 "@timestamp",
132 "host.name",
133 "host.id",
134 "user.name",
135 "user.id",
136 "process.entity_id",
137 "process.pid",
138 "process.executable",
139 "process.command_line",
140 "process.pe.original_file_name",
141 "process.working_directory",
142 "process.code_signature.subject_name",
143 "process.code_signature.trusted",
144 "process.parent.executable",
145 "process.parent.command_line",
146]
147
148[transform]
149
150[[transform.investigate]]
151label = "File events for MSBuild process"
152description = ""
153providers = [
154 [
155 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
156 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
157 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
158 ]
159]
160relativeFrom = "now-1h"
161relativeTo = "now"
162
163[[transform.investigate]]
164label = "Child process events for MSBuild"
165description = ""
166providers = [
167 [
168 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
169 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
170 { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
171 ]
172]
173relativeFrom = "now-1h"
174relativeTo = "now"
175
176[[transform.investigate]]
177label = "Alerts associated with the user"
178description = ""
179providers = [
180 [
181 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
182 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
183 ]
184]
185relativeFrom = "now-48h/h"
186relativeTo = "now"
187
188[[transform.investigate]]
189label = "Alerts associated with the host"
190description = ""
191providers = [
192 [
193 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
194 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
195 ]
196]
197relativeFrom = "now-48h/h"
198relativeTo = "now"
199
200[[rule.threat]]
201framework = "MITRE ATT&CK"
202[[rule.threat.technique]]
203id = "T1127"
204name = "Trusted Developer Utilities Proxy Execution"
205reference = "https://attack.mitre.org/techniques/T1127/"
206[[rule.threat.technique.subtechnique]]
207id = "T1127.001"
208name = "MSBuild"
209reference = "https://attack.mitre.org/techniques/T1127/001/"
210
211[rule.threat.tactic]
212id = "TA0005"
213name = "Defense Evasion"
214reference = "https://attack.mitre.org/tactics/TA0005/"
215[[rule.threat]]
216framework = "MITRE ATT&CK"
217[[rule.threat.technique]]
218id = "T1204"
219name = "User Execution"
220reference = "https://attack.mitre.org/techniques/T1204/"
221[[rule.threat.technique.subtechnique]]
222id = "T1204.002"
223name = "Malicious File"
224reference = "https://attack.mitre.org/techniques/T1204/002/"
225
226[rule.threat.tactic]
227id = "TA0002"
228name = "Execution"
229reference = "https://attack.mitre.org/tactics/TA0002/"
Triage and analysis
Investigating Microsoft Build Engine Started by an Office Application
Possible investigation steps
-
What Office-to-MSBuild path did the alert capture?
- Focus:
process.parent.name,process.parent.executable,process.executable, andprocess.command_line. - Implication: escalate when Office launches MSBuild from a user-writable path or against a project, response, or import path unrelated to document work; lower suspicion only when the Office parent, working directory, project argument, and user-host pair align to one add-in, template-packaging, or test case.
- Focus:
-
Is the MSBuild binary the expected Microsoft Build Engine instance?
- Focus:
process.executable,process.pe.original_file_name,process.hash.sha256,process.code_signature.subject_name, andprocess.code_signature.trusted. - Implication: escalate when MSBuild is renamed, unsigned, recently introduced, user-writable, or not signed by the expected Microsoft publisher; lower suspicion when path, original name, signer, and hash history fit the installed Microsoft Build Engine. Identity alone does not clear the Office launch.
- Focus:
-
Do the MSBuild arguments indicate inline-task or staged-project abuse?
- Why: MSBuild can execute project-defined tasks, making project or response-file paths the alert-local clue for developer tooling versus payload staging.
- Focus:
process.command_lineand same-process file activity for project or response artifacts. $investigate_0 - Implication: escalate when arguments point to XML, project, response, or imported files in temp, downloads, archive, cache, mail, or relative paths, or when targets do not fit user compilation; lower suspicion when the same project path, target set, and working directory match a recognized developer or packaging workflow.
-
Does the parent and user context explain this Office-launched build?
- Focus:
process.parent.command_line,user.id,host.id, andhost.name. - Implication: escalate when a standard Office user, shared workstation, or unusual parent command line triggers MSBuild without a matching project path and child helper pattern; lower suspicion when
user.id,host.id, parent command line, project path, and child helpers converge on developer packaging or authorized testing.
- Focus:
-
Did MSBuild spawn compiler helpers only, or did it hand off to payload tooling?
- Focus: child starts where
process.parent.entity_idmatchesprocess.entity_id, then childprocess.executableandprocess.command_line. $investigate_1 - Hint: if
process.entity_idis absent, recover child starts withhost.id+process.pid+ a tight alert window; treat the result as weaker than exact lineage. - Implication: escalate when MSBuild launches shells, scripting engines, browsers, LOLBins, installers, or children from unexpected paths; lower suspicion when telemetry shows no child starts or only expected compiler helpers such as csc.exe and cvtres.exe for the same recognized project path. Missing child-process telemetry is unresolved, not benign.
- Focus: child starts where
-
If local evidence is suspicious or unresolved, is this part of a broader Office proxy-execution pattern?
- Focus: related alerts for the same
user.id, especially Office-to-script, Office-to-LOLBin, persistence, or credential-access activity. $investigate_2 - Hint: check whether the same
host.idshows Office-launched rundll32.exe, regsvr32.exe, mshta.exe, PowerShell, or suspicious child-process alerts. $investigate_3 - Implication: broaden scope and raise priority when either pivot shows related proxy execution or follow-on alerts; keep localized when related alerts are absent and local evidence points to one stable Office parent, MSBuild project path, child helper pattern, and user-host pair.
- Focus: related alerts for the same
-
Escalate when identity, arguments, parent context, child behavior, or related alerts show abnormal Office-launched MSBuild execution; close only when the same signer, parent command line, project path, child helper pattern,
host.id, anduser.idsupport a recognized workflow with no contradictory findings; preserve evidence and escalate when visibility or answers remain mixed.
False positive analysis
- Office add-in, template, document-packaging, or controlled testing workflows can legitimately trigger this rule. Confirm from process evidence that
process.executable,process.code_signature.subject_name, the project or response-file pattern inprocess.command_line,process.parent.executable,process.parent.command_line, childprocess.executable, and theuser.idplushost.idpair align to the same workflow. When telemetry cannot prove purpose, require outside confirmation before closing; use recurrence only after confirmation to judge exception stability. - Before creating an exception, validate that the same user-host cohort shows a stable recognized workflow across prior alerts. Keep
process.code_signature.subject_name,process.executable,process.parent.executable, the project or response-file pattern inprocess.command_line,user.id, andhost.idstable; allowprocess.hash.sha256changes only when signer, path, and workflow remain consistent with normal updates. Avoid exceptions onprocess.name, Office parent name, oruser.namealone.
Response and remediation
- If confirmed benign, reverse temporary containment and record the evidence that validated the workflow: MSBuild signer and path, project-path pattern in
process.command_line, Office parent context, child-process pattern, and theuser.idplushost.idcohort. Create an exception only after the same pattern recurs consistently across prior alerts. - If suspicious but unconfirmed, preserve the alert record, process tree,
process.entity_id, recovered child entity IDs,process.command_line, Office parent command line, and project or response-file paths named in the command line before containment. Apply reversible controls first, such as heightened monitoring, temporary delivery blocks, or endpoint isolation when host criticality allows; avoid process termination or file deletion until lineage and scope are clearer. - If confirmed malicious, preserve the same process and project evidence, then contain the affected
host.idoruser.idbased on the child-process chain, payload handoff, or related alerts. Block confirmed malicious indicators recovered during the case, collect suspicious project or response files before deletion, and terminate malicious processes only after recording their entity IDs and command lines. - Eradicate only artifacts tied to the investigated process chain: malicious Office content, MSBuild project or response files, scripts, build outputs, and follow-on payloads identified from child-process execution. Remediate the delivery path that let Office launch the build chain, then scope other
host.idanduser.idvalues for the same project-path pattern or child-process sequence before broader cleanup. - Post-incident hardening: restrict Office macro, add-in, and template paths that can invoke developer utilities; retain the process evidence that supported the case; record adjacent Office-launched proxy-execution variants in the case notes for future triage.
References
Related rules
- Control Panel Process with Unusual Arguments
- IIS HTTP Logging Disabled
- Proxy Execution via Console Window Host
- Proxy Execution via Windows OpenSSH
- Suspicious Microsoft HTML Application Child Process