Msbuild — CraftedSignal Threat Feed

Microsoft Build Engine Started by an Office Application

hello@craftedsignal.io — Tue, 09 Jan 2024 18:22:00 +0000

The Microsoft Build Engine (MSBuild) is a software build platform commonly used by Windows developers. When MSBuild is started by an Office application like Word or Excel, it deviates from typical usage patterns. This behavior can be indicative of a malicious document executing a script payload as part of a defense evasion tactic. Attackers may leverage MSBuild to execute code or perform actions that would otherwise be blocked or detected. This activity is particularly concerning because it can bypass traditional security measures that focus on blocking suspicious executables or scripts directly launched by Office applications. The rule was created in March 2020, and last updated in April 2026.

Attack Chain

A user opens a malicious Office document (e.g., Word, Excel, PowerPoint).
The Office document contains an embedded macro or exploit that triggers the execution of MSBuild.exe.
MSBuild.exe is launched as a child process of the Office application (e.g., winword.exe, excel.exe, powerpnt.exe).
MSBuild executes a project file or inline task specified in the command line. This can involve compiling code, executing scripts, or performing other actions.
The executed code or script performs malicious activities, such as downloading additional payloads, modifying system settings, or establishing persistence.
MSBuild may spawn child processes, such as cmd.exe, powershell.exe, or other utilities, to further execute malicious commands.
The attacker achieves their objective, which could include data exfiltration, installing malware, or gaining unauthorized access to the system.

Impact

Successful exploitation can lead to the execution of arbitrary code on the victim’s machine, potentially resulting in data theft, malware installation, or complete system compromise. Since MSBuild is a legitimate Microsoft tool, its use by malicious actors can make detection more challenging. The impact is high because it leverages a trusted process to carry out malicious activities, evading standard security measures.

Recommendation

Deploy the Sigma rule “Microsoft Build Engine Started by an Office Application” to your SIEM to detect this specific behavior based on process creation events.
Enable Sysmon process creation logging with the appropriate configuration to capture the necessary process start events for the Sigma rule to function correctly.
Investigate any alerts generated by the Sigma rule, focusing on the command-line arguments of MSBuild.exe and the parent process information, including the executable name and command line.
Monitor process execution events for MSBuild.exe with parent processes being Office applications as a high priority indicator of potential compromise.
Review and harden Office macro settings to prevent execution of malicious macros.

MSBuild Making Network Connections Indicating Potential Defense Evasion

hello@craftedsignal.io — Tue, 09 Jan 2024 12:00:00 +0000

Attackers may abuse the Microsoft Build Engine (MSBuild) to execute malicious files or masquerade as legitimate utilities to bypass detections and evade defenses. MSBuild is a platform for building applications using an XML schema for project files that controls how the build platform processes and builds software. The observed behavior involves MsBuild.exe initiating outbound network connections, which is not typical for its intended use and may indicate unauthorized code execution or command and control activity. This activity can be used to download malicious payloads, exfiltrate data, or establish a reverse shell. Detecting this behavior is crucial as it can be an early indicator of compromise.

Attack Chain

Attacker gains initial access through an external vector (e.g., phishing, software vulnerability).
Attacker executes MsBuild.exe.
MSBuild executes a malicious project file (.csproj, .vbproj).
The project file contains embedded or referenced code (e.g., C#, VB.NET) designed to perform malicious actions.
The malicious code executes, initiating a network connection.
The network connection is established to an external command and control (C2) server or a resource hosting a malicious payload.
Data exfiltration or payload download occurs via the network connection.
The attacker gains further control over the compromised system, potentially leading to lateral movement or data theft.

Impact

Compromised systems can lead to data breaches, system instability, and further propagation of malware within the network. Successful exploitation can result in sensitive information being stolen, disruption of services, and potential financial losses. This activity can be difficult to detect without specific monitoring rules and can lead to extended dwell time for attackers within the compromised environment.

Recommendation

Deploy the Sigma rule MSBuild Making Outbound Network Connection to your SIEM to detect suspicious network connections initiated by MsBuild.exe.
Investigate any alerts generated by the Sigma rule, focusing on the destination IP addresses and the content of the network traffic.
Monitor process execution events for instances of MsBuild.exe executing unusual or suspicious project files.
Enable process monitoring with command-line argument logging to identify potential malicious project files being passed to MsBuild.exe.
Consider implementing application control policies to restrict the execution of MsBuild.exe to authorized users and processes only.
Block known malicious domains and IP addresses associated with command and control activity at the firewall or DNS resolver.

MSBuild Making Network Connections

hello@craftedsignal.io — Tue, 09 Jan 2024 10:00:00 +0000

The Microsoft Build Engine (MSBuild) is a platform for building applications that uses an XML schema for project files to control the build process. Attackers can abuse MSBuild to execute malicious code, proxy code execution, and masquerade as legitimate utilities to evade defenses. This behavior is often used in defense evasion tactics. This detection identifies instances of MsBuild.exe executing and subsequently establishing network connections to external addresses. This activity warrants further investigation as it deviates from expected usage patterns and might signify malicious exploitation of MSBuild.

Attack Chain

Adversary gains initial access to the system via unspecified means.
Adversary executes MsBuild.exe.
MSBuild process loads and executes a malicious project file, potentially containing embedded code or instructions to download and execute further payloads.
The project file instructs MSBuild to initiate a network connection to a remote server.
MSBuild establishes an outbound network connection to the attacker-controlled server.
The attacker can use the established connection for command and control (C2) or data exfiltration.
The compromised host may download additional malicious tools or payloads from the C2 server using MSBuild’s network capabilities.

Impact

A successful attack leveraging MSBuild can lead to code execution, defense evasion, and potentially command and control. Although the number of affected organizations is not specified, any Windows environment where developers use MSBuild is potentially at risk. If successful, attackers can bypass traditional security measures, gain unauthorized access, and exfiltrate sensitive data.

Recommendation

Enable process creation logging and network connection logging on Windows endpoints to capture the necessary events for detection.
Deploy the Sigma rule “MSBuild Making Network Connections” to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule by examining the process execution chain and network connections for suspicious activity.
Consider adding exceptions for legitimate MSBuild network activity, based on destination IP addresses and command-line arguments.

MSBuild запускает необычные процессы

hello@craftedsignal.io — Wed, 03 Jan 2024 15:30:00 +0000

The Microsoft Build Engine (MSBuild) is a legitimate tool used for building applications. However, adversaries may abuse MSBuild to execute malicious scripts or compile code, effectively bypassing security controls. This technique is often employed to deploy malicious payloads. This detection focuses on identifying instances where MSBuild initiates unusual processes such as PowerShell, Internet Explorer, or the Visual C# Command Line Compiler (csc.exe). This activity is considered suspicious because legitimate software development workflows do not typically involve MSBuild directly spawning these processes. The original Elastic detection rule was created on 2020-03-25 and last updated on 2026-05-04.

Attack Chain

An attacker gains initial access to a system (e.g., through phishing or exploiting a vulnerability).
The attacker modifies or creates an MSBuild project file (.csproj or .sln) containing malicious commands.
The malicious MSBuild project file is crafted to execute a script or compile code.
The attacker uses the MSBuild.exe or msbuild.exe utility to execute the malicious project file.
MSBuild spawns an unusual process such as powershell.exe, csc.exe, or iexplore.exe based on the malicious project file configuration.
PowerShell executes arbitrary commands, downloads further payloads, or performs other malicious actions.
The C# compiler (csc.exe) compiles malicious code into an executable or library.
The compiled malware or downloaded payloads execute, leading to further compromise, such as data exfiltration or lateral movement.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to deploy malware, compromise sensitive data, and establish persistence on the targeted system. The use of MSBuild for malicious purposes allows attackers to bypass application whitelisting and other security controls that trust signed Microsoft binaries. While the precise number of victims is unknown, this technique can be employed against a wide range of organizations, particularly those with vulnerable systems or inadequate endpoint protection.

Recommendation

Enable process creation logging, specifically including parent-child relationships, to detect unusual process spawning by MSBuild (logs-endpoint.events.process-*, logs-system.security*, logs-windows.forwarded*, logs-windows.sysmon_operational-*, winlogbeat-*).
Deploy the Sigma rule “Microsoft Build Engine Started an Unusual Process” to your SIEM to identify instances of MSBuild spawning suspicious processes, and tune for your environment.
Investigate any instances of MSBuild spawning PowerShell, csc.exe, or iexplore.exe to determine if the activity is legitimate or malicious (process.name:(“csc.exe” or “iexplore.exe” or “powershell.exe”)).
Monitor for modifications to MSBuild project files (.proj or .sln) for signs of tampering.

Suspicious MSBuild Execution from Scripting Processes

hello@craftedsignal.io — Wed, 03 Jan 2024 14:00:00 +0000

The Microsoft Build Engine (MSBuild) is a software build platform typically used by developers. However, attackers can abuse MSBuild to execute malicious code by using it as a proxy execution method, allowing them to bypass traditional defenses. This technique involves invoking MSBuild from scripting environments like PowerShell or cmd.exe to run arbitrary code within the context of a trusted process. The activity detected by this rule focuses on instances where MSBuild is launched by a script interpreter, which is not typical for standard software development workflows. This behavior, observed since at least 2020, can be used for stealthy execution of payloads and defense evasion tactics, especially in environments that trust MSBuild as a legitimate system utility. Defenders should be aware of this technique as it allows attackers to blend in with normal system activity and bypass application control policies.

Attack Chain

The attacker gains initial access to the target system, potentially through phishing or exploiting a software vulnerability.
A script (e.g., PowerShell, cmd.exe) is used to execute a malicious command or series of commands.
The script invokes msbuild.exe with specific arguments to execute arbitrary code. This might involve inline tasks or references to external XML project files containing malicious instructions.
MSBuild processes the provided XML file or inline task, interpreting and executing the malicious code.
The executed code performs actions such as downloading additional payloads, modifying system configurations, or establishing persistence.
MSBuild, acting as a proxy, executes the attacker’s code within a trusted process, potentially evading detection by security software.
The attacker leverages the compromised system to move laterally within the network, escalating privileges, and accessing sensitive data.
The attacker’s final objective is achieved, such as data exfiltration or deploying ransomware.

Impact

Successful exploitation allows attackers to execute arbitrary code on Windows systems, potentially leading to data theft, system compromise, and further propagation within the network. This technique can bypass application control and other security measures, making it difficult to detect and prevent. The impact can range from minor data breaches to complete system takeover, depending on the attacker’s objectives and the compromised system’s role within the organization.

Recommendation

Enable Sysmon process creation logging (Event ID 1) to capture the process tree and command-line arguments, enabling detection of suspicious MSBuild executions.
Deploy the Sigma rule Microsoft Build Engine Started by a Script Process to your SIEM to identify instances of MSBuild being invoked by script interpreters. Tune the rule with appropriate whitelisting for known development activities to reduce false positives.
Monitor process execution events for msbuild.exe with parent processes such as cmd.exe, powershell.exe, cscript.exe, and mshta.exe.
Implement application control policies to restrict the execution of MSBuild to authorized users and directories.
Regularly review and update the list of excluded processes and directories in the Sigma rule to adapt to changing development practices.

MSBuild Started by System Process for Defense Evasion and Execution

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The Microsoft Build Engine (MSBuild) is a legitimate tool used by developers to build applications. However, adversaries are known to abuse MSBuild to execute malicious code, leveraging its trusted status to bypass security measures. This technique allows attackers to perform various actions on compromised systems while blending in with legitimate system activity. The observed behavior involves MSBuild being started by system processes like Explorer (explorer.exe) or Windows Management Instrumentation (WMI, wmiprvse.exe). Defenders should be aware of this unusual activity as it signifies a potential defense evasion tactic and unauthorized code execution within the targeted environment. This activity has been observed across environments leveraging Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, CrowdStrike, and standard Windows event logging.

Attack Chain

An attacker gains initial access to the system through various means (e.g., phishing, exploitation of vulnerabilities).
The attacker leverages a script or payload that invokes MSBuild.exe.
The script or payload is executed by a system process like explorer.exe or wmiprvse.exe, which is highly unusual for typical MSBuild usage.
MSBuild.exe starts with specific command-line arguments that dictate the build process, often involving malicious code.
The malicious code is embedded within an MSBuild project file (.csproj or similar).
MSBuild.exe executes the malicious code as part of the build process.
The executed code performs actions such as downloading additional payloads, modifying system configurations, or establishing persistence.
The attacker achieves their objective, such as gaining remote access, exfiltrating data, or deploying ransomware.

Impact

Successful exploitation can lead to a variety of negative outcomes, including unauthorized code execution, system compromise, data theft, and potentially complete system takeover. The use of MSBuild as a proxy execution method allows attackers to evade traditional security controls and blend in with legitimate system activities. This can result in delayed detection and increased dwell time, amplifying the potential damage. Since MSBuild is a trusted Microsoft utility, its abuse can make malicious activity harder to identify and respond to.

Recommendation

Deploy the Sigma rule “Microsoft Build Engine Started by a System Process” to your SIEM to detect instances of MSBuild.exe being launched by explorer.exe or wmiprvse.exe (see rules section).
Enable process creation logging with command line arguments to capture the full context of MSBuild.exe executions (reference setup instructions in the source URL).
Investigate any instances of MSBuild.exe started by explorer.exe or wmiprvse.exe to determine if they are legitimate or malicious.
Implement enhanced monitoring and logging for MSBuild.exe and related processes to detect similar activities in the future, ensuring alerts are configured for rapid response.
Review and whitelist any legitimate scripts or administrative tools that leverage MSBuild for authorized tasks to reduce false positives.

Microsoft Build Engine Executed After Renaming

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Attackers may rename legitimate utilities, such as MSBuild, to evade detection, application allowlists, and other security protections. MSBuild, the Microsoft Build Engine, is a platform for building applications. Attackers can abuse MSBuild to proxy the execution of malicious code. The detection rule identifies instances where MSBuild is started after being renamed, indicating a potential attempt to evade detection. The rule focuses on identifying processes where the original file name is MSBuild.exe, but the process name is different, suggesting a renaming attempt.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker renames the legitimate MSBuild.exe executable to a different name (e.g., evil.exe) to evade detection.
The attacker executes the renamed MSBuild executable (evil.exe) with a malicious project file (.csproj or similar).
MSBuild processes the project file, which contains commands or scripts to be executed.
The malicious commands within the project file are executed by MSBuild, potentially downloading or executing further payloads.
The attacker may use MSBuild to execute PowerShell commands or other scripting languages for lateral movement or further exploitation.
MSBuild can be used to modify files, registry entries, or other system settings.
The attacker achieves their final objective, such as data exfiltration or establishing persistence.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to install malware, steal sensitive information, or compromise the entire system. The renaming of MSBuild can bypass standard application allowlisting and detection mechanisms.

Recommendation

Enable Sysmon process creation logging to capture the Image and OriginalFileName fields.
Deploy the Sigma rule “Microsoft Build Engine Using an Alternate Name” to your SIEM and tune for your environment to detect renamed MSBuild executables based on process metadata and command-line arguments.
Monitor process execution events for processes with OriginalFileName of “MSBuild.exe” and a different process.name.
Implement application control policies to restrict the execution of renamed executables, specifically those with an OriginalFileName of “MSBuild.exe.”