Process
msbuild.exe
msbuild.exe is the Microsoft Build Engine, the tool that compiles and builds .NET projects from XML project files. Developers and build servers use it constantly. Attackers use it as a proxy: because it compiles and runs the code inside a project file, a signed Microsoft binary will execute arbitrary C# straight from a crafted file.
File identity
Not observed.
Not observed.
Not observed.
Not observed.
Execution context
Not observed.
Not observed.
Not observed.
Not observed.
Not observed.
Not observed.
Ancestry
Not observed.
Not observed.
Not observed.
Not observed.
Behavior
Not observed.
Not observed.
Not observed.
Not observed.
msbuild.exe {PATH:.xml}AWL Bypass · Compile and run codemsbuild.exe {PATH:.csproj}Execute · Compile and run codemsbuild.exe /logger:TargetLogger,{PATH_ABSOLUTE:.dll};MyParameters,FooExecute · Execute DLLmsbuild.exe {PATH:.proj}Execute · Execute project file that contains XslTransformation tag parametersmsbuild.exe @{PATH:.rsp}Execute · Bypass command-line based detections
Indicators
Not observed.
Analysis
msbuild.exe builds applications by reading an XML project file (.csproj, .proj, and similar) that describes properties, items, tasks, and targets, then carrying out those tasks. Tasks are units of .NET code, and a project file can define an inline task whose C# source is embedded in the XML and compiled and run as part of the build. It ships with the .NET Framework, so the genuine binary lives under C:\Windows\Microsoft.NET\Framework and Framework64 (and with Visual Studio Build Tools under Program Files), not in System32.
Legitimately, msbuild is run by developers and CI systems against real project files. The project file it is pointed at, and where that file came from, are what give an instance meaning.
msbuild.exe is a trusted-developer-utility proxy (T1127.001). Because a project file can carry an inline task whose C# is compiled and executed during the build, an attacker ships a .csproj or .xml that contains the payload as source and runs msbuild evil.csproj. The signed Microsoft build engine then compiles and runs the code in memory, which sidesteps application-control rules that allow MSBuild and never produces a separate untrusted executable on disk.
Because both the binary and the act of building are legitimate, context is what separates the two: msbuild running where nobody develops software, a project file pulled from a temp or download folder, or an inline task block in that file. A developer build looks nothing like msbuild launched by an Office document.
- Running on a machine with no development or build rolehigh
- A project file in a user-writable path (
Temp,AppData,Downloads)high - A project file containing an inline
<Task>/UsingTaskwith embedded sourcehigh - Parent is an Office application, a script host, or an unfamiliar processhigh
- Outbound network connections or child processes from msbuildhigh
Telemetry
Not observed.
Not observed.