T1127.001: MSBuild
Adversaries may use MSBuild to proxy execution of code through a trusted Windows utility. MSBuild.exe (Microsoft Build Engine) is a software build platform used by Visual Studio. It handles XML formatted project files that define requirements for loading and building various platforms and configurations.[1]
Adversaries can abuse MSBuild to proxy execution of malicious code. The inline task capability of MSBuild that was introduced in .NET version 4 allows for C# or Visual Basic code to be inserted into an XML project file.[1][2] MSBuild will compile and execute the inline task. MSBuild.exe is a signed Microsoft binary, so when it is used this way it can execute arbitrary code and bypass application control defenses that are configured to allow MSBuild.exe execution.[3]
Analyst context for executives and security teams
MSBuild matters because it is a trusted Microsoft-signed developer utility that can be abused to run code from XML project files. For business leaders, the risk is not that MSBuild is inherently malicious, but that controls which simply trust Microsoft binaries or developer tools may allow unwanted execution to blend into normal Windows activity.
Executive priority
Prioritize this where Windows endpoints include developer tooling, build systems, or broadly allowed Microsoft-signed binaries. Leaders should ask whether application control policy treats MSBuild as universally trusted, whether SOC teams can distinguish legitimate build activity from unusual execution, and whether incident responders can quickly identify where MSBuild is expected versus anomalous. This is relevant to execution control, stealth reduction, audit evidence for application control, and business continuity on developer and production-adjacent Windows systems.
Technical view
T1127.001 is a Windows sub-technique of Trusted Developer Utilities Proxy Execution under execution and stealth. ATT&CK states that adversaries may abuse MSBuild.exe to compile and execute inline C# or Visual Basic code embedded in XML project files, potentially bypassing application control that permits MSBuild.exe. Official ATT&CK detection text is not provided, but the relationship to DET0556 indicates a behavior-chain detection strategy exists. SOC and detection teams should validate MSBuild process execution context, project/XML inputs, parent and child process relationships, and whether execution occurs on hosts or accounts where build activity is expected.
Likely telemetry
- Windows process creation telemetry for MSBuild.exe, including command line and parent process context
- File telemetry for XML/project files used as MSBuild inputs
- Child process and module/load activity associated with MSBuild execution
- Application control, script blocking, or execution prevention logs showing allowed or blocked MSBuild activity
- Endpoint detection telemetry that can correlate MSBuild execution with subsequent code execution behavior
Detection direction
- Baseline legitimate MSBuild usage by host role, user, parent process, and working directory before alerting broadly.
- Tune for MSBuild execution on non-developer or non-build Windows systems, unusual parent processes, unusual project file locations, or unexpected child activity.
- Correlate behavior chains rather than relying only on the signed status of MSBuild.exe, consistent with the DET0556 relationship.
- Review false positives from normal software development, CI/build operations, and administrative maintenance.
- Validate whether current telemetry captures command line, file path, parent/child process, and application-control decisions; without these, coverage may be weak.
Mitigation priorities
- Use execution prevention controls, aligned to M1038, to restrict unauthorized code execution rather than trusting MSBuild solely because it is Microsoft-signed.
- Where MSBuild is not required, reduce attack surface by disabling or removing unnecessary features or programs, aligned to M1042.
- Segment policy by role: developer and build systems may need MSBuild, while general workstations and servers often should not have the same allowance.
- Maintain evidence of approved MSBuild usage and exceptions for audit, incident response scoping, and control validation.
- Test application control policies against trusted developer utility abuse scenarios to confirm that intended restrictions apply in practice.
Analyst notes and limits
ATT&CK links this technique to campaigns Frankenstein and Operation AkaiRyū and to software including PlugX, Empire, and NOOPLDR. These relationships show the behavior has appeared in documented ATT&CK reporting, but they should not be interpreted as evidence of current activity in any specific environment. The key defensive question is whether MSBuild execution is expected, observable, and governed on Windows systems.
The official ATT&CK object provides no specific detection procedure, so detection guidance here is derived from the technique description, platforms, tactics, and stated relationships. Local asset roles, developer workflows, application control design, and endpoint logging quality are required to determine actual risk and coverage.
MSBuild
Adversaries may use MSBuild to proxy execution of code through a trusted Windows utility. MSBuild.exe (Microsoft Build Engine) is a software build platform used by Visual Studio. It handles XML formatted project files that define requirements for loading and building various platforms and configurations.[1]
Adversaries can abuse MSBuild to proxy execution of malicious code. The inline task capability of MSBuild that was introduced in .NET version 4 allows for C# or Visual Basic code to be inserted into an XML project file.[1][2] MSBuild will compile and execute the inline task. MSBuild.exe is a signed Microsoft binary, so when it is used this way it can execute arbitrary code and bypass application control defenses that are configured to allow MSBuild.exe execution.[3]
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1127 | Trusted Developer Utilities Proxy Execution | This object subtechnique of Trusted Developer Utilities Proxy Execution. |
Groups, software, and campaigns
S9025: NOOPLDR
NOOPLDR is a shellcode loader with XML/C# and DLL versions that has been used by MirrorFace to load HiddenFace.[1]
S0013: PlugX
S0363: Empire
Empire is an open-source, cross-platform remote administration and post-exploitation framework that is publicly available on GitHub. While the tool itself is primarily written in Python, the post-exploitation agents are written in pure PowerShell for Windows and Python for Linux/macOS. Empire was one of five tools singled out by a joint report on public hacking tools being widely used by adversaries.[1][2][3]
C0060: Operation AkaiRyū
Operation AkaiRyū (Japanese for RedDragon) was a cyberespionage spearphishing campaign conducted by MirrorFace between June and September 2024 against entities in Japan and Central Europe. Operation AkaiRyū notably included the first reported targeting of a European entity by MirrorFace, as well as their use of UPPERCUT, which was thought to be exclusive to menuPass.[1][2]
C0001: Frankenstein
Frankenstein was described by security researchers as a highly-targeted campaign conducted by moderately sophisticated and highly resourceful threat actors in early 2019. The unidentified actors primarily relied on open source tools, including Empire. The campaign name refers to the actors' ability to piece together several unrelated open-source tool components.[1]
All related ATT&CK context
Mitigation direction
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 | 2.0 | Current bundle | 56239ed9552c… |
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]
MSDN MSBuild
Microsoft. (n.d.). MSBuild1. Retrieved November 30, 2016.
Open source URL -
[2]
Microsoft MSBuild Inline Tasks 2017
Microsoft. (2017, September 21). MSBuild inline tasks. Retrieved March 5, 2021.
Open source URL -
[3]
LOLBAS Msbuild
LOLBAS. (n.d.). Msbuild.exe. Retrieved July 31, 2019.
Open source URL -
[4]
mitre-attack T1127.001Open 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.