Cybercriminals are increasingly turning to tools that already live inside Windows to carry out attacks — and MSBuild.exe has become one of their favorites.

This Microsoft-signed build utility, trusted by the operating system itself, is now being weaponized to run malicious code without ever dropping a traditional executable file on the disk.

MSBuild.exe was originally designed to help software developers compile and build applications using XML-based project files. Because it carries a legitimate Microsoft digital signature, most security solutions treat it as safe.

Attackers have taken full advantage of this trust, using it to insert malicious C# code directly into project files and execute it in memory, leaving behind little to no trace on the file system. This makes the attack virtually invisible to conventional signature-based detection tools.

ASEC analysts identified and documented two real-world attack scenarios where MSBuild was abused as a Living Off the Land Binary (LOLBin).

The first, observed in January 2025, demonstrated that MSBuild could establish a TCP reverse shell connection — all without triggering any alert from Windows 11 Defender, even with real-time monitoring enabled.

The second and more sophisticated campaign, uncovered in February 2026, showed attackers using MSBuild as a downloader to retrieve malicious files from an external command-and-control (C2) server, paired with a DLL sideloading technique.

The appeal of MSBuild for attackers comes down to three core strengths. It can execute C# code inline within project files, removing the need for a standalone malicious executable.

It supports file loading, network communication, and binary execution — everything an attacker requires. And since it is digitally signed by Microsoft, it easily slips past code signature verification checks that many endpoint security tools depend on.

The impact of these attacks is serious. Organizations relying only on traditional antivirus or signature-based detection are largely blind to these techniques.

The fileless nature of the attack means minimal forensic evidence is left on disk, and the use of a trusted system binary makes it harder for defenders to separate malicious activity from normal developer workflows.

Phishing Entry, Downloader Behavior, and DLL Sideloading

The February 2026 attack campaign detailed by ASEC shows clearly how this threat works in practice. The attack begins with a phishing email carrying a compressed file attachment disguised as a meeting invitation or a work-related document.

Attachment inside phishing email (Source - ASEC) — Attachment inside phishing email (Source – ASEC)

Inside the archive, the victim finds what appears to be a document file — but it is actually a renamed copy of MSBuild.exe, still carrying its original Microsoft signature to avoid raising suspicion.

When the victim opens the file, MSBuild’s default behavior takes over. It automatically scans the same directory for a project file (.csproj) and loads it without requiring any command-line input from the user.

main.csproj (Source - ASEC) — main.csproj (Source – ASEC)

This happens silently, at a level that most users would never detect. The loaded project file holds an inline C# script with Base64-encoded URLs pointing to an external C2 server.

The script decodes those URLs and downloads three files: a randomly named executable, a DLL named Avk.dll, and a data file called AVKTray.dat — all stored quietly inside the system’s temporary folder.

Victim System (Source - ASEC) — Victim System (Source – ASEC)

Once downloaded, MSBuild automatically runs the executable. That executable, also carrying a valid digital signature, loads the malicious Avk.dll from the same directory through DLL sideloading, injecting the attacker’s code directly into memory.

Attacker system (Source - ASEC) — Attacker system (Source – ASEC)

At no stage in this chain does the attack appear obviously malicious to security tools — which is precisely what makes it effective.

To guard against MSBuild-based attacks, security teams should monitor for MSBuild.exe executing outside developer environments, flag .csproj files running from temporary or download folders, track outbound network connections made by MSBuild, and detect DLL sideloading patterns where legitimately signed executables load abnormal DLLs.

A behavior-based, multi-layered detection approach — rather than depending on file signatures alone — remains the most dependable way to catch this threat before damage is done.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.

The post Hackers Abuse MSBuild LOLBin to Evade Detection and Launch Fileless Windows Attacks appeared first on Cyber Security News.