Attempt to Install or Run Kali Linux via WSL

Detects attempts to install or use Kali Linux via 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 = "2026/04/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects attempts to install or use Kali Linux via Windows Subsystem for Linux. Adversaries may enable and use WSL for
 11Linux to avoid detection.
 12"""
 13from = "now-9m"
 14index = [
 15    "endgame-*",
 16    "logs-crowdstrike.fdr*",
 17    "logs-endpoint.events.process-*",
 18    "logs-m365_defender.event-*",
 19    "logs-sentinel_one_cloud_funnel.*",
 20    "logs-system.security*",
 21    "logs-windows.forwarded*",
 22    "logs-windows.sysmon_operational-*",
 23    "winlogbeat-*",
 24]
 25language = "eql"
 26license = "Elastic License v2"
 27name = "Attempt to Install or Run Kali Linux via WSL"
 28references = [
 29    "https://learn.microsoft.com/en-us/windows/wsl/basic-commands",
 30    "https://learn.microsoft.com/en-us/windows/wsl/wsl-config",
 31]
 32risk_score = 73
 33rule_id = "dd34b062-b9e3-4a6b-8c0c-6c8ca6dd450e"
 34severity = "high"
 35tags = [
 36    "Domain: Endpoint",
 37    "OS: Windows",
 38    "Use Case: Threat Detection",
 39    "Tactic: Defense Evasion",
 40    "Data Source: Elastic Endgame",
 41    "Data Source: Elastic Defend",
 42    "Data Source: Windows Security Event Logs",
 43    "Data Source: Microsoft Defender XDR",
 44    "Data Source: Sysmon",
 45    "Data Source: SentinelOne",
 46    "Data Source: Crowdstrike",
 47    "Resources: Investigation Guide",
 48]
 49timestamp_override = "event.ingested"
 50type = "eql"
 51
 52query = '''
 53process where host.os.type == "windows" and event.type == "start" and
 54(
 55  (process.name : "wsl.exe" and process.args : ("-d", "--distribution", "-i", "--install") and process.args : "kali*") or
 56  process.executable : (
 57    "?:\\Users\\*\\AppData\\Local\\packages\\kalilinux*",
 58    "?:\\Users\\*\\AppData\\Local\\Microsoft\\WindowsApps\\kali.exe",
 59    "?:\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe",
 60
 61    /* Crowdstrike specific exclusion as it uses NT Object paths */
 62    "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Local\\packages\\kalilinux*",
 63    "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Local\\Microsoft\\WindowsApps\\kali.exe",
 64    "\\Device\\HarddiskVolume*\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe"
 65  )
 66)
 67'''
 68
 69note = """## Triage and analysis
 70
 71### Investigating Attempt to Install or Run Kali Linux via WSL
 72
 73#### Possible investigation steps
 74
 75- What Kali/WSL behavior path did the alert prove?
 76  - Focus: alert-local `process.name`, `process.executable`, and `process.args`, separating "wsl.exe" Kali install or distro arguments from direct Kali package-path execution.
 77  - Hint: do not require install flags before escalating; an installed Kali distro may appear only as direct package-path launcher execution.
 78  - Implication: escalate when "wsl.exe" selects or installs Kali with "-d", "--distribution", "-i", or "--install", or when `process.executable` runs from KaliLinux package or WindowsApps paths without a confirmed endpoint exception; lower suspicion only when exact user, host, parent, and command path match the same previously confirmed Kali/WSL workflow.
 79- Is the launcher identity and parent chain credible, or does it suggest masquerading or hands-on abuse?
 80  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.command_line`.
 81  - Implication: escalate when unsigned, renamed, running from a user-writable non-package path, or launched by Office, browser, script, or unexpected remote-admin tooling; lower suspicion when signed Microsoft or Store WSL identity and parent workflow both fit recognized Kali/WSL use. Identity alone does not clear the behavior.
 82- Which account and Windows session started Kali or "wsl.exe", and does that fit the endpoint cohort?
 83  - Focus: `user.id`, `user.name`, `host.id`, and `process.Ext.session_info.logon_type`.
 84  - Implication: escalate when a non-admin user, service account, or remote/service logon starts Kali on a workstation or server cohort that does not normally run WSL; lower suspicion when account, logon type, and endpoint cohort align with a recognized developer, lab, training, or image-build pattern.
 85- Did process telemetry show WSL lifecycle or configuration intent around the alert?
 86  - Focus: surrounding process starts on `host.id`, using `process.Ext.ancestry`, `process.command_line`, and `process.parent.command_line`.
 87  - Hint: prefer `host.id` plus `process.entity_id`; if unavailable, use `host.id`, `process.pid`, and a tight alert-time window because PID reuse can mislead process recovery. $investigate_2 $investigate_4
 88  - Implication: escalate when `process.command_line` shows WSL install, shutdown, terminate, configuration editing, or stop/relaunch in the same lineage; lower suspicion when surrounding starts show only one previously confirmed distro launch and no lifecycle or configuration intent.
 89- Did Kali/WSL lead to Windows-visible follow-on execution?
 90  - Focus: child or descendant starts tied by `process.parent.entity_id` or `process.Ext.ancestry` to the alert process, reviewing `process.executable` and `process.command_line`.
 91  - Hint: direct child starts are high-confidence pivots; manually expand ancestry when WSL launches through intermediate hosts. $investigate_3
 92  - Implication: escalate for shells, archivers, credential tools, scanners, tunneling clients, Windows interop launches, or repeated distro starts; lower suspicion when visible follow-on activity stays limited to recognized setup or status commands.
 93- If local evidence remains suspicious or unresolved, is the same user or host repeating Kali/WSL activity elsewhere?
 94  - Focus: related alerts and recent process starts scoped by `user.id` or `host.id`, compared with the suspicious `process.executable` and `process.parent.command_line` pattern.
 95  - Hint: review user or host alerts only after local Kali/WSL evidence stays suspicious or unresolved. $investigate_0 $investigate_1
 96  - Implication: expand scope when the same user, host, parent chain, or Kali/WSL argument pattern appears on other endpoints or repeats outside the recognized workflow; keep scope local when exact activity stays confined to one recognized endpoint and bounded window, but do not close a suspicious local alert from recurrence alone.
 97- Escalate for unsupported user/host, suspicious launcher, masqueraded binary, lifecycle/configuration activity, offensive follow-on process, or spread; close only when process evidence binds to one exact recognized workflow with no contradictions; preserve evidence and escalate when mixed or incomplete.
 98
 99### False positive analysis
100
101- Developer, security-lab, training, red-team, provisioning, or image-build systems can legitimately run or install Kali under WSL. First confirm process telemetry ties `user.id` or `host.id` cohort, `process.executable`, `process.args` or package path, `process.parent.command_line`, and signer or hash identity to the same recognized workflow, with no unexpected WSL stop/relaunch, tooling, or follow-on activity. Use rosters, training, build records, owner confirmation, or inventory only as corroboration after process evidence matches; if they conflict or telemetry is incomplete, do not close as benign.
102- If workflow context is missing, keep the alert unresolved unless process telemetry proves the exact same bounded user/host, parent, binary identity, and Kali argument or package-path pattern with no contradictory lifecycle or follow-on evidence.
103- Before creating an exception, require recurrence for the minimum confirmed pattern: `user.id` or `host.id` cohort, `process.executable`, `process.code_signature.subject_name` or `process.hash.sha256`, `process.parent.command_line`, and the Kali-specific `process.args` or package-path `process.executable`. Avoid exceptions on `process.name`, the substring "kali", or "kali.exe" alone.
104
105### Response and remediation
106
107- If confirmed benign, reverse temporary containment and document the exact workflow evidence: user and host cohort, launcher path, signer or hash identity, parent command line, and Kali argument or package-path pattern. Create an exception only after the same bounded pattern recurs without contradictory follow-on behavior.
108- If suspicious but unconfirmed, export the alert and surrounding process timeline, preserve process instance IDs, command lines, binary identity, user/host/session anchors, and any WSL configuration or package paths visible in process telemetry before containment. Apply reversible containment first, such as terminating the active Kali or "wsl.exe" process, disabling the initiating account's WSL access, or running "wsl --shutdown" when operationally safe. Escalate to host isolation only if the activity spreads, reconfigures WSL, or launches offensive tooling.
109- If confirmed malicious, isolate the endpoint when the identity, lineage, lifecycle, or follow-on process evidence shows active abuse. Before cleanup, record the Kali/WSL process identity, parent chain, affected `user.id` and `host.id`, package paths, and WSL configuration paths seen in command lines. Then stop active WSL instances, remove the unauthorized Kali distribution and WSL configuration changes, reset credentials exposed to the Kali environment, and scope other endpoints for the same user, launcher identity, or package-path pattern.
110- Post-incident hardening should decide whether WSL is permitted for the affected endpoint cohort, restrict who can install or run WSL distributions, and retain process telemetry for Kali package paths, ".wslconfig", "wsl.conf", and "wsl.exe" lifecycle commands.
111"""
112
113setup = """## Setup
114
115This 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.
116
117Setup instructions: https://ela.st/install-elastic-defend
118
119### Additional data sources
120
121This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
122
123- [CrowdStrike](https://ela.st/crowdstrike-integration)
124- [Microsoft Defender XDR](https://ela.st/m365-defender)
125- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
126- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
127- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
128"""
129
130[rule.investigation_fields]
131field_names = [
132    "@timestamp",
133    "host.name",
134    "host.id",
135    "user.name",
136    "user.id",
137    "process.entity_id",
138    "process.executable",
139    "process.command_line",
140    "process.args",
141    "process.pe.original_file_name",
142    "process.code_signature.trusted",
143    "process.code_signature.subject_name",
144    "process.Ext.session_info.logon_type",
145    "process.parent.entity_id",
146    "process.parent.command_line",
147]
148
149[transform]
150
151[[transform.investigate]]
152label = "Alerts associated with the user"
153description = ""
154providers = [
155  [
156    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
157    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
158  ]
159]
160relativeFrom = "now-48h/h"
161relativeTo = "now"
162
163[[transform.investigate]]
164label = "Alerts associated with the host"
165description = ""
166providers = [
167  [
168    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
169    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
170  ]
171]
172relativeFrom = "now-48h/h"
173relativeTo = "now"
174
175[[transform.investigate]]
176label = "Same-parent process starts on this host"
177description = ""
178providers = [
179  [
180    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" },
181    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
182    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
183    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }
184  ]
185]
186relativeFrom = "now-1h"
187relativeTo = "now"
188
189[[transform.investigate]]
190label = "Child process starts from the Kali or WSL process"
191description = ""
192providers = [
193  [
194    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
195    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
196    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
197    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }
198  ]
199]
200relativeFrom = "now-1h"
201relativeTo = "now"
202
203[[transform.investigate]]
204label = "WSL lifecycle commands on this host"
205description = ""
206providers = [
207  [
208    { excluded = false, field = "process.name", queryType = "phrase", value = "wsl.exe", valueType = "string" },
209    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
210    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
211    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }
212  ]
213]
214relativeFrom = "now-1h"
215relativeTo = "now"
216
217[[rule.threat]]
218framework = "MITRE ATT&CK"
219
220[[rule.threat.technique]]
221id = "T1202"
222name = "Indirect Command Execution"
223reference = "https://attack.mitre.org/techniques/T1202/"
224
225[rule.threat.tactic]
226id = "TA0005"
227name = "Defense Evasion"
228reference = "https://attack.mitre.org/tactics/TA0005/"
229
230[[rule.threat]]
231framework = "MITRE ATT&CK"
232
233[[rule.threat.technique]]
234id = "T1059"
235name = "Command and Scripting Interpreter"
236reference = "https://attack.mitre.org/techniques/T1059/"
237
238[[rule.threat.technique.subtechnique]]
239id = "T1059.004"
240name = "Unix Shell"
241reference = "https://attack.mitre.org/techniques/T1059/004/"
242
243[rule.threat.tactic]
244id = "TA0002"
245name = "Execution"
246reference = "https://attack.mitre.org/tactics/TA0002/"

Triage and analysis

Investigating Attempt to Install or Run Kali Linux via WSL

Possible investigation steps

  • What Kali/WSL behavior path did the alert prove?
    • Focus: alert-local process.name, process.executable, and process.args, separating "wsl.exe" Kali install or distro arguments from direct Kali package-path execution.
    • Hint: do not require install flags before escalating; an installed Kali distro may appear only as direct package-path launcher execution.
    • Implication: escalate when "wsl.exe" selects or installs Kali with "-d", "--distribution", "-i", or "--install", or when process.executable runs from KaliLinux package or WindowsApps paths without a confirmed endpoint exception; lower suspicion only when exact user, host, parent, and command path match the same previously confirmed Kali/WSL workflow.
  • Is the launcher identity and parent chain credible, or does it suggest masquerading or hands-on abuse?
    • Focus: process.executable, process.pe.original_file_name, process.code_signature.subject_name, and process.parent.command_line.
    • Implication: escalate when unsigned, renamed, running from a user-writable non-package path, or launched by Office, browser, script, or unexpected remote-admin tooling; lower suspicion when signed Microsoft or Store WSL identity and parent workflow both fit recognized Kali/WSL use. Identity alone does not clear the behavior.
  • Which account and Windows session started Kali or "wsl.exe", and does that fit the endpoint cohort?
    • Focus: user.id, user.name, host.id, and process.Ext.session_info.logon_type.
    • Implication: escalate when a non-admin user, service account, or remote/service logon starts Kali on a workstation or server cohort that does not normally run WSL; lower suspicion when account, logon type, and endpoint cohort align with a recognized developer, lab, training, or image-build pattern.
  • Did process telemetry show WSL lifecycle or configuration intent around the alert?
    • Focus: surrounding process starts on host.id, using process.Ext.ancestry, process.command_line, and process.parent.command_line.
    • Hint: prefer host.id plus process.entity_id; if unavailable, use host.id, process.pid, and a tight alert-time window because PID reuse can mislead process recovery. $investigate_2 $investigate_4
    • Implication: escalate when process.command_line shows WSL install, shutdown, terminate, configuration editing, or stop/relaunch in the same lineage; lower suspicion when surrounding starts show only one previously confirmed distro launch and no lifecycle or configuration intent.
  • Did Kali/WSL lead to Windows-visible follow-on execution?
    • Focus: child or descendant starts tied by process.parent.entity_id or process.Ext.ancestry to the alert process, reviewing process.executable and process.command_line.
    • Hint: direct child starts are high-confidence pivots; manually expand ancestry when WSL launches through intermediate hosts. $investigate_3
    • Implication: escalate for shells, archivers, credential tools, scanners, tunneling clients, Windows interop launches, or repeated distro starts; lower suspicion when visible follow-on activity stays limited to recognized setup or status commands.
  • If local evidence remains suspicious or unresolved, is the same user or host repeating Kali/WSL activity elsewhere?
    • Focus: related alerts and recent process starts scoped by user.id or host.id, compared with the suspicious process.executable and process.parent.command_line pattern.
    • Hint: review user or host alerts only after local Kali/WSL evidence stays suspicious or unresolved. $investigate_0 $investigate_1
    • Implication: expand scope when the same user, host, parent chain, or Kali/WSL argument pattern appears on other endpoints or repeats outside the recognized workflow; keep scope local when exact activity stays confined to one recognized endpoint and bounded window, but do not close a suspicious local alert from recurrence alone.
  • Escalate for unsupported user/host, suspicious launcher, masqueraded binary, lifecycle/configuration activity, offensive follow-on process, or spread; close only when process evidence binds to one exact recognized workflow with no contradictions; preserve evidence and escalate when mixed or incomplete.

False positive analysis

  • Developer, security-lab, training, red-team, provisioning, or image-build systems can legitimately run or install Kali under WSL. First confirm process telemetry ties user.id or host.id cohort, process.executable, process.args or package path, process.parent.command_line, and signer or hash identity to the same recognized workflow, with no unexpected WSL stop/relaunch, tooling, or follow-on activity. Use rosters, training, build records, owner confirmation, or inventory only as corroboration after process evidence matches; if they conflict or telemetry is incomplete, do not close as benign.
  • If workflow context is missing, keep the alert unresolved unless process telemetry proves the exact same bounded user/host, parent, binary identity, and Kali argument or package-path pattern with no contradictory lifecycle or follow-on evidence.
  • Before creating an exception, require recurrence for the minimum confirmed pattern: user.id or host.id cohort, process.executable, process.code_signature.subject_name or process.hash.sha256, process.parent.command_line, and the Kali-specific process.args or package-path process.executable. Avoid exceptions on process.name, the substring "kali", or "kali.exe" alone.

Response and remediation

  • If confirmed benign, reverse temporary containment and document the exact workflow evidence: user and host cohort, launcher path, signer or hash identity, parent command line, and Kali argument or package-path pattern. Create an exception only after the same bounded pattern recurs without contradictory follow-on behavior.
  • If suspicious but unconfirmed, export the alert and surrounding process timeline, preserve process instance IDs, command lines, binary identity, user/host/session anchors, and any WSL configuration or package paths visible in process telemetry before containment. Apply reversible containment first, such as terminating the active Kali or "wsl.exe" process, disabling the initiating account's WSL access, or running "wsl --shutdown" when operationally safe. Escalate to host isolation only if the activity spreads, reconfigures WSL, or launches offensive tooling.
  • If confirmed malicious, isolate the endpoint when the identity, lineage, lifecycle, or follow-on process evidence shows active abuse. Before cleanup, record the Kali/WSL process identity, parent chain, affected user.id and host.id, package paths, and WSL configuration paths seen in command lines. Then stop active WSL instances, remove the unauthorized Kali distribution and WSL configuration changes, reset credentials exposed to the Kali environment, and scope other endpoints for the same user, launcher identity, or package-path pattern.
  • Post-incident hardening should decide whether WSL is permitted for the affected endpoint cohort, restrict who can install or run WSL distributions, and retain process telemetry for Kali package paths, ".wslconfig", "wsl.conf", and "wsl.exe" lifecycle commands.

References

Related rules

to-top