Attack.execution — CraftedSignal Threat Feed

Service Reconnaissance via WMIC.exe

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

Attackers may leverage the Windows Management Instrumentation Command-line (WMIC) tool for reconnaissance activities within a network. Specifically, WMIC can be used to query and retrieve information about services running on remote systems. By executing WMIC commands with the ‘service’ parameter, adversaries can identify the presence and status of specific services, potentially revealing vulnerable or misconfigured systems. This information can then be used to guide further exploitation attempts. WMIC is a built-in Windows utility, making its activity blend with legitimate system administration tasks, increasing the difficulty of detection. This activity is a component of the broader T1047 technique (Windows Management Instrumentation).

Attack Chain

The attacker gains initial access to a compromised system within the target network.
The attacker executes WMIC.exe from the command line.
WMIC.exe is invoked with the service parameter to query service information.
The command includes a target IP address or hostname to query a remote system.
The command attempts to retrieve service names and status information (e.g., wmic /node:"192.168.1.100" service get name, state).
WMIC attempts to connect to the remote host via RPC. An error message is generated if the remote host is unreachable: “Node - (provided IP or default) ERROR Description =The RPC server is unavailable”.
If the target service is not running, a “No instance(s) Available” message may be displayed.
The attacker parses the output from WMIC to identify running services of interest for further exploitation or lateral movement.

Impact

Successful service reconnaissance allows attackers to map potential attack vectors within a network. By identifying specific services running on remote systems, attackers can prioritize targets for exploitation based on known vulnerabilities or misconfigurations. This can lead to unauthorized access, data breaches, and system compromise. While the reconnaissance itself does not directly cause harm, it provides crucial information that enables subsequent malicious activities.

Recommendation

Deploy the Sigma rule Detect Suspicious WMIC Service Enumeration to your SIEM to identify potential service reconnaissance attempts via WMIC (logsource: process_creation, product: windows).
Monitor process creation events for WMIC.exe executions containing the service parameter using endpoint detection and response (EDR) solutions (logsource: process_creation, product: windows).
Implement network segmentation to limit the scope of potential reconnaissance activities.
Review and restrict the use of WMIC in your environment, as it is a common tool for both legitimate administration and malicious activity.

Detection of Python One-Liners with Base64 Decoding

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

Attackers frequently leverage Python one-liners with base64 encoding to obfuscate and execute malicious code. This technique bypasses standard security measures by concealing the true nature of the payload. The abuse involves embedding base64-encoded commands within Python scripts, which are then decoded and executed at runtime. While legitimate uses of Python and base64 exist, their combination in a single command line, especially with execution flags, is a strong indicator of malicious activity. This technique has been observed in various attacks, including those originating from fake AI websites, where malicious Python code is injected to perform unauthorized actions. Defenders should monitor for such patterns to identify and neutralize potential threats.

Attack Chain

Initial Access: The attacker gains access to the system, often through social engineering or exploiting a vulnerability.
Payload Delivery: A base64-encoded payload is delivered to the victim machine via email, website, or other means.
Python Invocation: Python is invoked via the command line, often using python.exe or python3.
Import Base64 Module: The import base64 statement is used to load the necessary decoding libraries.
Decoding Execution: The base64-encoded payload is decoded using functions like base64.b64decode() within the Python one-liner using the -c flag for command execution.
Code Execution: The decoded payload is executed in memory, performing malicious actions such as installing malware or establishing persistence.
Lateral Movement: The attacker leverages the compromised system to move laterally within the network, compromising additional systems.
Data Exfiltration/System Damage: The attacker exfiltrates sensitive data or causes damage to the system, depending on their objectives.

Impact

Successful exploitation can lead to complete system compromise, data theft, and potentially, a foothold for lateral movement within the network. The use of base64 encoding significantly hinders detection efforts, allowing attackers to operate undetected for extended periods. If successful, organizations could face data breaches, financial losses, and reputational damage.

Recommendation

Deploy the provided Sigma rule targeting process_creation events on Windows systems to detect Python commands utilizing base64 decoding functions (CommandLine|contains with import base64, b64decode, and -c).
Inspect command-line arguments of Python processes for suspicious base64 decoding patterns (as seen in the detection rule).
Implement application control policies to restrict the execution of unauthorized Python scripts, mitigating potential exploitation attempts.
Enable Sysmon process creation logging to ensure adequate coverage for the provided Sigma rule.

Suspicious Script Interpreter Execution from Environment Variable Folders

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

Attackers often leverage script interpreters like cscript.exe, wscript.exe, mshta.exe, and powershell.exe to execute malicious code. This activity becomes more suspicious when these interpreters are launched from directories referenced by environment variables commonly associated with temporary storage, such as %TEMP%, %PUBLIC%, or within user profile directories like Favorites or Contacts. This behavior is often indicative of malware attempting to evade detection by residing in locations less scrutinized by security tools. Such techniques are employed to execute malicious scripts downloaded from the internet or dropped by other malware components. This behavior has been linked to threat actors such as Shuckworm, known for targeting Ukraine with military-themed lures.

Attack Chain

A user downloads a malicious file (e.g., a document or executable) from the internet or receives it via email.
The malicious file, upon execution, drops a script file (e.g., VBScript, JavaScript, PowerShell script) into a temporary directory like C:\Users\Public\ or C:\Users\AppData\Local\Temp.
The dropped script uses obfuscation and/or encoding techniques to avoid static analysis.
The attacker executes a script interpreter (cscript.exe, wscript.exe, mshta.exe, powershell.exe) to run the malicious script from the temporary directory. The command line often includes bypass flags such as -ExecutionPolicy Bypass or -w hidden to evade security controls.
The script interpreter executes the malicious code, which may involve downloading additional payloads, establishing persistence, or performing lateral movement.
The malicious script may modify registry keys to establish persistence by adding a run key or scheduled task.
The script may attempt to connect to command-and-control (C2) servers to receive further instructions and exfiltrate sensitive data.
The final objective may include data theft, system compromise, or deployment of ransomware.

Impact

Successful exploitation can lead to the execution of arbitrary code, system compromise, and data exfiltration. Depending on the attacker’s objectives, the impact can range from data theft to full system control and ransomware deployment. The exploitation of scripting engines can bypass application control policies and other security measures, leading to widespread infection and significant disruption of business operations.

Recommendation

Deploy the Sigma rule “Script Interpreter Execution From Suspicious Folder” to your SIEM to detect suspicious script execution from temporary directories.
Review and tune the filters in the Sigma rule for your environment to reduce false positives, especially related to software installation processes.
Enable process creation logging with command-line arguments to provide the necessary data for the Sigma rule to function effectively.
Monitor PowerShell execution policies and restrict script execution to signed scripts only to prevent the execution of unsigned malicious scripts.
Implement application control policies to restrict the execution of script interpreters from untrusted locations.

Service Startup Type Modification via WMIC

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

Attackers may leverage WMIC, a legitimate Windows command-line utility, to modify the startup type of services. This tactic is often used to disable security products or critical system services, hindering incident response or creating system instability. By setting services to “Manual” or “Disabled”, adversaries ensure that these services do not automatically start upon system boot, achieving persistence or impeding detection. While WMIC is a built-in tool, its use for modifying service startup types is often indicative of malicious activity, especially when performed on security-related services. This activity may be part of a larger attack chain aimed at deploying ransomware, exfiltrating data, or establishing a persistent presence on the compromised system.

Attack Chain

An attacker gains initial access to the target system, potentially through phishing, exploiting a vulnerability, or compromised credentials.
The attacker executes wmic.exe with specific command-line arguments to interact with Windows services.
The service alias is invoked within WMIC to target specific services.
The ChangeStartMode method is used to modify the startup type of the targeted service.
The attacker sets the startup type to either Manual or Disabled, preventing the service from automatically starting on subsequent reboots.
If the targeted service is a security product, this action effectively disables the defense mechanism.
The attacker proceeds with further malicious activities, such as deploying malware or exfiltrating sensitive data, with reduced resistance.
The compromised system experiences degraded security posture and potential operational disruptions.

Impact

Successful modification of service startup types can severely impact system security and availability. Disabling security software can lead to undetected malware infections and data breaches. Disabling critical system services can cause system instability, data loss, or complete system failure. While the exact number of victims is unknown, this technique is broadly applicable across Windows environments, potentially affecting organizations of any size and in any sector. The impact ranges from minor operational disruptions to significant financial losses due to data breaches and ransomware attacks.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious wmic.exe process creations that attempt to change service startup types.
Investigate any instances where wmic.exe is used to modify service startup types, especially when the targeted services are related to security or critical system functions.
Implement endpoint detection and response (EDR) solutions to provide enhanced visibility into process execution and system modifications.
Regularly review and audit service configurations to identify unauthorized changes.

Detection of Important Scheduled Task Deletion or Disablement

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

This brief focuses on the detection of malicious activity related to the deletion or disabling of important scheduled tasks within a Windows environment. Adversaries may target these tasks to disrupt normal system operations, escalate privileges, establish persistence, or facilitate data destruction. The targeted tasks often include critical system functions like System Restore, Windows Defender updates, BitLocker encryption, Windows Backup processes, and Windows Update mechanisms. This…

PowerShell Loading .NET Assemblies via Reflection

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

This threat brief addresses the use of PowerShell to load .NET assemblies into memory using reflection, a technique frequently observed in advanced attacks. Threat actors, including those employing frameworks like Empire and Cobalt Strike, utilize this method to execute code directly in memory, evading traditional file-based security controls. The detection strategy focuses on PowerShell Script Block Logging (EventCode=4104), which captures the full commands executed, enabling analysis for specific reflection-related keywords. This behavior is a strong indicator of potential malicious activity, as it allows for unauthorized code execution, privilege escalation, and persistent access. Defenders should prioritize detection and response to such events to mitigate the risk of compromise. The technique allows attackers to bypass traditional defenses, execute code in memory, and potentially establish persistence within the targeted environment.

Attack Chain

Initial Access: The attacker gains initial access to the system, possibly through phishing or exploiting a vulnerability.
PowerShell Execution: The attacker executes PowerShell, often obfuscated or encoded, to avoid detection.
Reflection Assembly Loading: The PowerShell script uses reflection techniques, such as [System.Reflection.Assembly]::Load(), to load a .NET assembly directly into memory.
Bypassing Security Controls: The in-memory execution bypasses traditional security controls that scan files on disk.
Malicious Code Execution: The loaded assembly contains malicious code, which could be a payload for lateral movement, data exfiltration, or other malicious activities.
Privilege Escalation: The malicious code may attempt to escalate privileges to gain higher-level access to the system.
Persistence: The attacker establishes persistence by creating scheduled tasks or modifying registry keys.
Lateral Movement: The attacker uses the compromised system as a springboard to move laterally within the network, compromising additional systems.

Impact

Successful exploitation can lead to unauthorized code execution, privilege escalation, and persistent access within the environment. By loading .NET assemblies directly into memory, attackers can bypass traditional file-based security controls, making detection more challenging. This technique is often employed in advanced attacks, potentially affecting numerous systems across the network, leading to significant data breaches and system compromise. While specific victim counts are not available, the impact is considered high due to the potential for widespread damage and data loss.

Recommendation

Enable PowerShell Script Block Logging (EventCode=4104) on all endpoints to capture the full commands executed, as referenced in the description.
Deploy the provided Sigma rules to your SIEM to detect PowerShell scripts loading .NET assemblies into memory via reflection.
Investigate and remediate any alerts generated by the Sigma rules, prioritizing systems with high-value data or critical functions.
Regularly review and update PowerShell execution policies to restrict the execution of unsigned or untrusted scripts.
Monitor PowerShell logs for suspicious activity, such as the use of reflection techniques to load assemblies from unusual locations.
Consult the references provided, specifically the Microsoft .NET API documentation and the Palantir article on event tracing, to deepen your understanding of the attack techniques and potential mitigations.

Suspicious CSC.exe Parent Process

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

Attackers are leveraging the legitimate Csc.exe (C# compiler) to execute malicious code, often as a part of defense evasion or payload delivery. This is achieved by spawning Csc.exe from unusual parent processes such as scripting hosts (cscript.exe, wscript.exe), Office applications (excel.exe, winword.exe), or PowerShell, especially when combined with encoded commands. Observed techniques also include launching Csc.exe from temporary or unusual directories. This activity bypasses traditional application whitelisting and can lead to the execution of arbitrary code. This activity has been associated with WarzoneRAT, DarkVNC, and the delivery of IMAPLoader malware.

Attack Chain

An attacker gains initial access, potentially through phishing or exploiting a vulnerability.
A script or Office macro executes, initiating a command-line process.
This process then invokes a scripting host (e.g., cscript.exe) or PowerShell.
The scripting host or PowerShell executes a command that downloads or creates a C# source code file.
Csc.exe is then invoked, often from a temporary directory, to compile the downloaded/created C# code.
The compiled C# code executes, performing malicious actions.
The malicious code may establish persistence, communicate with a C2 server, or perform data exfiltration.
The final objective might be to deploy ransomware, steal sensitive data, or establish a persistent backdoor.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to compromise systems, steal data, or deploy malware. Depending on the user’s permissions, the attacker could gain elevated privileges. The observed techniques have been associated with ransomware deployment, data theft, and remote access trojans (RATs).

Recommendation

Deploy the Sigma rule “Csc.EXE Execution Form Potentially Suspicious Parent” to detect suspicious parent processes of csc.exe.
Monitor process creation events for csc.exe with parent processes like scripting hosts or Office applications.
Investigate any instances of csc.exe being executed from temporary directories or user profile locations by reviewing process_creation logs.
Enable Sysmon process creation logging to capture detailed process information, including parent-child relationships, for effective detection.