Wsl — CraftedSignal Threat Feed

Windows Subsystem for Linux Distribution Installed via Registry Modification

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

Attackers may leverage the Windows Subsystem for Linux (WSL) to evade detection by operating within a Linux environment on a Windows host. The installation of a new WSL distribution involves specific registry modifications. This rule identifies such modifications, providing an alert when a new WSL distribution is installed. This is important for defenders as it could signal an attacker setting up a persistent and potentially hidden environment for malicious activities. WSL allows attackers to utilize Linux tools and techniques on a Windows system, potentially bypassing traditional Windows-based security measures.

Attack Chain

Initial Access: The attacker gains initial access to the Windows system through existing vulnerabilities or compromised credentials.
Privilege Escalation: The attacker elevates their privileges to perform system-level changes, including registry modifications.
WSL Installation: The attacker initiates the installation of a WSL distribution. This may involve downloading and executing a WSL installer package.
Registry Modification: During installation, the system modifies the registry to configure and register the new WSL distribution. Specifically, keys under HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Lxss\\ are created/modified.
WSL Environment Setup: The attacker configures the installed WSL distribution, potentially installing additional tools and software needed for their objectives.
Execution of Malicious Activities: The attacker executes malicious commands and scripts within the WSL environment, leveraging Linux tools to perform actions such as lateral movement, data exfiltration, or persistence.
Defense Evasion: The attacker utilizes WSL to evade detection, as traditional Windows-based security tools may not effectively monitor or analyze activity within the Linux subsystem.
Persistence: The attacker establishes persistence within the WSL environment, ensuring continued access to the compromised system even after reboots or security updates.

Impact

Successful exploitation allows attackers to establish a hidden and persistent environment within the compromised Windows system. This can lead to data theft, system compromise, and further propagation of the attack within the network. The number of victims and affected sectors depends on the scope and objectives of the attacker. The use of WSL for malicious purposes can significantly complicate incident response and remediation efforts.

Recommendation

Deploy the Sigma rule “Detect WSL Installation via Registry Modification” to your SIEM to detect new WSL installations by monitoring registry changes.
Enable Sysmon registry event logging to capture the necessary data for the Sigma rule to function correctly (see setup instructions in the rule description).
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the WSL installation and identify potential malicious activities.
Monitor for execution of suspicious processes within WSL environments, as described in “Execution via Windows Subsystem for Linux - db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd”.

Windows Subsystem for Linux Enabled via Dism Utility

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

Attackers may enable the Windows Subsystem for Linux (WSL) to run Linux applications and tools directly on Windows, potentially bypassing security controls and hindering detection. This involves using the Dism.exe utility to enable the “Microsoft-Windows-Subsystem-Linux” feature. By leveraging WSL, adversaries can execute malicious code, access Windows resources, and perform various malicious activities while blending in with legitimate system processes. The use of WSL provides an environment where traditional Windows-based security solutions may have limited visibility, thus offering a way to evade detection. This activity has been observed as a post-exploitation technique, used after initial access to a compromised system.

Attack Chain

An attacker gains initial access to a Windows system through methods such as phishing, exploiting vulnerabilities, or using compromised credentials.
The attacker executes Dism.exe (Deployment Image Servicing and Management tool).
Dism.exe is invoked with the command-line argument to enable the “Microsoft-Windows-Subsystem-Linux” feature.
The system processes the Dism.exe command and enables WSL.
The attacker installs a Linux distribution (e.g., Ubuntu, Kali) within the WSL environment.
The attacker uses the WSL environment to execute Linux-based tools and scripts for reconnaissance, lateral movement, or data exfiltration.
The attacker leverages the WSL environment to interact with Windows resources or execute Windows commands.
The attacker achieves their objective, such as stealing sensitive data or establishing persistence on the compromised system.

Impact

Successful enablement of WSL can lead to a compromised Windows system being used as a platform for Linux-based attacks. This can result in data theft, system compromise, and further propagation of malicious activity within the network. The use of WSL can make it difficult to detect malicious activity since it allows attackers to blend Linux-based attacks with normal Windows operations. The lack of visibility into the WSL environment by traditional Windows security tools can lead to prolonged periods of undetected malicious activity.

Recommendation

Monitor process creation events for the execution of Dism.exe with command-line arguments that include Microsoft-Windows-Subsystem-Linux to detect WSL enablement attempts (see Sigma rule Detect WSL Enablement via Dism).
Enable Sysmon process creation logging to capture detailed command-line information for processes, which is crucial for detecting this activity (Sysmon Event ID 1).
Implement the provided Sigma rule to detect suspicious usage of the DISM utility to enable WSL. Tune the rule based on your environment to minimize false positives.
Investigate any alerts generated by the Sigma rule Detect WSL Enablement via Dism to determine the legitimacy of the activity.
Monitor network connections originating from WSL processes for suspicious outbound traffic.
Consider blocking the execution of Dism.exe if WSL is not a sanctioned tool in your environment.

Host File System Changes via Windows Subsystem for Linux

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

The Windows Subsystem for Linux (WSL) allows users to run a Linux environment directly on Windows. Adversaries may exploit WSL to modify host files stealthily, bypassing traditional security measures and evading detection. This can be achieved by using WSL processes, especially those involving the Plan9FileSystem, to perform file operations on the host system. The detection rule identifies suspicious file operations initiated by dllhost.exe with the Plan9FileSystem CLSID “{DFB65C4C-B34F-435D-AFE9-A86218684AA8}” to flag potential defense evasion attempts. This technique can be employed to modify system configurations, plant malicious files, or exfiltrate sensitive data, while blending in with legitimate WSL usage. Elastic has observed this activity and published a detection rule to identify such events.

Attack Chain

An attacker gains initial access to a Windows system.
WSL is enabled on the target system, if not already enabled.
The attacker executes commands within the WSL environment.
dllhost.exe is spawned to facilitate file system operations between WSL and the host.
The attacker uses the Plan9FileSystem to interact with the Windows host file system.
Malicious files are created or existing files are modified on the host system using dllhost.exe.
These files may be placed in locations outside of typical user directories to avoid detection.
The attacker achieves their objective, such as data theft or further system compromise, using the modified files or configurations.

Impact

Successful exploitation can lead to the compromise of sensitive data, modification of critical system files, and the installation of malware on the Windows host. While the exact number of victims and sectors targeted are not specified, this technique allows attackers to bypass traditional security measures, making it difficult to detect malicious activity. The impact could range from data breaches to complete system compromise, depending on the attacker’s objectives.

Recommendation

Enable Sysmon process creation and file creation logging to capture the execution of dllhost.exe and file modifications (Sysmon Event ID 1 and 11).
Deploy the Sigma rule “Host File System Changes via Windows Subsystem for Linux” to your SIEM to detect suspicious file operations involving dllhost.exe and the Plan9FileSystem CLSID.
Exclude legitimate WSL development directories and processes from the detection rule to reduce false positives.
Monitor for processes and file operations involving dllhost.exe and the Plan9FileSystem, alerting on unusual activity.
Review and whitelist legitimate applications using WSL that may trigger alerts to prevent unnecessary notifications.

Execution via Windows Subsystem for Linux

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

This rule detects attempts to execute programs on the host from the Windows Subsystem for Linux (WSL). Adversaries may enable and use WSL for Linux to avoid detection by executing malicious scripts or binaries, bypassing traditional Windows security mechanisms. The rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion. This detection focuses on identifying when a process is spawned by wsl.exe or wslhost.exe and is not within a known good path. The rule is designed to work with data from Elastic Defend, Crowdstrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Security Event Logs.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker enables the Windows Subsystem for Linux (WSL).
The attacker transfers or creates malicious scripts or binaries within the WSL environment.
The attacker executes the malicious script or binary using a Linux shell within WSL, such as bash.
The WSL environment interacts with the Windows host to execute commands or access resources.
The executed commands perform malicious actions, such as data exfiltration or lateral movement.
The attacker leverages WSL’s integration with Windows to evade traditional Windows-based security measures.
The final objective is to compromise the system or network while remaining undetected.

Impact

Successful exploitation allows adversaries to execute malicious code while potentially evading traditional Windows-based security measures. This can lead to system compromise, data theft, or further propagation of malware within the network. The rule’s medium severity reflects the potential for significant impact, necessitating prompt investigation and response.

Recommendation

Deploy the Sigma rule Execution via Windows Subsystem for Linux to your SIEM to detect potential malicious activity originating from WSL.
Enable Sysmon process creation logging (Event ID 1) or Windows process creation logs to provide the necessary data for the Sigma rule to function.
Investigate any alerts generated by the Sigma rule, focusing on identifying the executed process, parent process (wsl.exe or wslhost.exe), and associated user account.
Correlate alerts with other security events from Microsoft Defender XDR, SentinelOne, or Crowdstrike to identify related suspicious activities or patterns.
Implement exceptions for known administrative scripts or development tools that are frequently executed via WSL to reduce false positives, as outlined in the rule’s analysis.
Monitor the WSL configuration and installed Linux distributions on affected systems to identify unauthorized changes or installations.

Detection of Kali Linux Installation or Usage via Windows Subsystem for Linux (WSL)

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

This detection identifies attempts to install or utilize Kali Linux through the Windows Subsystem for Linux (WSL). Attackers may leverage WSL to deploy Kali Linux as a means of circumventing traditional security measures and carrying out malicious operations within a Windows operating system. This behavior enables them to potentially blend their activities with legitimate WSL usage, making detection more challenging. The detection focuses on identifying specific processes and command-line arguments associated with Kali Linux installations and executions within the WSL environment, aiming to expose malicious actors utilizing this technique for nefarious purposes. This activity started being tracked in early 2023. Defenders should be aware of this technique, as it can be used to bypass security controls and perform malicious activities discreetly.

Attack Chain

An attacker gains initial access to a Windows system through methods outside the scope of this specific detection (e.g., phishing, exploitation of a vulnerability).
The attacker enables WSL on the target Windows system using PowerShell or command-line tools.
The attacker downloads the Kali Linux distribution for WSL from the Microsoft Store or another source.
The attacker uses wsl.exe with arguments like -d, --distribution, -i, or --install along with “kali*” to install the Kali Linux distribution.
Alternatively, the attacker directly executes the kali.exe binary located within the Kali Linux package path (e.g., C:\\Users\\*\\AppData\\Local\\packages\\kalilinux*).
Once Kali Linux is installed, the attacker uses it to perform various malicious activities, such as penetration testing, vulnerability scanning, or exploiting other systems on the network.
The attacker may leverage tools and utilities within Kali Linux to escalate privileges, move laterally, or exfiltrate sensitive data.
The final objective is typically to compromise the target system or network, steal valuable information, or disrupt operations.

Impact

A successful attack using Kali Linux within WSL can lead to significant damage, including data breaches, system compromise, and disruption of services. The use of Kali Linux provides attackers with a wide range of tools and capabilities for reconnaissance, exploitation, and post-exploitation activities. Depending on the attacker’s objectives, this can result in financial losses, reputational damage, and legal liabilities. Organizations across various sectors are vulnerable, as this technique can be used against any Windows system with WSL enabled.

Recommendation

Deploy the Sigma rule “Detect Kali Linux Installation via WSL” to your SIEM to detect the use of wsl.exe with specific Kali Linux installation arguments (rule).
Deploy the Sigma rule “Detect Kali Linux Executable via WSL” to your SIEM to detect the direct execution of kali.exe from the common install directories (rule).
Monitor process creation events for the execution of wsl.exe and kali.exe within the Windows environment (logsource).
Review and restrict the usage of WSL within the organization to only authorized users and systems (overview).
Implement application control policies to prevent the execution of unauthorized binaries, including kali.exe (overview).