Suspicious Execution via Windows Subsystem for Linux
Detects Linux Bash commands 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/13"
3integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects Linux Bash commands from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to
11avoid detection.
12"""
13from = "now-9m"
14index = [
15 "winlogbeat-*",
16 "logs-endpoint.events.process-*",
17 "logs-windows.sysmon_operational-*",
18 "endgame-*",
19 "logs-m365_defender.event-*",
20 "logs-sentinel_one_cloud_funnel.*",
21]
22language = "eql"
23license = "Elastic License v2"
24name = "Suspicious Execution via Windows Subsystem for Linux"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> 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.
29
30### Investigating Suspicious Execution via Windows Subsystem for Linux
31
32Windows 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 Linux commands stealthily, bypassing traditional Windows security measures. The detection rule identifies unusual WSL activity by monitoring specific executable paths, command-line arguments, and parent-child process relationships, flagging deviations from typical usage patterns to uncover potential threats.
33
34### Possible investigation steps
35
36- Review the process command line and executable path to determine if the execution of bash.exe or any other Linux binaries is expected or authorized for the user or system in question.
37- Investigate the parent-child process relationship, especially focusing on whether wsl.exe is the parent process and if it has spawned any unexpected child processes that are not wslhost.exe.
38- Examine the command-line arguments used with wsl.exe for any suspicious or unauthorized commands, such as accessing sensitive files like /etc/shadow or /etc/passwd, or using network tools like curl.
39- Check the user's activity history and system logs to identify any patterns of behavior that might indicate misuse or compromise, particularly focusing on any deviations from typical usage patterns.
40- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender XDR, or Sysmon to gather additional context and determine if this is part of a broader attack or isolated incident.
41
42### False positive analysis
43
44- Frequent use of WSL for legitimate development tasks may trigger alerts. Users can create exceptions for specific user accounts or directories commonly used for development to reduce noise.
45- Automated scripts or tools that utilize WSL for system maintenance or monitoring might be flagged. Identify these scripts and whitelist their specific command-line patterns or parent processes.
46- Docker-related processes may cause false positives due to their interaction with WSL. Exclude Docker executable paths from the detection rule to prevent unnecessary alerts.
47- Visual Studio Code extensions that interact with WSL can generate alerts. Exclude known non-threatening extensions by specifying their command-line arguments in the exception list.
48- Regular system updates or administrative tasks that involve WSL might be misidentified. Document these activities and adjust the detection rule to recognize them as benign.
49
50### Response and remediation
51
52- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
53- Terminate any suspicious processes identified by the detection rule, such as those involving bash.exe or wsl.exe with unusual command-line arguments.
54- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify any unauthorized changes or installations.
55- Remove any unauthorized or suspicious Linux binaries or scripts found within the WSL environment.
56- Reset credentials for any accounts that may have been compromised, especially if sensitive files like /etc/shadow or /etc/passwd were accessed.
57- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
58- Implement enhanced monitoring and logging for WSL activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon."""
59references = [
60 "https://blog.f-secure.com/hunting-for-windows-subsystem-for-linux/",
61 "https://lolbas-project.github.io/lolbas/OtherMSBinaries/Wsl/",
62 "https://blog.qualys.com/vulnerabilities-threat-research/2022/03/22/implications-of-windows-subsystem-for-linux-for-adversaries-defenders-part-1",
63]
64risk_score = 21
65rule_id = "3e0eeb75-16e8-4f2f-9826-62461ca128b7"
66severity = "low"
67tags = [
68 "Domain: Endpoint",
69 "OS: Windows",
70 "Use Case: Threat Detection",
71 "Tactic: Execution",
72 "Tactic: Defense Evasion",
73 "Data Source: Elastic Endgame",
74 "Data Source: Elastic Defend",
75 "Data Source: Microsoft Defender XDR",
76 "Data Source: Sysmon",
77 "Data Source: SentinelOne",
78 "Resources: Investigation Guide",
79 "Noise: High",
80 "Performance: Normal",
81 "Profile: Aggressive",
82 "Rule Type: Event Correlation (EQL)",
83 "Platform: Windows",
84]
85timestamp_override = "event.ingested"
86type = "eql"
87
88query = '''
89process where host.os.type == "windows" and event.type : "start" and
90 (
91 (
92 (process.executable : "?:\\Windows\\System32\\bash.exe" or ?process.pe.original_file_name == "Bash.exe") and
93 not process.command_line : ("bash", "bash.exe")
94 ) or
95 process.executable : "?:\\Users\\*\\AppData\\Local\\Packages\\*\\rootfs\\usr\\bin\\bash" or
96 (
97 process.parent.name : "wsl.exe" and process.parent.command_line : "bash*" and not process.name : "wslhost.exe"
98 ) or
99 (
100 process.name : "wsl.exe" and
101 (
102 process.args : "--system" or
103 (
104 process.args : "--manage" and process.args : "--set-default-user" and process.args : "root"
105 ) or
106 (
107 (process.args : ("curl", "wget") and process.args : ("http://*", "https://*")) or
108 process.args : ("*curl*http://*", "*curl*https://*", "*wget*http://*", "*wget*https://*")
109 ) or
110 (
111 (
112 process.args like~ ("*/dev/tcp/*", "*/dev/udp/*", "*zsh/net/tcp*") and
113 process.args like ("*&>*", "*<>*", "*>&*", "*<&*")
114 ) or
115 (
116 process.args : ("nc", "netcat", "nc.traditional", "ncat", "*/nc", "*/netcat", "*/nc.traditional", "*/ncat") and
117 process.args : ("sh", "/bin/sh", "bash", "/bin/bash") and
118 process.args : ("-e", "--exec", "-c", "--sh-exec")
119 ) or
120 (
121 process.args like~ "*socat*" and
122 process.args like~ ("*exec:*", "*system:*", "*shell:*") and
123 process.args like~ ("*tcp*", "*udp*", "*openssl*")
124 )
125 ) or
126 (
127 process.args : ("-e", "--exec") and
128 process.args : (
129 "/mnt/c/*.exe", "/mnt/c/*.ps1", "/mnt/c/*.bat", "/mnt/c/*.cmd", "/mnt/c/*.vbs", "/mnt/c/*.js",
130 "/mnt/c/*.hta"
131 ) and
132 not process.args : "*wslpath*"
133 ) or
134 process.args : (
135 "*/etc/passwd*", "*/etc/shadow*", "*/etc/sudoers*", "*/etc/sudoers.d/*", "*/root/.ssh/*", "*/home/*/.ssh/*",
136 "*/root/.aws/credentials*", "*/home/*/.aws/credentials*", "*/root/.kube/config*", "*/home/*/.kube/config*",
137 "*/mnt/c/Windows/System32/config/SAM*",
138 "*/mnt/c/Windows/System32/config/SECURITY*",
139 "*/mnt/c/Windows/System32/config/SYSTEM", "*/mnt/c/Windows/System32/config/SYSTEM.*",
140 "*/mnt/c/Windows/NTDS/ntds.dit*",
141 "*/mnt/c/Users/*/AppData/Roaming/Microsoft/Credentials/*",
142 "*/mnt/c/Users/*/AppData/Local/Microsoft/Credentials/*",
143 "*/mnt/c/Users/*/AppData/Roaming/Microsoft/Protect/*",
144 "*/mnt/c/Users/*/.ssh/*",
145 "*/mnt/c/Users/*/.aws/credentials",
146 "*/mnt/c/Users/*/.azure/*",
147 "*/mnt/c/Users/*/.config/gcloud/*",
148 "*/mnt/c/Users/*/AppData/Local/Google/Chrome/User Data/*/Login Data*",
149 "*/mnt/c/Users/*/AppData/Local/Microsoft/Edge/User Data/*/Login Data*"
150 )
151 )
152 )
153 ) and
154 not process.parent.executable : ("?:\\Program Files\\Docker\\*.exe", "?:\\Program Files (x86)\\Docker\\*.exe")
155'''
156
157setup = """## Setup
158
159This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
160
161Setup instructions: https://ela.st/install-elastic-defend
162
163### Additional data sources
164
165This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
166
167- [Microsoft Defender XDR](https://ela.st/m365-defender)
168- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
169- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
170"""
171
172
173[[rule.threat]]
174framework = "MITRE ATT&CK"
175
176[[rule.threat.technique]]
177id = "T1202"
178name = "Indirect Command Execution"
179reference = "https://attack.mitre.org/techniques/T1202/"
180
181[rule.threat.tactic]
182id = "TA0005"
183name = "Defense Evasion"
184reference = "https://attack.mitre.org/tactics/TA0005/"
185
186[[rule.threat]]
187framework = "MITRE ATT&CK"
188
189[[rule.threat.technique]]
190id = "T1059"
191name = "Command and Scripting Interpreter"
192reference = "https://attack.mitre.org/techniques/T1059/"
193
194[[rule.threat.technique.subtechnique]]
195id = "T1059.004"
196name = "Unix Shell"
197reference = "https://attack.mitre.org/techniques/T1059/004/"
198
199[rule.threat.tactic]
200id = "TA0002"
201name = "Execution"
202reference = "https://attack.mitre.org/tactics/TA0002/"
203
204[[rule.threat]]
205framework = "MITRE ATT&CK"
206
207[[rule.threat.technique]]
208id = "T1003"
209name = "OS Credential Dumping"
210reference = "https://attack.mitre.org/techniques/T1003/"
211
212[[rule.threat.technique.subtechnique]]
213id = "T1003.008"
214name = "/etc/passwd and /etc/shadow"
215reference = "https://attack.mitre.org/techniques/T1003/008/"
216
217[rule.threat.tactic]
218id = "TA0006"
219name = "Credential Access"
220reference = "https://attack.mitre.org/tactics/TA0006/"
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 Suspicious 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 Linux commands stealthily, bypassing traditional Windows security measures. The detection rule identifies unusual WSL activity by monitoring specific executable paths, command-line arguments, and parent-child process relationships, flagging deviations from typical usage patterns to uncover potential threats.
Possible investigation steps
- Review the process command line and executable path to determine if the execution of bash.exe or any other Linux binaries is expected or authorized for the user or system in question.
- Investigate the parent-child process relationship, especially focusing on whether wsl.exe is the parent process and if it has spawned any unexpected child processes that are not wslhost.exe.
- Examine the command-line arguments used with wsl.exe for any suspicious or unauthorized commands, such as accessing sensitive files like /etc/shadow or /etc/passwd, or using network tools like curl.
- Check the user's activity history and system logs to identify any patterns of behavior that might indicate misuse or compromise, particularly focusing on any deviations from typical usage patterns.
- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender XDR, or Sysmon to gather additional context and determine if this is part of a broader attack or isolated incident.
False positive analysis
- Frequent use of WSL for legitimate development tasks may trigger alerts. Users can create exceptions for specific user accounts or directories commonly used for development to reduce noise.
- Automated scripts or tools that utilize WSL for system maintenance or monitoring might be flagged. Identify these scripts and whitelist their specific command-line patterns or parent processes.
- Docker-related processes may cause false positives due to their interaction with WSL. Exclude Docker executable paths from the detection rule to prevent unnecessary alerts.
- Visual Studio Code extensions that interact with WSL can generate alerts. Exclude known non-threatening extensions by specifying their command-line arguments in the exception list.
- Regular system updates or administrative tasks that involve WSL might be misidentified. Document these activities and adjust the detection rule to recognize them as benign.
Response and remediation
- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious processes identified by the detection rule, such as those involving bash.exe or wsl.exe with unusual command-line arguments.
- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify any unauthorized changes or installations.
- Remove any unauthorized or suspicious Linux binaries or scripts found within the WSL environment.
- Reset credentials for any accounts that may have been compromised, especially if sensitive files like /etc/shadow or /etc/passwd were accessed.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring and logging for WSL activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon.
References
Related rules
- Disabling Windows Defender Security Settings via PowerShell
- Potential DLL Side-Loading via Trusted Microsoft Programs
- Clearing Windows Event Logs
- Code Signing Policy Modification Through Registry
- Disabling Lsa Protection via Registry Modification