Living-Off-the-Land — CraftedSignal Threat Feed

Crowdstrike RTR Script Execution via PowerShell

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

This threat brief addresses the abuse of Crowdstrike Real Time Response (RTR) functionality to execute arbitrary commands on managed hosts. Attackers with access to a Crowdstrike Dashboard can use the “runscript” command to execute scripts, often PowerShell, on remote systems. This is particularly concerning because it allows attackers to leverage a trusted platform for malicious purposes, potentially bypassing traditional security controls. The encoded commands within PowerShell obfuscate the attacker’s actions, making detection more challenging. This technique has been observed in past campaigns where threat actors target SaaS applications, highlighting the potential for significant impact on organizations relying on these services.

Attack Chain

Attacker gains unauthorized access to the Crowdstrike Dashboard.
Attacker uses the RTR “runscript” command to initiate a PowerShell script execution on a target host.
The RTR process spawns dllhost.exe to execute the script.
dllhost.exe initiates powershell.exe with encoded command parameters (-EncodedCommand).
PowerShell executes the attacker-controlled, obfuscated script.
The script performs malicious activities such as reconnaissance, lateral movement, or data exfiltration.
Results of the script execution may be returned to the attacker via command and control channels.
Attacker achieves their final objective, such as data theft, system compromise, or ransomware deployment.

Impact

Successful exploitation can lead to complete compromise of targeted systems. An attacker with RTR access can use this technique to bypass normal endpoint security controls. This can result in data breaches, financial losses, and reputational damage. The impact is amplified by the trust relationship between Crowdstrike and its managed endpoints, making detection and prevention more difficult.

Recommendation

Deploy the Sigma rule Detect Crowdstrike RTR PowerShell EncodedCommand Execution to identify suspicious PowerShell executions originating from Crowdstrike RTR.
Monitor process creation events (Sysmon EventID 1) and filter for PowerShell processes with encoded commands (-EncodedCommand) where the parent process is dllhost.exe.
Review and restrict Crowdstrike Dashboard access to only authorized personnel to prevent unauthorized use of RTR.
Implement multi-factor authentication (MFA) for all Crowdstrike Dashboard accounts.
Implement the Sigma rule Detect Crowdstrike RTR PowerShell EncodedCommand Execution - Alternate.

Suspicious MSBuild Spawned by WMI Provider Process

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

This detection identifies a suspicious process execution pattern where wmiprvse.exe (the WMI Provider Host process) spawns msbuild.exe. This behavior is atypical because msbuild.exe is usually initiated by devenv.exe (Visual Studio) during software development. An adversary might leverage this technique to proxy execution of malicious code through a trusted Windows utility, a tactic known as “Living off the Land.” The activity is significant because it allows attackers to execute arbitrary code or scripts without directly introducing new executables, potentially leading to system compromise or further malicious activities, such as lateral movement and data exfiltration. The detection focuses on process relationships and command-line executions observed on Windows endpoints. This technique has been observed in campaigns such as the Storm-2460 CLFS Zero Day Exploitation.

Attack Chain

The attacker gains initial access to the system through an exploit or compromised credentials.
The attacker uses WMI to execute a malicious command or script.
wmiprvse.exe is invoked as part of the WMI execution process.
The attacker crafts a malicious project file or uses an existing one to execute code through MSBuild.
wmiprvse.exe spawns msbuild.exe to build and execute the malicious project.
msbuild.exe executes the attacker’s code, potentially downloading additional payloads or executing commands.
The attacker achieves code execution within the context of MSBuild, bypassing some application control defenses.
The attacker performs further malicious activities such as credential theft, lateral movement, or data exfiltration.

Impact

Successful exploitation allows attackers to execute arbitrary code, escalate privileges, and bypass application control mechanisms. This can lead to full system compromise, data theft, and further propagation within the network. The number of affected systems depends on the scope of the initial compromise. Successful attacks leveraging this technique have been observed to facilitate lateral movement and data exfiltration.

Recommendation

Enable Sysmon process creation logging (Event ID 1) to capture process relationships for detection.
Deploy the Sigma rule Suspicious MSBuild Spawned by WMI Provider to your SIEM to detect anomalous process spawns.
Investigate any instances where wmiprvse.exe spawns msbuild.exe, focusing on the executed command-line arguments and project files.
Implement application control policies to restrict the execution of msbuild.exe to authorized users and processes.
Monitor for suspicious network connections originating from msbuild.exe processes using a network intrusion detection system (NIDS).

Suspicious MSBuild Execution from Non-Standard Path

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

Attackers commonly abuse msbuild.exe, a legitimate Microsoft build tool, to execute malicious code while bypassing security controls. This technique, known as “Living off the Land,” allows threat actors to utilize trusted system binaries to perform malicious actions. This analytic focuses on detecting instances where msbuild.exe is executed from a non-standard path. This deviation from the expected execution path is a strong indicator of malicious activity, as legitimate uses typically involve the standard installation directory. Identifying and responding to these anomalous executions can prevent attackers from gaining a foothold and escalating their attacks. This detection is relevant across various attack scenarios, including malware deployment, privilege escalation, and lateral movement.

Attack Chain

Initial Access: An attacker gains initial access through various methods (e.g., phishing, exploiting a vulnerability).
File Dropping: A malicious payload or script is dropped onto the system.
MSBuild Download: Attacker downloads a malicious .csproj file or modifies an existing one.
Evade defenses: The attacker copies msbuild.exe to a non-standard path.
Execution: The attacker executes msbuild.exe from the non-standard path, pointing it to the malicious .csproj file.
Code Execution: MSBuild parses the project file and executes the embedded malicious code or commands.
Persistence/Lateral Movement: Depending on the executed code, the attacker establishes persistence or moves laterally within the network.
Objective Achieved: The attacker achieves their objective, such as data theft, system compromise, or ransomware deployment.

Impact

Successful exploitation can lead to arbitrary code execution, system compromise, data exfiltration, and further malicious activities. The execution of msbuild.exe from a non-standard path is often a precursor to more serious attacks, including ransomware deployment.

Recommendation

Implement the Sigma rule “Suspicious MSBuild Execution from Non-Standard Path” to detect msbuild.exe execution from unusual locations based on process creation logs.
Enable process creation logging with command-line arguments via Sysmon or other EDR solutions to ensure accurate detection of msbuild.exe execution.
Investigate any alerts triggered by the Sigma rule, focusing on the parent process, command-line arguments, and destination IP addresses.
Baseline MSBuild.exe usage within your environment to identify legitimate uses and filter them from the detection logic.
Monitor for network connections originating from msbuild.exe processes launched from non-standard paths to identify potential command and control activity.

Suspicious Microsoft Workflow Compiler Usage

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

The Microsoft Workflow Compiler (microsoft.workflow.compiler.exe) is a legitimate Microsoft executable, but its usage is uncommon in typical environments. This makes it an attractive target for attackers looking to bypass security controls and execute malicious code. Located in C:\Windows\Microsoft.NET\Framework64\v4.0.30319, the executable is designed for compiling workflow definitions, but can be abused to execute arbitrary code. Its rare usage means that any execution of this binary warrants further investigation. This activity is often seen after initial compromise, as an attempt to establish persistence or execute payloads.

Attack Chain

An attacker gains initial access to the system, potentially through exploitation of a vulnerability or social engineering.
The attacker leverages an existing scripting capability (e.g., PowerShell) to stage the malicious payload.
The attacker executes microsoft.workflow.compiler.exe to compile and execute a malicious workflow definition.
The workflow definition contains embedded code or calls out to external resources to download and execute additional payloads.
The compiled code executes in the context of the workflow compiler process, potentially bypassing application whitelisting.
The attacker establishes persistence by creating a scheduled task or modifying registry keys to automatically execute the malicious workflow on system startup.
The attacker performs lateral movement using the compromised system as a pivot point to access other systems within the network.

Impact

Successful exploitation can allow attackers to execute arbitrary code, bypass application whitelisting, and establish persistence on compromised systems. The lack of widespread usage of the Microsoft Workflow Compiler makes its malicious use difficult to detect, potentially allowing attackers to maintain a foothold in the environment for extended periods. If the attacker achieves persistence and lateral movement, it could lead to data exfiltration, ransomware deployment, or other significant security incidents.

Recommendation

Deploy the Sigma rule Suspicious Microsoft Workflow Compiler Execution to detect the execution of microsoft.workflow.compiler.exe with unusual parent processes.
Enable Sysmon process creation logging (Event ID 1) or Windows Event Log Security (4688) to ensure the necessary telemetry for the detection is available.
Investigate any identified instances of microsoft.workflow.compiler.exe execution, paying close attention to the parent process, command-line arguments, and network activity.
Monitor process execution data for unusual parent-child process relationships involving microsoft.workflow.compiler.exe, especially if the parent process is a scripting engine like PowerShell or cmd.exe.
Review and tune the suspicious_microsoft_workflow_compiler_usage_filter macro in the original Splunk search to reduce false positives in your environment.

Suspicious Microsoft Workflow Compiler Rename

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

This brief focuses on the suspicious renaming of the Microsoft Workflow Compiler (microsoft.workflow.compiler.exe), a legitimate but rarely used executable typically found in C:\Windows\Microsoft.NET\Framework64\v4.0.30319. Attackers may rename this file to masquerade malicious activity and bypass security solutions that rely on file name-based detection. This technique can be employed by various threat actors, including ransomware groups like BlackByte, to execute arbitrary code, escalate privileges, and maintain persistence on compromised systems. The LOLBAS Project documents this binary as a potential avenue for malicious code execution. This activity is significant because it represents a living-off-the-land tactic (LOTL) that is harder to detect than custom malware.

Attack Chain

An attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker identifies Microsoft.Workflow.Compiler.exe in C:\Windows\Microsoft.NET\Framework64\v4.0.30319.
The attacker renames Microsoft.Workflow.Compiler.exe to a different name (e.g., svchost.exe) using a command-line tool like rename.
The attacker executes the renamed executable with malicious parameters or a payload.
The renamed Microsoft Workflow Compiler executes arbitrary code, bypassing file name-based security controls.
The attacker achieves privilege escalation by exploiting the trust associated with the original executable.
The attacker establishes persistence by scheduling the renamed executable to run automatically.
The attacker uses the compromised system to move laterally, exfiltrate data, or deploy ransomware.

Impact

Successful renaming and execution of the Microsoft Workflow Compiler can lead to significant compromise, allowing attackers to bypass security measures and execute arbitrary code. This can lead to privilege escalation, persistence, and further malicious activities such as data theft or ransomware deployment. The BlackByte ransomware group has been known to use similar LOLBIN techniques, and the ease of renaming the file makes it a popular choice for attackers looking to evade detection.

Recommendation

Monitor process creation events (Sysmon EventID 1 or Windows Event Log Security 4688) for the execution of renamed Microsoft Workflow Compiler processes using the provided Sigma rule Detect Suspicious Microsoft Workflow Compiler Execution.
Implement endpoint detection and response (EDR) solutions to collect and analyze process telemetry, including process names, original file names, parent processes, and command-line arguments.
Deploy the Sigma rule Detect Suspicious Microsoft Workflow Compiler Rename to identify instances where Microsoft.Workflow.Compiler.exe is renamed.
Investigate any alerts generated by the Sigma rules, paying close attention to the parent processes, command-line arguments, and destination hosts.
Enable Sysmon process creation logging to activate the rules above.

Detection of Processes Launching netsh.exe for Malicious Purposes

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

This brief focuses on the anomalous execution of netsh.exe, a command-line utility native to Windows operating systems used for network configuration. While legitimate use of netsh.exe exists, its invocation by uncommon processes can signify malicious activity, such as establishing persistence or modifying network settings. This activity has been observed in attacks attributed to Volt Typhoon, where it was used for “living off the land” tactics targeting US critical infrastructure, and in malware campaigns involving Azorult, Snake Keylogger, ShrinkLocker, and Hellcat Ransomware. Defenders should monitor for unexpected processes launching netsh.exe to identify potential threats within their environments.

Attack Chain

An attacker gains initial access to a system through various means (e.g., compromised credentials, exploitation of vulnerabilities).
The attacker attempts to establish persistence on the compromised system.
The attacker uses a process (e.g., a script interpreter or legitimate application) to execute netsh.exe.
netsh.exe is invoked with specific commands to modify network configurations (e.g., adding firewall rules, configuring port forwarding, or changing DNS settings).
These network configuration changes facilitate further malicious activities, such as lateral movement, command and control communication, or data exfiltration.
Malicious helper DLLs are loaded through netsh.exe to maintain persistent access.
The attacker uses the compromised system as a foothold to move laterally within the network, targeting critical assets.
The attacker achieves their objective, such as data theft, system disruption, or ransomware deployment.

Impact

Successful exploitation via anomalous netsh.exe execution can lead to significant network compromise, including persistent access for attackers, unauthorized modification of network settings, and potential privilege escalation. This can result in data breaches, service disruption, and reputational damage. The Volt Typhoon campaign targeted US critical infrastructure, demonstrating the potential for significant impact on national security. Multiple malware families including Azorult, Snake Keylogger, ShrinkLocker, and Hellcat Ransomware have been known to abuse netsh.exe.

Recommendation

Monitor process creation events (Sysmon Event ID 1, Windows Event Log Security 4688) for the execution of netsh.exe by unusual parent processes.
Implement the Sigma rule Detect Suspicious Processes Launching Netsh to identify suspicious invocations of netsh.exe.
Investigate any instances where netsh.exe is launched with network configuration-related commands.
Review and audit existing netsh.exe configurations to identify any unauthorized or malicious changes.
Consider blocking execution of netsh.exe where it is not required for legitimate business operations.
Deploy the Sigma rule Detect Netsh Helper DLL Load to detect malicious DLL loading by netsh.exe.