Microsoft has moved Windows Subsystem for Linux well beyond its original scope of simply running Linux distributions on Windows: WSL Containers is now generally available, bringing native Linux container support directly into the WSL ecosystem. For developers, this is a meaningful productivity win — Linux containers on Windows without a separate Docker Desktop stack. For defenders, it is something else entirely: a new, privileged-capable execution layer on corporate Windows endpoints that most EDR policies, application control rules, and SOC detections were never built to watch.
This matters now because developer workstations are among the most targeted asset classes in the enterprise. They hold cloud credentials, source code, signing keys, SSH private keys, and lateral-movement pathways into build pipelines. Every time Microsoft expands WSL's capability surface, threat actors inherit it. WSL has already been abused in the wild as an EDR-evasion and defense-evasion mechanism — payloads executed inside WSL distributions historically received far less telemetry scrutiny than native Windows processes. GA container support compounds that risk: adversaries can now pull and run arbitrary container images, mount host filesystems, and operate tooling inside an isolated namespace that many monitoring stacks treat as a black box.
If your organization has developers running Windows 11 with WSL enabled, you need visibility and policy around this feature before it becomes someone else's persistence mechanism.
Technical Analysis
What Changed
WSL Containers, now generally available, allows users to run Linux containers directly within WSL without requiring Docker Desktop or a separate container host. The capability builds on the WSL2 architecture: a lightweight utility VM running a real Linux kernel, with containers now sharing that kernel inside the WSL environment.
Affected platforms: Windows 10 (version 2004+) and Windows 11 systems running WSL2, with the feature reaching GA through current WSL releases distributed via the Microsoft Store and GitHub (microsoft/WSL). Developer and power-user workstations are the primary exposure population — servers rarely run WSL, but if yours do, treat that as a finding in itself.
Why Defenders Should Care: The Threat Model
There is no CVE here — this is a capability announcement, not a vulnerability disclosure. But capability changes alter the attack surface in concrete ways:
-
EDR visibility gaps. Processes executing inside WSL and its containers do not generate native Windows process-creation telemetry in the same way
cmd.exeorpowershell.exedo. If your detections assume Windows-native execution, an attacker running tooling inside a WSL container can operate with materially reduced telemetry. Microsoft has shipped a Defender for Endpoint plug-in for WSL, but it must be explicitly deployed — most environments haven't. -
Defense evasion via
wsl.exeas a living-off-the-land binary.wsl.exeandwslhost.exeare signed Microsoft binaries that can be invoked to execute arbitrary Linux commands:wsl.exe -e /bin/bash -c <payload>. Attackers have used this pattern to bypass application whitelisting and proxy Linux-side execution through a trusted Windows parent. -
Arbitrary container image execution. With container support GA, a user (or malware acting as one) can pull images from public registries and run them. A malicious or compromised image is a supply-chain delivery vehicle that lands directly on the endpoint with host filesystem access via
/mnt/cinterop by default. -
Filesystem and network interop. WSL mounts the Windows filesystem under
/mnt/, and localhost port forwarding bridges Windows and Linux networking. Ransomware-style encryption of Windows files from inside WSL is a documented technique, and container networking can be abused to tunnel traffic in ways that bypass Windows-side proxy and firewall expectations. -
Unmanaged configuration surface. WSL behavior is governed by
.wslconfig(user-level) andwsl.conf(distro-level) — files most organizations neither baseline nor monitor.
Exploitation Status
No vulnerability is being exploited here — the news is a feature GA. However, the techniques this feature amplifies (WSL-based defense evasion, MITRE ATT&CK T1202 – Indirect Command Execution, T1027 – Obfuscation, and container-image supply-chain abuse, T1195.001) are actively observed in real intrusions. Treat this as an attack-surface expansion requiring proactive detection engineering, not a patch event.
Detection & Response
The detections below target the observable behaviors that matter: suspicious invocation of wsl.exe, container runtime activity originating from Windows, and child-process anomalies around WSL binaries.
---
title: Suspicious WSL Command Execution via wsl.exe
id: 8f2c4a91-3b7d-4e15-a6c9-2d1e5f7b9a04
status: experimental
description: Detects wsl.exe invoked with inline command execution flags or shell interpreters, a common defense-evasion and payload-execution pattern used to run Linux tooling from a signed Microsoft binary.
references:
- https://attack.mitre.org/techniques/T1202/
- https://attack.mitre.org/techniques/T1027/
- https://www.bleepingcomputer.com/news/microsoft/microsoft-is-rolling-out-linux-container-support-to-wsl/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.defense_evasion
- attack.execution
- attack.t1202
logsource:
category: process_creation
product: windows
detection:
selection_image:
Image|endswith:
- '\wsl.exe'
- '\wslhost.exe'
selection_cli:
CommandLine|contains:
- ' -e '
- '--exec'
- 'bash -c'
- 'sh -c'
- '/bin/bash'
- '/bin/sh'
- 'curl '
- 'wget '
- 'chmod +x'
filter_dev:
CommandLine|contains:
- 'code '
- 'docker '
- 'git '
condition: selection_image and selection_cli and not filter_dev
falsepositives:
- Developer workflows invoking WSL shells interactively
- VS Code Remote-WSL extensions
level: medium
---
title: WSL Execution from Uncommon Parent Process
id: 3e9b1d47-6a2f-4c83-b5e1-7d4a9f2c8e15
status: experimental
description: Detects wsl.exe spawned by Office applications, script interpreters, or other non-interactive parents — a strong indicator of phishing-delivered or malware-driven WSL abuse rather than legitimate developer use.
references:
- https://attack.mitre.org/techniques/T1202/
- https://www.bleepingcomputer.com/news/microsoft/microsoft-is-rolling-out-linux-container-support-to-wsl/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.defense_evasion
- attack.execution
- attack.t1202
logsource:
category: process_creation
product: windows
detection:
selection_image:
Image|endswith: '\wsl.exe'
selection_parent:
ParentImage|endswith:
- '\winword.exe'
- '\excel.exe'
- '\powerpnt.exe'
- '\outlook.exe'
- '\mshta.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\cmd.exe'
condition: selection_image and selection_parent
falsepositives:
- Scripted developer environment bootstrap (should be inventoried and tuned per-environment)
level: high
---
title: WSL Container Runtime Execution from Windows Host
id: 5a1d8f63-9c4b-4e27-a3f6-1b8e2d7c4a96
status: experimental
description: Detects container runtime commands (docker/podman/containerd) invoked through wsl.exe from the Windows host, indicating container operations inside WSL that may bypass Windows-native monitoring.
references:
- https://attack.mitre.org/techniques/T1610/
- https://attack.mitre.org/techniques/T1195.001/
- https://www.bleepingcomputer.com/news/microsoft/microsoft-is-rolling-out-linux-container-support-to-wsl/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.execution
- attack.defense_evasion
- attack.t1610
logsource:
category: process_creation
product: windows
detection:
selection_image:
Image|endswith: '\wsl.exe'
selection_cli:
CommandLine|contains:
- 'docker run'
- 'docker pull'
- 'docker exec'
- 'docker build'
- 'podman run'
- 'nerdctl run'
- 'ctr run'
condition: selection_image and selection_cli
falsepositives:
- Legitimate developer container workflows — inventory authorized usage and alert on deviations
level: medium
The following KQL hunts assume Microsoft Defender for Endpoint (or MDE via Sentinel) process telemetry. Deploy the MDE plug-in for WSL to get Linux-side process events; without it, you only see the Windows-side invocation.
// Hunt: WSL abuse patterns on Windows endpoints — last 14 days
// Covers LOLBin-style wsl.exe execution, suspicious parents, and container operations
let Lookback = 14d;
DeviceProcessEvents
| where TimeGenerated >= ago(Lookback)
| where FileName in~ ("wsl.exe", "wslhost.exe", "bash.exe")
| extend SuspiciousParent = InitiatingProcessFileName in~ (
"winword.exe","excel.exe","powerpnt.exe","outlook.exe","mshta.exe",
"wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe","powershell.exe","pwsh.exe","cmd.exe")
| extend SuspiciousCmd = ProcessCommandLine has_any (
"bash -c","sh -c"," --exec "," -e ","curl ","wget ","chmod +x",
"docker run","docker pull","docker exec","podman run","/mnt/c/Users")
| where SuspiciousParent or SuspiciousCmd
| project TimeGenerated, DeviceName, AccountName,
InitiatingProcessFileName, InitiatingProcessCommandLine,
FileName, ProcessCommandLine, SHA256, ReportId
| sort by TimeGenerated desc
// Hunt: Baseline deviation — devices running WSL for the first time in 30 days
// New WSL activity on a device with no history is a strong anomaly signal
let History = DeviceProcessEvents
| where TimeGenerated between (ago(60d) .. ago(30d))
| where FileName =~ "wsl.exe"
| summarize by DeviceName;
DeviceProcessEvents
| where TimeGenerated >= ago(30d)
| where FileName =~ "wsl.exe"
| where DeviceName !in (History)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
InvocationCount = count(), Users = make_set(AccountName),
SampleCmds = make_set(ProcessCommandLine, 5) by DeviceName
| sort by FirstSeen desc
-- Velociraptor hunt: enumerate live WSL processes and interrogate WSL configuration artifacts
-- Deploy across developer workstation fleet
-- Part 1: Live WSL/container process execution with command lines
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)wsl|bash|docker|containerd|podman'
OR CommandLine =~ '(?i)wsl.*(-e|--exec|bash -c|sh -c)'
-- Part 2: WSL user configuration files (persistence-relevant — .wslconfig controls VM behavior)
SELECT FullPath, Size, Mtime AS Modified
FROM glob(globs='C:\\Users\\*\\.wslconfig')
-- Part 3: WSL registry state — confirm which distributions are installed per machine
SELECT Name, FullPath
FROM glob(globs='HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Lxss\\*\\*',
accessor='registry')
Remediation & Hardening
Because this is a capability rather than a patchable vulnerability, remediation means governance, visibility, and configuration control:
-
Inventory WSL usage. You cannot secure what you haven't enumerated. Run the PowerShell below across your fleet to identify machines with WSL enabled and which distributions/containers are present.
-
Deploy the Microsoft Defender for Endpoint plug-in for WSL. This restores Linux-side process/file telemetry into MDE. Without it, WSL containers are a monitoring blind spot. See Microsoft's documentation:
https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/mde-plugin-wsl. -
Enforce WSL policy centrally. Microsoft provides WSL enterprise controls via Intune/group policy (WSL settings management) allowing you to control which distributions are permitted, disable kernel command-line customization, restrict networking modes, and block custom kernels. If WSL is not a business requirement on a device class, disable the feature entirely.
-
Baseline and monitor
.wslconfig/wsl.conf. Alert on modification of these files — they control VM resources, networking mode, and swap, and tampering can weaken isolation assumptions. -
Extend container supply-chain policy to endpoints. If developers pull images, require signed/trusted registries and consider enforcing image provenance (e.g., only allow pulls from an internal registry mirror). A developer laptop is not exempt from supply-chain hygiene.
-
Disable WSL where not needed via Windows Features or Intune device configuration, and confirm removal of the
Virtual Machine PlatformandWindows Subsystem for Linuxoptional features.
# WSL Container Attack Surface Audit & Hardening — run elevated, deploy via Intune/SCCM
# Part 1: Enumerate WSL state on the endpoint
Write-Host "=== WSL Feature State ===" -ForegroundColor Cyan
Get-WindowsOptionalFeature -Online |
Where-Object { $_.FeatureName -in 'Microsoft-Windows-Subsystem-Linux','VirtualMachinePlatform' } |
Select-Object FeatureName, State | Format-Table -AutoSize
# Part 2: List installed WSL distributions and versions
Write-Host "=== Installed Distributions ===" -ForegroundColor Cyan
try { wsl.exe --list --verbose } catch { Write-Host "WSL not present or not invocable." }
# Part 3: Check for user-level .wslconfig files (should be baselined/monitored)
Write-Host "=== .wslconfig Files ===" -ForegroundColor Cyan
Get-ChildItem 'C:\Users\*\.wslconfig' -ErrorAction SilentlyContinue |
Select-Object FullName, LastWriteTime | Format-Table -AutoSize
# Part 4: Report recent wsl.exe executions from Defender telemetry (local check)
Write-Host "=== Recent WSL Process Activity (Event 4688 requires audit policy) ===" -ForegroundColor Cyan
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 5000 -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match 'wsl\.exe|wslhost\.exe' } |
Select-Object -First 20 TimeCreated, Message | Format-List
# Part 5: Hardening — disable WSL entirely on machines where it is NOT required
# Uncomment to enforce:
# Disable-WindowsOptionalFeature -Online -FeatureName 'Microsoft-Windows-Subsystem-Linux' -NoRestart
# Disable-WindowsOptionalFeature -Online -FeatureName 'VirtualMachinePlatform' -NoRestart
# Part 6: Verify MDE WSL plug-in presence (Linux-side telemetry coverage)
Write-Host "=== MDE WSL Plug-in Check ===" -ForegroundColor Cyan
if (Test-Path "$env:ProgramFiles\Microsoft Defender for Endpoint plug-in for WSL") {
Write-Host "MDE WSL plug-in installed — Linux-side telemetry available."
} else {
Write-Warning "MDE WSL plug-in NOT found. WSL/container activity is a telemetry blind spot."
}
Bottom line: WSL Containers going GA is a legitimate developer feature that arrives with an adversary-usable execution layer attached. Inventory your WSL footprint this week, close the telemetry gap with the MDE WSL plug-in, baseline the Sigma/KQL detections above against your developer population, and put policy around which machines are allowed to run Linux containers at all. The organizations that treat developer endpoints as first-class monitored assets are the ones that catch the intrusion at the workstation instead of at the domain controller.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.