Listen to this Post
Introduction:
Living Off the Land Binaries (LOLBins) are legitimate Windows executables that attackers repurpose to evade security tools. MSBuild.exe, a core component of the .NET Framework used to compile code, has become a powerful vector for fileless malware execution—running malicious C code directly in memory without writing a single malicious file to disk, all while carrying Microsoft’s own digital signature that bypasses most antivirus engines.
Learning Objectives:
- Understand how MSBuild.exe automatically compiles and executes malicious .csproj files from the same directory, enabling fileless attacks.
- Learn to detect MSBuild abuse using Sysmon, PowerShell, and behavioral rules (network connections, file paths).
- Implement mitigation strategies including AppLocker, WDAC, and endpoint detection rules to block LOLBin-based evasion techniques.
You Should Know:
- How MSBuild.exe Executes Fileless Malware Without Admin Rights
MSBuild.exe is designed to compile C project files (.csproj) into executables. When launched without a project file argument, it scans its own directory for any .csproj file and automatically loads and compiles it. The compiled code runs entirely in memory, leaving minimal artifacts on disk. No administrator rights are required, and Windows Defender does not flag the process because MSBuild.exe is signed by Microsoft.
Step-by-step breakdown of the attack:
- Attacker crafts a malicious .csproj file containing embedded C code (e.g., reverse shell, downloader, or PlugX loader).
- Phishing email delivers a ZIP archive containing two files: a decoy document (e.g., “Meeting_Invitation.pdf.lnk” or a legitimate signed executable) and the .csproj file.
- Victim opens the decoy, which triggers MSBuild.exe (often via a shortcut or document macro). MSBuild.exe automatically finds and compiles the adjacent .csproj file.
- The malicious code executes in memory, connects to a C2 server, and downloads additional payloads without ever writing a traditional malware executable to disk.
Example malicious .csproj snippet (simplified):
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <Target Name="Execute"> <Exec Command="powershell -EncodedCommand JABjAGwAaQBlAG4AdAA..." /> </Target> </Project>
2. Real-World Campaigns: PlugX and Fake Pro
In January 2025, Lab52 and AhnLab documented a campaign where MSBuild.exe delivered PlugX malware via a phishing email disguised as a meeting invitation. The package included a legitimate G DATA antivirus executable as a loader alongside the malicious DLL. In April 2026, the same package appeared on a fake Pro download site. Twenty-two seconds after installation, the infected machine had already connected to a command-and-control server.
Step-by-step analysis of the infection chain:
- User downloads “Pro_Setup.zip” from a typosquatted domain.
- Archive contains “Pro.msi” (legitimate-looking) and “setup.csproj”.
- MSI installer executes, drops a signed binary (e.g., G Data executable), which then invokes MSBuild.exe.
- MSBuild.exe compiles setup.csproj, which loads PlugX shellcode directly into memory.
- System connects to C2 at 185.130.5.253:443 (example) for remote control.
To simulate detection, use Sysmon Event ID 1 (process creation) and filter for:
– Image: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
– CommandLine containing no .csproj argument (suspicious auto-load behavior)
– ParentImage: not typical dev tools (e.g., Outlook, WinRAR, msiexec)
3. Detection Using PowerShell and Sysmon
Security teams can implement real-time alerts by monitoring specific process creation events and file writes. Below are verified commands to deploy on Windows endpoints.
Enable Sysmon with a configuration that logs MSBuild.exe activity:
Download Sysmon and config Invoke-WebRequest -Uri "https://live.sysinternals.com/Sysmon64.exe" -OutFile "$env:TEMP\Sysmon64.exe" Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile "$env:TEMP\sysmon.xml" Install Sysmon Start-Process -FilePath "$env:TEMP\Sysmon64.exe" -ArgumentList "-accepteula -i $env:TEMP\sysmon.xml" -NoNewWindow -Wait
Create a custom detection rule for MSBuild.exe launching from suspicious directories:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=1} | Where-Object {
$<em>.Properties[bash].Value -like 'MSBuild.exe' -and
($</em>.Properties[bash].Value -like '\Downloads\' -or $<em>.Properties[bash].Value -like '\Temp\')
} | Select-Object TimeCreated, @{n='CommandLine';e={$</em>.Properties[bash].Value}}
For network-based detection, alert when MSBuild.exe initiates outbound connections (Event ID 3):
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=3} | Where-Object {
$<em>.Properties[bash].Value -like 'MSBuild.exe' -and $</em>.Properties[bash].Value -ne '127.0.0.1'
}
4. Mitigation: Blocking MSBuild.exe with AppLocker and WDAC
Since MSBuild.exe is not required on most end-user workstations (only developers and build servers need it), the most effective defense is to block its execution entirely using Application Control policies.
Step-by-step to block MSBuild.exe using AppLocker (Windows 10/11 Pro/Enterprise):
– Open `secpol.msc` → Application Control Policies → AppLocker → Executable Rules.
– Right-click → Create New Rule → Deny → Select “Publisher” as rule condition.
– Click “Browse” and navigate to C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe.
– Select “Microsoft Windows” as publisher and set the version to “Any”.
– Complete the rule and enforce it via gpupdate /force.
For Windows Defender Application Control (WDAC), create a policy that explicitly denies MSBuild.exe:
Run as Administrator $Rules = @( New-CIPolicyRule -DriverFilePath "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" -Deny ) New-CIPolicy -FilePath "C:\WDAC\BlockMSBuild.xml" -Rules $Rules -UserPEs ConvertFrom-CIPolicy -XmlFilePath "C:\WDAC\BlockMSBuild.xml" -BinaryFilePath "C:\WDAC\BlockMSBuild.bin" Deploy via Group Policy or Copy-Item "C:\WDAC\BlockMSBuild.bin" -Destination "C:\Windows\System32\CodeIntegrity\SiPolicy.p7b"
5. Behavioral Analysis and Network Alerts
Because MSBuild.exe is not a typical network client, any outbound connection from it is highly suspicious. Configure your SIEM or EDR to trigger on:
- MSBuild.exe making DNS requests to rare or newly registered domains.
- MSBuild.exe connecting to non-Microsoft IP addresses on ports 80, 443, 8080, 4444.
- MSBuild.exe spawning child processes like
powershell.exe,cmd.exe,rundll32.exe, orregsvr32.exe.
Example Sigma rule (YAML) for detection:
title: MSBuild Suspicious Child Process status: experimental logsource: product: windows category: process_creation detection: selection: Image|endswith: '\MSBuild.exe' ParentImage|contains: 'Downloads' condition: selection falsepositives: - Developers running builds from Downloads folder (rare) level: high
For Linux-based EDR (if monitoring Windows via syslog), use `auditd` to monitor SMB shares or forwarded events, but the primary detection remains on Windows endpoints.
6. Incident Response Steps for MSBuild LOLBin Attacks
If you suspect MSBuild.exe has been abused on a system, follow this IR playbook:
- Isolate the machine from the network immediately.
- Collect memory dump using `DumpIt` or `winpmem` to capture in-memory payloads.
- Extract MSBuild logs: `Get-WinEvent -FilterHashtable @{LogName=’Microsoft-Windows-TaskScheduler/Operational’}` to find scheduled tasks that may persist the .csproj.
- Search for .csproj files in unusual locations: `Get-ChildItem -Path C:\ -Recurse -Filter .csproj -ErrorAction SilentlyContinue | Where-Object { $_.DirectoryName -match ‘Temp|Downloads|AppData’ }`
– Check for persistent WMI subscriptions: `Get-WMIObject -Namespace root\subscription -Class __FilterToConsumerBinding`
– Review network connection logs: `netstat -ano | findstr “ESTABLISHED”` and correlate with MSBuild PID. - Reimage the machine if any unknown outbound connection is confirmed.
7. Other LOLBins Used in Fileless Attacks
MSBuild is just one of dozens of LOLBins. Attackers also abuse:
– `Regsvr32.exe` – to run scriptlets via scrobj.dll.
– `Mshta.exe` – to execute JavaScript/VBS from .hta files.
– `Cscript.exe` / `Wscript.exe` – for script execution.
– `InstallUtil.exe` – to run .NET binaries.
– `Certutil.exe` – to decode and execute Base64 payloads.
To harden against all LOLBins, deploy a default-deny AppLocker policy that only allows known executables in C:\Program Files, `C:\Windows\System32` (with specific exceptions), and block scripting engines from writing child processes.
What Undercode Say:
- Key Takeaway 1: MSBuild.exe abuse is a perfect example of why signature-based antivirus fails – trusted binaries with valid certificates execute malicious code entirely in memory, bypassing file scans.
- Key Takeaway 2: Defense must shift to behavioral detection (network egress filtering, process lineage analysis, and application whitelisting) because Microsoft will not patch a legitimate feature.
- Analysis: The success of this technique lies in its simplicity – no exploits, no privilege escalation, just a design quirk. Organizations that rely solely on next-gen AV without EDR or application control remain vulnerable. The April 2026 fake Pro campaign proves threat actors actively weaponize this in the wild. Blocking MSBuild.exe on non-developer workstations is the single most effective mitigation, followed by strict alerting on .csproj files in user-writable directories. As LOLBins become more prevalent, expect attackers to chain multiple tools (e.g., MSBuild + Regsvr32) to evade even behavioral rules.
Prediction:
Within the next 12 months, Microsoft will likely introduce a controlled folder or a “Trusted Compiler” list in Defender for Endpoint that flags MSBuild.exe when invoked from untrusted paths (Downloads, Temp) – but they will not remove the functionality. Attackers will shift to lesser-known .NET tools like `csc.exe` (the C compiler) or `vbc.exe` with similar auto-load behaviors. Meanwhile, threat actors will begin distributing .csproj files via OneDrive phishing links and Teams webhooks, bypassing email gateway scans. The long-term impact will force enterprises to adopt zero-trust execution policies, where even signed Microsoft binaries are subject to behavioral constraints. Security operations centers must train analysts to recognize LOLBin chains – not just isolated alerts – as the new norm in fileless malware campaigns.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Jolandadekoff Ethicalhacking – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
