Cybercriminals are increasingly exploiting legitimate Windows tools to execute malicious activities, a technique known as “Living Off the Land.” A prominent example involves the abuse of MSBuild.exe, a Microsoft-signed build utility, to launch sophisticated, fileless attacks that evade conventional security detection methods. This method allows attackers to run malicious code directly in memory, leaving minimal traces on the system’s file system.
Security researchers, including those at ASEC, have recently documented real-world scenarios where MSBuild.exe was weaponized. These attacks demonstrate the utility’s capability to establish network connections and download further malicious payloads without deploying traditional executable files. The inherent trust placed in MSBuild by operating systems and security software makes it an attractive tool for threat actors seeking stealthy and persistent access.
How Hackers Abuse MSBuild to Evade Detection
MSBuild.exe, originally intended for software development to compile project files, has been repurposed by attackers to bypass security measures. By embedding malicious C# code within legitimate-looking MSBuild project files (.csproj), threat actors can trick the utility into executing harmful commands. Because MSBuild.exe is digitally signed by Microsoft, it often passes verification checks performed by endpoint security solutions, making it difficult to distinguish from legitimate system processes.
The appeal of using MSBuild.exe lies in its native capabilities. It can execute C# code inline within project files, eliminating the need to write a standalone malicious executable to the disk. Furthermore, the utility supports file operations, network communication, and binary execution, providing attackers with a comprehensive toolkit for post-exploitation activities. This combination of inherent functionality and trusted status makes it a formidable weapon in the cybercriminal’s arsenal.
Phishing Entry, Downloader Behavior, and DLL Sideloading
Recent threat intelligence from ASEC highlights two distinct attack campaigns leveraging MSBuild in January and February of 2025 and 2026, respectively. The earlier campaign demonstrated the ability of MSBuild.exe to create a TCP reverse shell connection without triggering Windows Defender alerts, even with real-time protection active. This indicated the evasiveness of the technique, bypassing signature-based detection.
The more advanced campaign observed in February 2026 showcased a multi-stage attack. It began with a phishing email containing a compressed attachment. Upon extraction, the attachment contained a renamed MSBuild.exe, preserving its Microsoft signature. When the victim launched this executable, it silently searched for and loaded a malicious .csproj file within the same directory. This project file contained Base64-encoded URLs pointing to a command-and-control (C2) server.
The embedded C# script within the .csproj file would then decode these URLs and download three essential files to the system’s temporary folder: a randomly named executable, a DLL named Avk.dll, and a data file identified as AVKTray.dat. The MSBuild.exe utility would then execute the downloaded random executable.
Crucially, this randomly named executable, also often digitally signed to maintain a facade of legitimacy, employed a DLL sideloading technique. It loaded the malicious Avk.dll from the same directory. This process injects the attacker’s code directly into the memory space of the legitimate-looking executable, further obscuring the malicious activity from security monitoring systems. The entire chain of events is designed to be inconspicuous, making it exceptionally difficult for defenders to identify and disrupt.
The implications of these MSBuild-abused attacks are significant for organizations relying on traditional antivirus solutions. These fileless techniques leave minimal digital forensic evidence on the disk, complicating incident response efforts. The use of a trusted system binary blurs the lines between malicious operations and legitimate developer activities, making it harder for security teams to proactively detect and respond to threats.
To counter these evolving threats, security teams are advised to implement a multi-layered detection strategy. This should include monitoring for unusual executions of MSBuild.exe outside of development environments, flagging .csproj files being executed from temporary or download directories, and tracking outbound network connections initiated by MSBuild. Additionally, detecting DLL sideloading patterns, where legitimately signed executables load suspicious or unsigned DLLs, is crucial. A behavior-based approach, focusing on anomalous activities rather than solely relying on file signatures, offers a more robust defense against such sophisticated, fileless attacks.