Execution via Windows Subsystem for Linux

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

1. An attacker gains initial access to a Windows system.
2. The attacker enables the Windows Subsystem for Linux (WSL).
3. The attacker transfers or creates malicious scripts or binaries within the WSL environment.
4. The attacker executes the malicious script or binary using a Linux shell within WSL, such as bash.
5. The WSL environment interacts with the Windows host to execute commands or access resources.
6. The executed commands perform malicious actions, such as data exfiltration or lateral movement.
7. The attacker leverages WSL’s integration with Windows to evade traditional Windows-based security measures.
8. 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.