AN1535: Analytic 1535
MSBuild.exe is invoked outside expected developer/build contexts or with anomalous arguments (e.g., non-canonical paths, remote shares, Base64/obfuscated property values). Within a short window, it (a) spawns high-risk LOLBins/script interpreters, (b) writes new PE/DLL/script artifacts into user-writable paths and executes them, (c) loads unsigned/user-writable modules, (d) performs memory injection/thread creation into other processes, and/or (e) initiates outbound network connections.
Analyst context for executives and security teams
This analytic focuses on suspicious use of MSBuild.exe on Windows when it appears outside normal developer or build activity and is followed by behaviors such as launching scripting tools, writing and executing files in user-writable locations, loading unsigned modules, injecting into other processes, or making outbound network connections. For leaders, the value is not just spotting MSBuild itself, but validating whether the organization can distinguish legitimate software build activity from abuse of a trusted Windows build utility.
Executive priority
Prioritize this where Windows endpoints include developer workstations, build servers, engineering environments, or any systems where trusted Microsoft tooling could be misused and overlooked. The business decision is whether SOC and IR teams have enough endpoint, process, file, module, memory, and network evidence to investigate suspicious MSBuild activity quickly without disrupting legitimate development operations. This also supports audit and resilience conversations around monitoring of living-off-the-land binaries and control coverage on user-writable execution paths.
Technical view
Validate detections around MSBuild.exe execution on Windows when it occurs outside expected developer or build contexts, from non-canonical paths, remote shares, or with unusual/obfuscated arguments such as Base64-like property values. Correlate MSBuild process starts with short-window follow-on behaviors: spawning LOLBins or script interpreters, creating PE/DLL/script artifacts in user-writable paths and executing them, loading unsigned or user-writable modules, process injection or remote thread creation, and outbound network connections. Because no ATT&CK detection text or relationship context is supplied, local baselining of legitimate MSBuild usage is essential.
Likely telemetry
- Windows process creation events including command line, parent process, executable path, user, host, and working directory
- File creation and execution telemetry for PE, DLL, and script artifacts in user-writable paths
- Module load telemetry, especially unsigned modules or modules loaded from user-writable locations
- Endpoint memory behavior telemetry for process injection or thread creation into other processes
- Network connection telemetry tied to MSBuild.exe process identity
Detection direction
- Baseline approved MSBuild locations, expected parent processes, developer/build hosts, service accounts, and normal command-line patterns before alerting broadly.
- Tune for suspicious context: MSBuild launched from remote shares or non-canonical paths, unusual properties, obfuscated/Base64-like arguments, or unexpected parents.
- Correlate MSBuild execution with high-risk child processes, file writes plus execution, unsigned/user-writable module loads, injection/thread creation, or outbound connections in a short time window.
- Separate developer/build pipeline noise from unusual endpoint activity; false positives are likely if normal software build workflows are not modeled.
- Check for blind spots where command-line logging, module loads, process injection telemetry, or process-to-network attribution are unavailable.
Mitigation priorities
- Inventory legitimate MSBuild usage across Windows endpoints, build systems, and developer environments.
- Restrict or monitor execution from user-writable paths and remote shares where operationally feasible.
- Apply least privilege and application control policies for systems that should not run developer/build tooling.
- Ensure endpoint logging captures process command lines, file activity, module loads, memory behavior, and network connections with process attribution.
- Prepare IR triage playbooks for suspicious MSBuild activity, including collection of command line, parent/child process tree, written artifacts, loaded modules, and outbound destinations.
Analyst notes and limits
The supplied object is a detection analytic for Windows MSBuild.exe behavior. No ATT&CK tactic, technique relationships, groups, software, campaigns, mitigations, or official detection logic were supplied. Treat this as a behavioral detection validation topic rather than a complete ATT&CK technique assessment.
This take is based only on the official STIX fields provided. It does not establish active exploitation, attribution, prevalence, impact, or guaranteed detection coverage. Local environment baselines are required to determine what MSBuild behavior is expected versus suspicious.
Analytic 1535
MSBuild.exe is invoked outside expected developer/build contexts or with anomalous arguments (e.g., non-canonical paths, remote shares, Base64/obfuscated property values). Within a short window, it (a) spawns high-risk LOLBins/script interpreters, (b) writes new PE/DLL/script artifacts into user-writable paths and executes them, (c) loads unsigned/user-writable modules, (d) performs memory injection/thread creation into other processes, and/or (e) initiates outbound network connections.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | a58d9b7ba7f7… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1535Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.