Execution via Windows Subsystem for Linux
Detects attempts to execute a program on the host from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/01/12"
3integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
4maturity = "production"
5updated_date = "2025/01/15"
6min_stack_version = "8.14.0"
7min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
8
9[rule]
10author = ["Elastic"]
11description = """
12Detects attempts to execute a program on the host from the Windows Subsystem for Linux. Adversaries may enable and use
13WSL for Linux to avoid detection.
14"""
15from = "now-9m"
16index = [
17 "winlogbeat-*",
18 "logs-endpoint.events.process-*",
19 "logs-windows.*",
20 "endgame-*",
21 "logs-system.security*",
22 "logs-m365_defender.event-*",
23 "logs-sentinel_one_cloud_funnel.*",
24 "logs-crowdstrike.fdr*",
25]
26language = "eql"
27license = "Elastic License v2"
28name = "Execution via Windows Subsystem for Linux"
29references = ["https://learn.microsoft.com/en-us/windows/wsl/wsl-config"]
30risk_score = 47
31rule_id = "db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd"
32severity = "medium"
33tags = [
34 "Domain: Endpoint",
35 "OS: Windows",
36 "Use Case: Threat Detection",
37 "Tactic: Defense Evasion",
38 "Data Source: Elastic Endgame",
39 "Data Source: Elastic Defend",
40 "Data Source: System",
41 "Data Source: Microsoft Defender for Endpoint",
42 "Data Source: SentinelOne",
43 "Data Source: Crowdstrike",
44 "Resources: Investigation Guide",
45]
46timestamp_override = "event.ingested"
47type = "eql"
48
49query = '''
50process where host.os.type == "windows" and event.type : "start" and
51 process.parent.name : ("wsl.exe", "wslhost.exe") and
52 not process.executable : (
53 "?:\\Program Files (x86)\\*",
54 "?:\\Program Files\\*",
55 "?:\\Program Files*\\WindowsApps\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\wsl*.exe",
56 "?:\\Windows\\System32\\conhost.exe",
57 "?:\\Windows\\System32\\lxss\\wslhost.exe",
58 "?:\\Windows\\System32\\WerFault.exe",
59 "?:\\Windows\\Sys?????\\wslconfig.exe"
60 ) and
61 not (
62 event.dataset == "crowdstrike.fdr" and
63 process.executable : (
64 "\\Device\\HarddiskVolume?\\Program Files (x86)\\*",
65 "\\Device\\HarddiskVolume?\\Program Files\\*",
66 "\\Device\\HarddiskVolume?\\Program Files*\\WindowsApps\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\wsl*.exe",
67 "\\Device\\HarddiskVolume?\\Windows\\System32\\conhost.exe",
68 "\\Device\\HarddiskVolume?\\Windows\\System32\\lxss\\wslhost.exe",
69 "\\Device\\HarddiskVolume?\\Windows\\System32\\WerFault.exe",
70 "\\Device\\HarddiskVolume?\\Windows\\Sys?????\\wslconfig.exe"
71 )
72 )
73'''
74note = """## Triage and analysis
75
76> **Disclaimer**:
77> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
78
79### Investigating Execution via Windows Subsystem for Linux
80
81Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute malicious scripts or binaries, bypassing traditional Windows security mechanisms. The detection rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion.
82
83### Possible investigation steps
84
85- Review the process details to identify the executable path and determine if it matches any known malicious or suspicious binaries not listed in the safe executables.
86- Investigate the parent process, specifically wsl.exe or wslhost.exe, to understand how the execution was initiated and if it aligns with expected user behavior or scheduled tasks.
87- Check the user account associated with the process execution to verify if the activity is consistent with the user's typical behavior or if the account may have been compromised.
88- Analyze the event dataset, especially if it is from crowdstrike.fdr, to gather additional context about the process execution and any related activities on the host.
89- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or SentinelOne to identify any related suspicious activities or patterns.
90- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response actions accordingly.
91
92### False positive analysis
93
94- Legitimate administrative tasks using WSL may trigger alerts. Users can create exceptions for known administrative scripts or binaries that are frequently executed via WSL.
95- Development environments often use WSL for compiling or testing code. Exclude specific development tools or scripts that are regularly used by developers to prevent unnecessary alerts.
96- Automated system maintenance scripts running through WSL can be mistaken for malicious activity. Identify and whitelist these scripts to reduce false positives.
97- Security tools or monitoring solutions that leverage WSL for legitimate purposes should be identified and excluded from detection to avoid interference with their operations.
98- Frequent use of WSL by specific users or groups for non-malicious purposes can be managed by creating user-based exceptions, allowing their activities to proceed without triggering alerts.
99
100### Response and remediation
101
102- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
103- Terminate any suspicious processes identified as being executed via WSL that are not part of the known safe executables list.
104- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify unauthorized changes or installations.
105- Remove any unauthorized or malicious scripts and binaries found within the WSL environment.
106- Restore the system from a known good backup if malicious activity has compromised system integrity.
107- Update and patch the system to ensure all software, including WSL, is up to date to mitigate known vulnerabilities.
108- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
109
110
111[[rule.threat]]
112framework = "MITRE ATT&CK"
113[[rule.threat.technique]]
114id = "T1202"
115name = "Indirect Command Execution"
116reference = "https://attack.mitre.org/techniques/T1202/"
117
118
119[rule.threat.tactic]
120id = "TA0005"
121name = "Defense Evasion"
122reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating Execution via Windows Subsystem for Linux
Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute malicious scripts or binaries, bypassing traditional Windows security mechanisms. The detection rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion.
Possible investigation steps
- Review the process details to identify the executable path and determine if it matches any known malicious or suspicious binaries not listed in the safe executables.
- Investigate the parent process, specifically wsl.exe or wslhost.exe, to understand how the execution was initiated and if it aligns with expected user behavior or scheduled tasks.
- Check the user account associated with the process execution to verify if the activity is consistent with the user's typical behavior or if the account may have been compromised.
- Analyze the event dataset, especially if it is from crowdstrike.fdr, to gather additional context about the process execution and any related activities on the host.
- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or SentinelOne to identify any related suspicious activities or patterns.
- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response actions accordingly.
False positive analysis
- Legitimate administrative tasks using WSL may trigger alerts. Users can create exceptions for known administrative scripts or binaries that are frequently executed via WSL.
- Development environments often use WSL for compiling or testing code. Exclude specific development tools or scripts that are regularly used by developers to prevent unnecessary alerts.
- Automated system maintenance scripts running through WSL can be mistaken for malicious activity. Identify and whitelist these scripts to reduce false positives.
- Security tools or monitoring solutions that leverage WSL for legitimate purposes should be identified and excluded from detection to avoid interference with their operations.
- Frequent use of WSL by specific users or groups for non-malicious purposes can be managed by creating user-based exceptions, allowing their activities to proceed without triggering alerts.
Response and remediation
- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified as being executed via WSL that are not part of the known safe executables list.
- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify unauthorized changes or installations.
- Remove any unauthorized or malicious scripts and binaries found within the WSL environment.
- Restore the system from a known good backup if malicious activity has compromised system integrity.
- Update and patch the system to ensure all software, including WSL, is up to date to mitigate known vulnerabilities.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
References
Related rules
- Attempt to Install Kali Linux via WSL
- Control Panel Process with Unusual Arguments
- ImageLoad via Windows Update Auto Update Client
- Microsoft Build Engine Started by a System Process
- Potential File Transfer via Certreq