MSBuild abuse deepens stealth on Windows

MSBuild, a legitimate Microsoft build tool embedded in many Windows and developer environments, is drawing renewed scrutiny after fresh threat research showed how attackers are using it to run malicious code in memory, evade signature-based defences and blend into normal system activity. Security researchers and defenders say the technique is not new, but its continued effectiveness underlines how cyber intrusions are shifting away from obvious malware files and towards the abuse of trusted software already present on a machine.

The attraction for attackers is straightforward. MSBuild. exe is signed by Microsoft and is designed to compile and execute code from XML-based project files. MITRE ATT&CK classifies this as sub-technique T1127.001, noting that adversaries can abuse MSBuild’s inline task capability to insert C# or Visual Basic code into project files and have the utility compile and execute it. Because the process appears to be a normal Microsoft binary, it can slip past controls that are tuned to block unfamiliar executables rather than trusted system tools.

Research published on 10 April by AhnLab’s ASEC unit said MSBuild remains highly attractive for so-called Living off the Land Binary attacks because it lets threat actors inject and execute code inline, often without placing a conventional payload on disk. That makes the approach useful not only during initial compromise but also in post-intrusion activity, when operators want to move quietly, launch follow-on scripts or stage additional tools while keeping their footprint light. The same research pointed to MSBuild’s value as a defence-evasion mechanism because it operates through software that many organisations already trust and allow.

The broader security community has tracked this pattern for years. Anomali documented a campaign in 2021 in which attackers used MSBuild project files to deliver Remcos remote access malware and the RedLine password stealer filelessly, with low or zero antivirus detections at the time. MITRE’s procedure examples also show MSBuild being used in operations involving Empire, PlugX and other malicious activity, underscoring that the utility has long been part of the offensive playbook rather than a one-off novelty.

What has changed is the defensive challenge. Modern endpoint protection is better than it was several years ago, but defenders now face a threat landscape in which abuse of legitimate tools is routine. Red Canary’s 2025 threat reporting describes large-scale human-led investigations across millions of protected systems and highlights persistent concern around common adversary techniques rather than only custom malware strains. CrowdStrike and other vendors have likewise treated Living off the Land activity as a core detection problem, with MSBuild grouped alongside other frequently abused binaries such as mshta, rundll32 and certutil.

That trend matters because fileless or near-fileless tradecraft changes what defenders must watch. Rather than relying mainly on file hashes and quarantine events, security teams have to inspect behaviour: whether MSBuild was launched from an unusual path, whether it was triggered by PowerShell or a script host, whether it spawned command shells, wrote artefacts into user-writable folders, or opened suspicious outbound network connections. MITRE’s current detection guidance for T1127.001 explicitly points to those behaviour chains, while Elastic has published detection logic focused on MSBuild being started by script processes.

The issue also cuts into a long-running tension inside Windows security. Microsoft’s own application control guidance says organisations that do not need msbuild. exe should block it, while environments that genuinely rely on development workflows may need to permit it. That leaves enterprises balancing operational reality against abuse potential. A developer workstation, build server or admin machine may have legitimate reasons to run MSBuild, but the same allowance can create an opening for an attacker who already has access and wants to escalate quietly.

Security practitioners say the answer is less about panic over a single binary and more about reducing blind trust in signed tools. Restricting MSBuild to systems that truly need it, baselining where and when it normally runs, and flagging executions tied to suspicious parent processes or non-standard project files are all becoming standard defensive measures. The LOLBAS project, which catalogues Windows binaries with dual-use potential, lists MSBuild as capable of application allow-list bypass and arbitrary code execution, reinforcing why defenders now treat it as a monitoring priority rather than an obscure developer utility.