Proxy-Execution — CraftedSignal Threat Feed

Process Activity via Compiled HTML File Execution

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

Attackers are known to deliver malicious payloads within compiled HTML files (.chm) to bypass security measures and gain initial access to systems. This technique leverages the Microsoft HTML Help system and its associated executable, hh.exe, to proxy the execution of malicious code. Compiled HTML files can contain various types of content, including HTML documents, images, and scripting languages like VBA, JScript, Java, and ActiveX. By embedding malicious scripts or executables within a .chm file, attackers can trick users into executing them when they open the file. This is particularly effective because hh.exe is a signed binary, which may allow it to bypass certain security controls. The scope of this technique affects Windows systems where the HTML Help system is installed.

Attack Chain

The attacker crafts a malicious .chm file containing embedded malicious code, such as a PowerShell script or executable.
The attacker delivers the .chm file to the victim via social engineering, such as phishing or malicious websites.
The victim opens the .chm file, causing hh.exe to launch.
hh.exe processes the .chm file, rendering its content, which includes the embedded malicious script or executable.
The malicious code executes, often spawning a scripting interpreter like powershell.exe or cmd.exe.
The scripting interpreter executes commands to download additional payloads or perform malicious actions on the system.
The attacker gains initial access to the victim’s system.
The attacker escalates privileges and moves laterally within the network.

Impact

Successful exploitation can lead to initial access, code execution, and potentially full system compromise. This can result in data theft, malware installation, and further lateral movement within the network. The severity and impact depend on the permissions of the user running hh.exe and the nature of the malicious payload.

Recommendation

Deploy the Sigma rule “Compiled HTML File Spawning Suspicious Processes” to your SIEM to detect instances where hh.exe is the parent process of scripting interpreters.
Enable Sysmon process creation logging to provide the necessary data for the Sigma rule to function correctly.
Monitor process execution chains for unknown processes originating from hh.exe, as mentioned in the investigation guide.
Implement email filtering and security awareness training to prevent users from opening malicious .chm files delivered via phishing.
Block the execution of unsigned or untrusted executables in the environment to reduce the risk of malicious code execution.
Use endpoint detection and response (EDR) solutions like Elastic Defend, CrowdStrike, Microsoft Defender XDR, and SentinelOne to detect and respond to malicious activity.

InstallUtil Process Making Network Connections for Defense Evasion

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

InstallUtil.exe is a legitimate Windows utility used for installing and uninstalling server resources. Adversaries abuse InstallUtil.exe to execute malicious code under the guise of legitimate processes, often to evade detection. This technique allows attackers to proxy execution through a trusted system binary, potentially bypassing application control and security monitoring. The detection rule identifies suspicious network activity by monitoring InstallUtil.exe’s outbound connections, flagging potential misuse by alerting on the initial network connection attempt. This activity is detected via the Elastic EQL rule “InstallUtil Process Making Network Connections.”

Attack Chain

An attacker gains initial access through an undisclosed method.
The attacker uses InstallUtil.exe to execute a malicious .NET assembly.
InstallUtil.exe loads the malicious assembly into its process.
The malicious assembly executes code that establishes an outbound network connection.
The connection is used for command and control (C2) or data exfiltration.
The attacker may use the C2 channel to download and execute further payloads.
The attacker performs lateral movement within the network.
The attacker achieves their objective, such as data theft or system compromise.

Impact

Successful exploitation can lead to arbitrary code execution within the context of a trusted Windows process (InstallUtil.exe), bypassing application control and potentially evading detection. This could result in a compromised system, data exfiltration, or further malicious activities within the network. The scope of impact depends on the attacker’s objectives and the level of access gained, potentially affecting entire organizations.

Recommendation

Enable process creation logging and network connection logging via Sysmon or Elastic Defend to provide the data needed for the rules below.
Deploy the Sigma rule “InstallUtil Network Connection” to your SIEM and tune for your environment to detect suspicious outbound network connections from InstallUtil.exe.
Investigate any alerts triggered by the Sigma rule by examining the parent process of InstallUtil.exe, destination IP addresses, and associated activities.
Implement network monitoring and alerting for unusual outbound connections from critical systems to enhance detection of similar threats in the future.

Unusual Network Activity from Windows System Binaries

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

Attackers frequently abuse trusted Windows system binaries and developer utilities to proxy the execution of malicious payloads, effectively bypassing security controls that would otherwise prevent direct execution. This technique, known as “System Binary Proxy Execution,” allows adversaries to masquerade their activities and blend in with legitimate system processes. This detection identifies network activity from system applications such as mshta.exe, regsvr32.exe, and installutil.exe that are not expected to initiate network connections under normal circumstances. The original rule was created in September 2020, and updated in May 2026. The scope of targeting includes any Windows environment where adversaries might attempt to evade detection by proxying malicious activity through trusted system binaries.

Attack Chain

An attacker gains initial access to the system, often through phishing or exploiting a vulnerability.
The attacker drops a malicious payload onto the system, potentially obfuscated to avoid detection.
The attacker uses a trusted system binary, such as mshta.exe, regsvr32.exe, or installutil.exe to execute the payload.
The system binary initiates a network connection, potentially to a command-and-control (C2) server.
The attacker uses the C2 channel to download additional tools or exfiltrate data.
The attacker moves laterally within the network, compromising additional systems.
The attacker achieves their final objective, such as data theft, ransomware deployment, or system disruption.

Impact

Successful exploitation can lead to a variety of negative impacts, including data breaches, system compromise, and potential financial losses. The technique is often employed in targeted attacks and can be difficult to detect due to the use of legitimate system binaries. If successful, attackers can maintain persistence, escalate privileges, and move laterally within the network, leading to widespread damage.

Recommendation

Enable Sysmon process creation (Event ID 1) and network connection (Event ID 3) logging to provide the necessary data for detection.
Deploy the Sigma rules in this brief to your SIEM to detect unusual network activity from Windows system binaries.
Regularly review and update the list of known benign network connections from these binaries to reduce false positives.
Implement application control policies to restrict the execution of untrusted applications.
Monitor DNS queries (Sysmon Event ID 22) for suspicious domain resolutions originating from system binaries.

Conhost Proxy Execution for Defense Evasion

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

Attackers are leveraging the Console Window Host (conhost.exe) to proxy execution of commands, using the --headless argument to hide malicious activity. This technique allows adversaries to blend in with legitimate Windows processes, making detection more challenging. This behavior, often associated with defense evasion, involves using conhost.exe to execute commands such as PowerShell, cmd.exe, mshta, curl, and scripts. The activity can be seen across multiple environments including endpoints, Windows systems, and cloud platforms like Microsoft Defender XDR and SentinelOne. Defenders must differentiate between legitimate uses of conhost.exe, such as those by Winget-AutoUpdate or OpenSSH, and malicious proxy executions, which could indicate broader compromise.

Attack Chain

An attacker gains initial access to the system, possibly through phishing or exploiting a vulnerability.
The attacker executes a command that calls conhost.exe with the --headless argument.
Conhost.exe is used to proxy the execution of a malicious command, such as PowerShell, cmd.exe, or mshta.
The proxied command downloads a malicious payload from a remote server using tools like curl or bitsadmin.
The downloaded payload is executed, establishing persistence on the compromised system.
The attacker uses the compromised system to move laterally within the network, compromising additional systems.
Sensitive data is exfiltrated from the network to a remote server controlled by the attacker.
The attacker achieves their final objective, such as deploying ransomware or stealing intellectual property.

Impact

Successful exploitation can lead to a complete compromise of the targeted system and potentially the entire network. This can result in data theft, financial loss, and reputational damage. The use of conhost.exe for proxy execution makes it difficult to detect malicious activity, potentially allowing attackers to remain undetected for extended periods. The impact could range from individual workstation compromises to large-scale network breaches, affecting potentially hundreds or thousands of systems within an organization.

Recommendation

Deploy the “Proxy Execution via Console Window Host” Sigma rule to your SIEM and tune for your environment to detect suspicious conhost.exe activity.
Monitor process creation events for conhost.exe with the --headless argument, focusing on the command-line arguments to identify potentially malicious commands.
Investigate any instances of conhost.exe executing suspicious scripts, downloaders, or task scheduler modifications to identify potential threats.
Enable Sysmon process creation logging (Event ID 1) to capture detailed process execution information, as recommended in the setup instructions linked in the overview.
Review the investigation fields in the brief to understand the key data points for analyzing potential proxy execution attempts.

Proxy Execution via Windows OpenSSH Client

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

This detection identifies attempts to execute commands through a proxy using the Windows OpenSSH client (ssh.exe or sftp.exe). Attackers may abuse this behavior to evade application control policies by leveraging the trusted Windows OpenSSH binaries. The technique involves using the ProxyCommand or LocalCommand options with the OpenSSH client to execute arbitrary commands on the target system. The rule focuses on detecting command lines containing potentially malicious commands such as PowerShell, schtasks, mshta, msiexec, cmd, or script execution, indicating a possible attempt to bypass security measures. The detection logic is applicable to Windows systems.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker executes the Windows OpenSSH client (ssh.exe or sftp.exe) with either the ProxyCommand or LocalCommand option.
The ProxyCommand or LocalCommand parameter specifies a command to be executed locally on the system.
The command includes potentially malicious payloads such as PowerShell commands, scheduled tasks manipulation (schtasks), or execution of other LOLBINs (Living Off the Land Binaries) like mshta or msiexec.
The OpenSSH client executes the specified command.
The malicious command performs actions such as downloading and executing additional payloads, creating scheduled tasks for persistence, or executing arbitrary code.
The attacker achieves their objectives, such as gaining further access to the system, escalating privileges, or deploying malware.

Impact

Successful exploitation can lead to a complete compromise of the affected system. Attackers can bypass application control mechanisms, execute arbitrary code, and establish persistence. This can result in data theft, system disruption, or further propagation of the attack within the network. The severity of the impact depends on the privileges of the account running the OpenSSH client and the specific actions performed by the malicious commands.

Recommendation

Enable process creation logging with command line details to capture the execution of ssh.exe and sftp.exe with malicious parameters.
Deploy the Sigma rule Proxy Execution via Windows OpenSSH to your SIEM to detect suspicious OpenSSH client executions with malicious commands in the command line.
Monitor for the creation of child processes from ssh.exe or sftp.exe, as this can indicate the execution of malicious commands specified in the ProxyCommand or LocalCommand options.
Review and restrict the usage of PermitLocalCommand in OpenSSH server configurations to prevent attackers from executing commands locally on the system after a connection is established.

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.

Unusual System Utilities Initiating Network Connections

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

Attackers frequently exploit built-in system utilities to bypass security measures and execute malicious code. This technique, known as “Living off the Land,” allows them to blend in with legitimate system activity, making detection more challenging. This threat brief focuses on identifying unusual network connections originating from Windows system utilities that are not typically associated with network communication. This behavior is often indicative of an attacker leveraging these tools for purposes such as downloading payloads, establishing command and control, or exfiltrating data. The utilities of concern include: Microsoft.Workflow.Compiler.exe, bginfo.exe, cdb.exe, cmstp.exe, csi.exe, dnx.exe, fsi.exe, ieexec.exe, iexpress.exe, odbcconf.exe, rcsi.exe and xwizard.exe. Defenders should monitor for network activity from these processes to identify potential malicious activity.

Attack Chain

An attacker gains initial access to a Windows system through methods such as phishing or exploiting a vulnerability.
The attacker leverages a system utility such as cmstp.exe to execute malicious code.
cmstp.exe is invoked with a malicious INF file, leading to the execution of arbitrary commands.
The executed code initiates a network connection to an external server.
The connection is used to download a secondary payload, such as a reverse shell or malware.
The attacker uses the downloaded payload to establish a persistent presence on the system.
The attacker performs lateral movement to other systems on the network.
The attacker exfiltrates sensitive data from compromised systems to a remote server.

Impact

A successful attack can lead to a compromised system with unauthorized code execution, data exfiltration, and potential lateral movement within the network. Due to the low severity and the high probability of false positives, this rule should be tuned for specific environments and paired with other detection mechanisms. This may lead to data breaches, financial loss, or reputational damage.

Recommendation

Implement the Sigma rules provided in this brief to detect unusual network connections from system utilities within your environment.
Monitor process execution events for the utilities listed in the rule query to identify potential abuse of these tools.
Enable Sysmon Event ID 1 (Process Creation) and Event ID 3 (Network Connection) logging for enhanced visibility into process execution and network activity.
Correlate detections from this rule with other security alerts and logs to gain a more complete understanding of the attack.

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.

Windows Proxy Execution of .NET Utilities via Scripts

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

This threat brief addresses the abuse of trusted Microsoft .NET binaries as proxies for malicious code execution. Attackers leverage script-based execution (e.g., PowerShell, VBScript, batch files) from atypical or user-writable directories to launch .NET utilities like aspnet_compiler.exe, msbuild.exe, regasm.exe, InstallUtil.exe, and vbc.exe. This method allows threat actors to bypass security controls and blend in with legitimate system activity. Observed activity occurs in environments where endpoint detection and response (EDR) agents are deployed. The lack of command-line variation between the utility’s image path and its executed process reinforces the suspicion of proxy execution. This technique has been associated with malware campaigns, including the deployment of VIP Keylogger.

Attack Chain

An attacker gains initial access to the system (potentially through phishing or exploiting a software vulnerability, although this source does not specify the entry vector).
The attacker drops a malicious script (e.g., a PowerShell script) into a user-writable directory such as C:\Users\Public\ or C:\Temp\.
The malicious script executes, and is often obfuscated to evade detection, from the non-standard location.
The script then calls a legitimate .NET utility (e.g., InstallUtil.exe) to execute malicious code.
The .NET utility executes with minimal command-line arguments, often just the executable path itself, to further blend in with legitimate activity.
The .NET utility loads and executes attacker-controlled code, bypassing application control policies.
The malicious code performs actions such as keylogging (as seen with VIP Keylogger), credential theft, or lateral movement.
The attacker achieves their objective, such as data exfiltration or establishing persistent access.

Impact

Successful exploitation enables attackers to bypass application control and execute arbitrary code, potentially leading to data theft, system compromise, and persistent access. While the number of victims and specific sectors are not detailed in this brief’s source, the use of VIP Keylogger as a payload demonstrates the potential for sensitive data exfiltration. Organizations lacking robust endpoint detection capabilities are at significant risk.

Recommendation

Deploy the Sigma rule “Detect .NET Utility Execution from Unusual Script Parents” to identify potential proxy execution attempts based on process relationships and file paths (rule provided below).
Investigate any instances of .NET utilities (aspnet_compiler.exe, msbuild.exe, regasm.exe, InstallUtil.exe, vbc.exe) being launched from user-writable directories, especially when the parent process is a script interpreter (batch, CMD, PowerShell, JScript, VBScript, HTML).
Monitor process creation events (Sysmon EventID 1 or Windows Event Log Security 4688) for unusual parent-child process relationships involving script interpreters and .NET utilities.
Implement application control policies to restrict the execution of .NET utilities from untrusted locations.

Unusual Child Processes of RunDLL32 Execution Without Arguments

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

This detection identifies instances where rundll32.exe is executed without arguments or with malformed arguments, immediately followed by the execution of a child process. This behavior is atypical, as rundll32.exe is normally invoked with specific parameters indicating a DLL, export, or Control_RunDLL target. Attackers may exploit this by using rundll32.exe as a proxy to execute other malicious payloads or for command and control. The detection logic focuses on identifying instances where the argument count is one and the command line does not conform to expected patterns. This behavior has been observed being used by malware to evade traditional detection methods by proxying execution through a trusted Windows utility. This rule is applicable to endpoint telemetry, Windows event logs, and Crowdstrike FDR data.

Attack Chain

An initial access vector, such as a phishing email or exploit, delivers an initial payload to the system.
The initial payload executes, potentially dropping or creating a file on disk, or directly invoking rundll32.exe.
rundll32.exe is executed without arguments, or with malformed arguments, bypassing typical usage patterns. This is the key indicator the rule detects.
rundll32.exe spawns a child process, which could be a script interpreter (e.g., powershell.exe, cmd.exe), another executable, or a network utility.
The child process executes malicious code, downloads additional payloads, or establishes a command and control connection.
The attacker leverages the child process for lateral movement or privilege escalation within the network.
The final objective could include data exfiltration, ransomware deployment, or persistent access to the compromised system.
The adversary uses rundll32.exe to hide the execution of the malicious process and blend into normal system activity.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to gain control of the affected system. This can result in data breaches, system compromise, and potential lateral movement within the network. The use of a trusted system binary like rundll32.exe makes detection more challenging. It affects Windows systems and can be used in targeted attacks as well as widespread campaigns. Organizations failing to detect this behavior are at risk of significant data loss and operational disruption.

Recommendation

Deploy the Sigma rule Unusual RunDLL32 Child Process to your SIEM and tune for your environment to detect the execution of rundll32.exe without arguments, followed by a child process.
Enable Sysmon process creation logging (Event ID 1) to collect the necessary data for the Sigma rule.
Investigate any alerts generated by this rule to determine the legitimacy of the rundll32.exe execution and the spawned child process.
Implement application control policies to restrict the execution of unsigned or untrusted executables in your environment, mitigating the impact of this technique.
Monitor process execution events for unusual parent-child relationships involving rundll32.exe.

Control Panel Process with Unusual Arguments

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

This detection rule identifies unusual instances of Control Panel being executed with suspicious keywords or paths in the process command line. Control Panel (control.exe) is a legitimate Windows utility, but adversaries may abuse it to proxy execution of malicious code, effectively bypassing defense mechanisms. This technique involves launching control.exe with command-line arguments that point to malicious payloads or unusual file types, such as image files or INF files, or paths containing traversal sequences. The rule is designed to trigger when control.exe is launched with suspicious arguments like image files, INF files, paths containing traversal sequences, or paths in user-writable locations.

Attack Chain

An adversary gains initial access to the system (e.g., via phishing or exploiting a vulnerability).
The adversary stages a malicious payload on the system in a location such as AppData\Local or Users\Public.
The adversary crafts a command line that uses control.exe to execute the malicious payload. The command line includes a suspicious path, such as control.exe evil.jpg or control.exe ..\..\..\evil.dll.
The control.exe process is executed with the malicious command line.
Control.exe attempts to load the specified file.
If the file is an executable or script, it is executed within the context of the control.exe process.
The malicious code performs its intended actions (e.g., downloading additional payloads, establishing persistence, or exfiltrating data).
The adversary achieves their objective, such as data theft or system compromise.

Impact

Successful exploitation can lead to arbitrary code execution, allowing adversaries to install malware, steal sensitive data, or compromise the entire system. This can result in significant financial loss, reputational damage, and disruption of business operations. Because Control Panel is a signed Microsoft binary, abusing it can bypass application control policies.

Recommendation

Deploy the Sigma rule “Control Panel Process with Unusual Arguments” to your SIEM to detect suspicious control.exe command lines (rule).
Enable Sysmon process creation logging to capture the command-line arguments of control.exe (logsource).
Monitor process execution events for instances of control.exe launching child processes (rule).
Investigate any alerts generated by the Sigma rule, focusing on the parent process, command-line arguments, and any subsequent network connections (rule).
Implement application control policies to restrict the execution of control.exe from unusual locations (overview).

Msiexec Arbitrary DLL Execution

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

Msiexec.exe is the command-line utility for the Windows Installer, commonly used to execute installation packages (.msi). Attackers are known to abuse msiexec.exe to proxy the execution of arbitrary DLLs, a technique that helps bypass application control and evade detection. This approach leverages the trusted nature of msiexec.exe to execute malicious code, making it harder for security tools to identify and block the activity. The abuse of msiexec.exe has been observed in various attack campaigns, highlighting the need for defenders to monitor its usage closely.

Attack Chain

An attacker gains initial access to the target system, often through phishing or exploitation of a vulnerability.
The attacker uploads a malicious DLL to the compromised system.
The attacker uses msiexec.exe with the /Y flag to execute the malicious DLL. This flag is used to trigger DLL execution via msiexec.
Msiexec.exe loads and executes the malicious DLL.
The malicious DLL performs its intended actions, such as establishing persistence, escalating privileges, or deploying additional malware.
The attacker may use the proxy execution through msiexec.exe to evade detection by security tools monitoring process execution.
The attacker pivots to other systems or begins data exfiltration.
The ultimate objective is often data theft, system compromise, or ransomware deployment.

Impact

Successful exploitation allows attackers to execute arbitrary code on the targeted system, potentially leading to a full system compromise. This can result in data breaches, financial loss, and reputational damage. The technique is particularly effective at bypassing application control solutions, increasing the likelihood of a successful attack. While specific victim counts are unavailable, the widespread use of Windows Installer makes this a relevant threat across various sectors.

Recommendation

Deploy the Sigma rule Suspicious Msiexec Execute Arbitrary DLL to your SIEM to detect the execution of msiexec.exe with the /Y flag, indicative of potential malicious DLL execution.
Investigate any instances of msiexec.exe executing DLLs from unusual or temporary locations.
Implement application control policies to restrict the execution of msiexec.exe to authorized users and legitimate installation processes.
Monitor process creation events for msiexec.exe to identify suspicious command-line arguments and parent processes.