MSBuild LOLBin Abused in Fileless Windows Attacks

Key Takeaways

• Threat actors are actively exploiting MSBuild.exe, a legitimate Microsoft Windows utility, to execute fileless attacks.
• This “Living Off The Land” (LOTL) technique allows malicious code to run in memory without dropping traditional executable files, making detection difficult.
• The attacks leverage MSBuild’s trusted digital signature and its ability to run inline C# code to bypass conventional signature-based security tools.
• Recent campaigns observed by ASEC demonstrate establishing reverse shells and using MSBuild as a downloader with DLL sideloading.

Cybercriminals are increasingly adopting “Living Off The Land” (LOTL) tactics, utilizing legitimate system tools to execute their attacks. Among these, MSBuild.exe, a core component of the .NET framework, has become a prominent choice for threat actors seeking to circumvent traditional security measures and launch fileless Windows attacks, according to recent research.

This Microsoft-signed build utility, inherently trusted by the operating system, is now being weaponized to run malicious code directly in memory. This approach eliminates the need to drop a conventional executable file onto the disk, significantly reducing the attack’s footprint and making it harder to detect.

MSBuild.exe was originally developed to assist software developers in compiling applications using XML-based project files. Its legitimate Microsoft digital signature causes most security solutions to deem it safe.

Attackers exploit this inherent trust by embedding malicious C# code directly within project files. When executed, this code runs in memory, leaving minimal to no trace on the file system. This stealthy execution renders the attack virtually invisible to traditional signature-based detection tools.

Real-World Attack Scenarios

Analysts at ASEC have documented two distinct real-world attack scenarios where MSBuild was leveraged as a Living Off the Land Binary (LOLBin). The first incident, identified in January 2025, showcased MSBuild’s capability to establish a TCP reverse shell connection. Notably, this activity did not trigger any alerts from Windows 11 Defender, even with real-time monitoring actively enabled.

A more advanced campaign, discovered in February 2026, revealed attackers using MSBuild as a downloader. In this scenario, MSBuild retrieved malicious files from an external command-and-control (C2) server, integrating this with a DLL sideloading technique.

MSBuild’s attractiveness to attackers stems from three key capabilities. First, it can execute C# code directly within project files, negating the requirement for a separate malicious executable. Second, it supports essential attacker functions like file loading, network communication, and binary execution. Finally, its legitimate digital signature from Microsoft allows it to bypass code signature verification checks, which many endpoint security tools rely upon.

The implications of these attacks are substantial. Organizations that depend solely on traditional antivirus or signature-based detection mechanisms are largely vulnerable to these sophisticated techniques. The fileless nature of these attacks means that minimal forensic evidence is left on disk. Furthermore, the use of a trusted system binary complicates the task for defenders attempting to differentiate between legitimate system activity and malicious operations.

Phishing Entry, Downloader Behavior, and DLL Sideloading

The attack campaign detailed by ASEC from February 2026 provides a clear illustration of how this threat operates in practice. The initial phase of the attack involves a phishing email, which contains a compressed file attachment. This attachment is typically disguised as a legitimate document, such as a meeting invitation or a work-related file.

Upon extraction, the archive reveals what appears to be a document file. However, this file is actually a renamed copy of MSBuild.exe, retaining its original Microsoft digital signature to avoid suspicion.

When the victim opens this seemingly innocuous file, MSBuild’s default functionality is triggered. It automatically scans the current directory for a project file (.csproj) and loads it without requiring any explicit command-line input from the user. This process occurs silently, unnoticed by the average user.

The loaded project file contains an inline C# script with Base64-encoded URLs that point to an external C2 server. This script decodes the URLs and proceeds to download three additional files: a randomly named executable, a DLL named Avk.dll, and a data file called AVKTray.dat. All these components are covertly stored within the system’s temporary folder.

Once downloaded, MSBuild automatically executes the newly retrieved executable. This executable, also bearing a valid digital signature, then loads the malicious Avk.dll from the same directory using a DLL sideloading technique, injecting the attacker’s code directly into memory.

Throughout this entire attack chain, the malicious activities do not appear overtly suspicious to conventional security tools, which is precisely what makes this method so effective at evading detection.

What You Should Do

• Monitor MSBuild.exe Activity: Implement robust monitoring to detect instances of MSBuild.exe executing outside of typical developer environments. Any execution originating from non-standard locations should be flagged for investigation.
• Scrutinize Project File Locations: Configure security solutions to alert on .csproj files being run from unusual directories, particularly temporary folders or download locations.
• Track Outbound Network Connections: Monitor all outbound network connections initiated by MSBuild.exe. Legitimate usage rarely involves direct communication to external, unauthorized servers.
• Detect DLL Sideloading: Employ endpoint detection and response (EDR) solutions capable of identifying DLL sideloading patterns. This involves detecting when legitimately signed executables load abnormal or untrusted DLLs from unexpected paths.
• Adopt Behavioral Analysis: Move beyond signature-based detection. Implement a multi-layered security approach that prioritizes behavior-based analysis to identify anomalous process activity, regardless of file signatures.
• User Awareness Training: Educate employees about the dangers of phishing emails and the importance of scrutinizing unexpected attachments, even if they appear to be standard document types.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.