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

to-top