MSBuild — CraftedSignal Threat Feed

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 Process Injection Detection

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

The Microsoft Build Engine (MSBuild) is a platform for building applications, commonly used in software development environments. Adversaries are exploiting MSBuild to perform process injection, a technique to execute malicious code within the address space of another process. This allows attackers to evade detection and potentially escalate privileges. The detection focuses on monitoring for thread creation in other processes by instances of MSBuild.exe. This activity is considered unusual outside of legitimate software development or build environments. The exploitation of MSBuild for process injection is a known technique (T1127.001) to proxy execution through trusted developer utilities.

Attack Chain

An attacker gains initial access to the system through various means (e.g., compromised credentials, software vulnerability).
The attacker executes MSBuild.exe, either directly or through another process.
MSBuild.exe is used to load and execute a malicious project file or inline code.
The malicious code within the MSBuild project file leverages Windows API calls to create a thread in a target process.
The created thread injects malicious code or a payload into the target process’s memory space.
The injected code executes within the context of the target process, potentially performing malicious activities.
These activities could include lateral movement, data exfiltration, or establishing persistence.

Impact

Successful process injection can lead to a variety of malicious outcomes, including privilege escalation, data theft, and system compromise. While the specific number of victims is not available, any Windows system running MSBuild is potentially vulnerable. The use of a trusted Microsoft utility like MSBuild makes detection more difficult, as it can blend in with legitimate developer activity. This can lead to prolonged compromise and significant damage before the malicious activity is detected.

Recommendation

Enable Sysmon process creation and CreateRemoteThread logging (event IDs 1 and 8) to detect the malicious activity described in the attack chain.
Deploy the Sigma rule “Process Injection by the Microsoft Build Engine” to your SIEM and tune for your environment to reduce false positives.
Implement application whitelisting to prevent unauthorized execution of MSBuild.exe in non-development environments.
Monitor the parent processes of MSBuild.exe for unusual or suspicious activity.

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.”

Potential Credential Access via MSBuild Loading Credential Management DLLs

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

This detection rule identifies potential credential access attempts leveraging the Microsoft Build Engine (MSBuild). Attackers may abuse MSBuild, a legitimate developer tool, to load malicious DLLs related to Windows credential management, such as vaultcli.dll or SAMLib.dll. This technique enables credential dumping by a trusted Windows utility, making it harder to detect. The rule focuses on detecting the loading of these specific DLLs by MSBuild processes. The rule relies on data from Elastic Defend and Sysmon logs.

Attack Chain

Attacker gains initial access to the target system (e.g., via phishing or exploiting a vulnerability).
Attacker places a malicious .csproj file or a DLL designed to load credential management DLLs on the system.
The attacker executes MSBuild.exe to process the malicious project file.
MSBuild.exe loads the attacker-controlled DLL.
The attacker-controlled DLL loads either vaultcli.dll or SAMLib.dll.
The loaded DLLs are used to dump credentials from the system.
The attacker accesses the dumped credentials.
The attacker uses the compromised credentials for lateral movement or data exfiltration.

Impact

A successful attack can lead to the compromise of sensitive credentials stored on the affected system. This can allow attackers to move laterally within the network, access confidential data, and potentially compromise entire domains. The impact ranges from data breaches to complete system compromise, depending on the privileges of the compromised accounts.

Recommendation

Deploy the Sigma rule MSBuild Loads Credential Management DLL to your SIEM, tuned for your specific environment, to detect instances of MSBuild loading vaultcli.dll or SAMLib.dll.
Enable Sysmon event ID 7 (Image Loaded) logging with the appropriate configurations to capture DLL loading events.
Investigate any instances of MSBuild loading vaultcli.dll or SAMLib.dll from unusual or unexpected locations using the guidance in the rule note.