MSBuild LOLBin: How Hackers Run Malware on Windows Without Leaving a Trace

MSBuild.exe is a LOLBin, a legitimate Windows tool being abused to run malware on fully patched machines without dropping a single file on disk, and Windows Defender does not raise an alert because MSBuild.exe carries Microsoft’s own digital signature and many security tools treat it as trusted by default. There is no patch coming because nothing here is broken. MSBuild.exe is doing exactly what Microsoft designed it to do. 😏

MSBuild.exe, the Microsoft Build Engine, has been part of the .NET Framework and Visual Studio for years. Software developers use it to compile and build applications from XML-based project files. Because Microsoft built it and signed it, Windows trusts it completely. AppLocker trusts it. Windows Defender Application Control trusts it. Most endpoint security solutions wave it through without a second look, because as far as they are concerned, it is a legitimate Microsoft tool doing its job.

A LOLBin, short for Living Off the Land Binary, is a legitimate Windows tool that attackers use to carry out an attack instead of bringing their own malware. The idea is simple: use what is already on the system, already trusted, already signed by Microsoft. Security tools see a known legitimate binary running and have no reason to interfere. MSBuild.exe fits that description perfectly, which is exactly why MITRE ATT&CK tracks this abuse under T1127.001, Trusted Developer Utilities Proxy Execution, listed under Defense Evasion. That trust is exactly what attackers are exploiting.

When MSBuild.exe starts without a project file specified on the command line, it automatically scans the directory it is sitting in for any file ending in .csproj and loads it without any further user interaction. The malicious C# code inside that project file gets compiled and executed directly in memory, with minimal artifacts written to disk and nothing for signature-based antivirus to scan.

A phishing email lands in your inbox, the attachment described as a meeting invitation or a work document. Inside the ZIP are two files. One looks like a normal document and carries a legitimate Microsoft digital signature. The other is a .csproj file sitting quietly next to it. You open what you think is the document, MSBuild.exe kicks in automatically, finds the project file right there in the same directory, and the attack is already running before anything looks suspicious.

In January 2025, security researcher Michał Walkowski published a proof-of-concept that showed exactly how this works: two files, no admin rights needed, and a reverse TCP shell connecting back to an attacker’s machine. Windows 11 with real-time protection fully switched on produced no alert and no warning in testing. The entire process chain runs through trusted Windows components, so from the perspective of standard detection rules, everything looks like normal system activity.

Then came February 2026, and things got more serious.

Lab52, the threat intelligence division of Spanish security firm S2 Grupo, was the first to document this campaign on February 26, 2026. AhnLab’s ASEC team published their own in-depth technical analysis on April 10, 2026, citing Lab52’s original findings. Together they described a real-world attack campaign where MSBuild.exe was used as a downloader to deliver PlugX, a remote access trojan that has been active since at least 2008 and keeps showing up consistently in long-running espionage operations.

The attack started with a phishing email carrying a compressed file disguised as a meeting invitation, with the actual phishing file named Invitation_Letter_No.02_2026.exe. Inside that archive was a renamed copy of MSBuild.exe, still carrying its original Microsoft signature, bundled together with a malicious .csproj file. The victim opened what appeared to be a document, MSBuild.exe auto-loaded the project file from the same directory, and the inline C# script immediately reached out to an attacker-controlled server to pull down three additional files.

Those three files tell the story of how sophisticated this approach has become. All three arrived in the Windows temporary folder under randomized filenames, a folder that cleans itself and leaves almost nothing behind. The package included a completely legitimate executable from German antivirus company G DATA, alongside Avk.dll, identified as a PlugX variant called Korplug, and an encrypted payload file. When the G DATA binary ran, it loaded the DLL from the same directory, which is completely normal expected behavior for that legitimate program, and that DLL pulled PlugX directly into memory. The anti-malware software was the loader.

Security software watched the entire chain and flagged nothing, because every individual component in that chain is legitimate. MSBuild.exe is a trusted Microsoft binary, the G DATA executable is trusted, and a DLL loading from the same directory as its parent executable is completely normal behavior. The whole infection looked like routine activity on a working system.

Lab52 connected this activity to patterns linked to multiple threat groups. Researchers tracking this have named clusters including TA416, which overlaps with groups tracked as Mustang Panda, RedDelta, and Twill Typhoon, all consistently linked to state-aligned espionage operations targeting government institutions, diplomatic entities, and defense organizations across Europe and Asia.

In cybersecurity, attribution is one of the hardest problems in the field. IP addresses can be rented and abandoned. Tools circulate in underground forums and get picked up by completely unrelated actors. Code can be modified to mimic another group’s style. What the research establishes clearly is how the malware works and where it was observed, not necessarily who ordered it.

What is documented is that malicious MSBuild packages were being hosted on Google Drive and compromised SharePoint instances and distributed through targeted phishing campaigns. By March 2026 the same patterns were showing up in campaigns aimed at government bodies in the Middle East.

And then in April 2026 the exact same package showed up somewhere completely unexpected.

Malwarebytes documented a campaign spreading PlugX through a fake website offering a download for Claude Pro, an AI assistant. The site delivered a nearly identical three-file sideloading package using the same G DATA sideloading technique, with only the filenames changed. The installer even contained a typo in the installation path, writing to a folder called Cluade instead of Claude, a small slip that gives away the fake. Twenty-two seconds after installation, the infected machine had already made its first outbound connection to a command-and-control server. The same technique is being recycled with fresh lures as fast as researchers can document it.

MSBuild.exe abuse is not limited to state-linked espionage operations. Since early 2024, a large-scale cybercrime campaign known as ClickFix has been tricking victims into pasting commands into their Windows Run dialog or terminal, with those commands delivering payloads through LOLBins including MSBuild.exe. Thousands of systems are hit daily, delivering stealers, remote access trojans, and loaders like AsyncRAT and Lumma Stealer. The technique has moved well beyond targeted attacks.

Part of the reason it spread so fast is its deep roots in the red team community. MSBuild is tightly woven into the Cobalt Strike ecosystem through community tools like PowerLessShell, which generates malicious .csproj files that execute payloads through MSBuild without ever launching PowerShell. That is how the technique moved from professional penetration testers into the hands of criminal groups and state actors.

Fortinet documented a separate campaign in February 2026 where MSBuild.exe was used differently again, this time as the target of process hollowing to deliver XWorm, a modular remote access trojan. Instead of using MSBuild as a downloader, attackers injected XWorm directly into a running MSBuild.exe process, replacing its memory with malicious code while keeping the trusted process name visible to security tools. Different malware family, different technique, same trusted binary being abused.

The reason this is so difficult to defend against is straightforward. MSBuild.exe is a legitimate and useful tool, and on machines where software development happens, blocking it breaks real workflows. The same features that make it useful, inline code execution, network access, and the full .NET runtime, make it a powerful base for exactly this kind of attack. Commodity malware, ransomware operators, and advanced persistent threat groups have all used it for years. The technique is not new. The active campaigns running right now are.

MSBuild.exe does not only run on developer workstations. It runs on build servers, the systems that compile and package software for entire organizations. If an attacker compromises a build server and injects malicious code into a project file, that code gets compiled directly into otherwise legitimate software, potentially signed and distributed to every machine in the organization. The build system becomes a code-signing machine for the attacker.

Here is what to do depending on your situation.

If you are on a machine without a development environment:

• → Block MSBuild.exe entirely using AppLocker or Windows Defender Application Control. If nobody on that system compiles software, there is no reason for it to run.
• → You can also restrict access to the binary directly at C:\Windows\Microsoft.NET\Framework\

If MSBuild.exe is genuinely needed on your system:

• → Set up monitoring to alert on MSBuild.exe making any outbound network connection. This catches the attack at the point the downloader reaches out to retrieve its payload.
• → Alert on .csproj or .proj files executing from %TEMP%, the Downloads folder, or anywhere outside your normal source code directories.
• → Watch for MSBuild.exe spawning child processes like PowerShell or cmd.exe, because that has no legitimate explanation in a normal build workflow.
• → Alert on MSBuild.exe running from a user download folder or the Windows temporary directory.

For everyone:

• → Do not open compressed email attachments that contain executable files, even when the file carries a legitimate digital signature and looks like a document.
• → Keep Windows updated and watch Microsoft security advisories for updates related to this attack surface.

There is no patch coming for this, because MSBuild.exe is not broken. It is working exactly as designed, and the attack lives entirely inside that legitimate behavior. The only real defense is behavioral detection, knowing what normal MSBuild.exe activity looks like, and alerting on everything that falls outside it.

Understanding detection evasion, how attackers abuse trusted system tools to stay invisible, and how to analyze and stop these techniques is covered in depth in my ethical hacking course, including malware analysis, privilege escalation, and the complete attack chain from initial access to full system compromise.

• → Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources: Lab52: PlugX Meeting Invitation via MSBuild and GDATA · AhnLab ASEC: LOLBins Analyzing Attack Techniques with MSBuild · Proofpoint: TA416 Resumes European Government Espionage Campaigns · Malwarebytes: Fake Claude Site Installs Malware