« Host File System Changes via Windows Subsystem for Linux Windows Subsystem for Linux Distribution Installed »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Attempt to Install or Run Kali Linux via WSL

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Attempt to Install or Run Kali Linux via WSL

edit

Detects attempts to install or use Kali Linux via Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection.

Rule type: eql

Rule indices:

  • endgame-*
  • logs-crowdstrike.fdr*
  • logs-endpoint.events.process-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-system.security*
  • logs-windows.forwarded*
  • logs-windows.sysmon_operational-*
  • winlogbeat-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Windows Security Event Logs
  • Data Source: Microsoft Defender XDR
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Data Source: Crowdstrike
  • Resources: Investigation Guide

Version: 217

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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{"description":"","label":"Same-parent process starts on this host","providers":[[{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"WSL lifecycle commands on this host","providers":[[{"excluded":false,"field":"process.name","queryType":"phrase","value":"wsl.exe","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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{"description":"","label":"Child process starts from the Kali or WSL process","providers":[[{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
process where host.os.type == "windows" and event.type == "start" and
(
  (process.name : "wsl.exe" and process.args : ("-d", "--distribution", "-i", "--install") and process.args : "kali*") or
  process.executable : (
    "?:\\Users\\*\\AppData\\Local\\packages\\kalilinux*",
    "?:\\Users\\*\\AppData\\Local\\Microsoft\\WindowsApps\\kali.exe",
    "?:\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe",

    /* Crowdstrike specific exclusion as it uses NT Object paths */
    "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Local\\packages\\kalilinux*",
    "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Local\\Microsoft\\WindowsApps\\kali.exe",
    "\\Device\\HarddiskVolume*\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe"
  )
)

Framework: MITRE ATT&CKTM

« Host File System Changes via Windows Subsystem for Linux Windows Subsystem for Linux Distribution Installed »