Windows Subsystem for Linux (WSL) Security: How to Manage and Harden WSL in Enterprise Environments
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
WSL is a productive tool for developers who need Linux tooling on Windows workstations. It is also a potential security gap: standard Windows security controls (application allowlisting, Windows event logging, many EDR agents) were designed for Windows PE executables and may not fully cover Linux ELF binaries running in the WSL subsystem. Attackers who obtain code execution on a Windows endpoint can potentially use WSL to run Linux-based attack tooling that bypasses Windows-side security controls. The right enterprise approach is a deliberate policy: allow WSL for developer roles with monitoring configured, or block WSL for all other roles. The default -- WSL enabled by default on Windows 10/11 with no enterprise policy -- is the worst outcome.
Assess WSL Usage in Your Environment
Before deploying controls, determine how many devices have WSL installed and which users are using it. PowerShell to enumerate WSL installations across managed endpoints via Intune or SCCM: Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux will return Enabled or Disabled for each device. Via Intune device compliance: create a device health script that checks the feature state and reports it as a custom attribute. From event logs: WSL activity can sometimes be detected by searching for the wsl.exe and wslhost.exe processes in Sysmon process creation events (Event ID 1). Search your SIEM: index=sysmon EventID=1 Image="\wsl.exe" OR Image="\wslhost.exe" OR CommandLine="wsl" | stats count by Computer, User. The result tells you whether WSL is already in active use before you enforce any restrictions.
Block WSL for Non-Developer Roles via GPO
For endpoints where WSL is not a business requirement, disable it via Group Policy. The WSL-specific GPO setting is in Computer Configuration > Administrative Templates > Windows Components > Windows Subsystem for Linux > Allow Windows Subsystem for Linux. Set to Disabled to block all WSL functionality. Additionally, block WSL installation via Microsoft Store controls and the Optional Features panel: the Microsoft-Windows-Subsystem-Linux Windows feature can be blocked via GPO at Computer Configuration > Administrative Templates > System > 'Specify settings for optional component installation and component repair'. For developer endpoints where WSL is required: allow it but configure monitoring (see the monitoring section). Separate developer workstations into a dedicated Intune or GPO group so WSL controls can be applied differentially. Standard business user laptops should have WSL blocked; developer workstations should have WSL allowed with enhanced monitoring.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Configure Defender AV to Scan the WSL Filesystem
Windows Defender does not scan the WSL 2 Linux filesystem by default. The Linux ext4 filesystem image (the .vhd file) is not mounted as a Windows volume that Defender routinely scans. To enable Defender scanning of WSL paths: in the Windows Security Center or via Intune, ensure that 'Scan mapped drives' and 'Scan removable drives' are enabled. More importantly, configure a manual scan target for the WSL filesystem directory: Add-MpPreference -ScanScheduledScanOnlyIfIdle $false and configure a scheduled scan of %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited* which is where WSL distribution filesystems are stored. Defender for Endpoint (MDE) version 101.24062 and later includes native WSL monitoring support via the MDE Linux agent deployed within the WSL distribution itself -- for environments with MDE, configure the MDE Linux sensor inside WSL distributions on monitored endpoints.
Enable WSL Process Auditing via Sysmon
Standard Windows Sysmon configuration captures WSL process creation if the Sysmon process monitoring rules include ELF binary paths within the WSL virtual filesystem (/usr/bin, /usr/local/bin, etc.). However, Sysmon captures these as Windows events about the wslhost.exe process, not as individual Linux process events. For comprehensive Linux process visibility within WSL: deploy the MDE Linux sensor or the Sysmon for Linux binary within the WSL distribution itself. The MDE Linux agent within WSL generates standard MDE telemetry for Linux processes, network connections, and file operations. Alternatively, configure Linux audit daemon (auditd) within the WSL distribution: within the WSL shell, install auditd and configure rules, then forward the audit log to your SIEM via syslog forwarding configured within the WSL Linux environment. The WSL syslog can be forwarded to a Windows syslog forwarder by writing to the Windows host's event log via /proc/sys/kernel hooks or by using a WSL-aware log forwarding agent.
Network Access Controls for WSL
WSL 2 uses a virtual network interface (vEthernet WSL) with a private IP address space. By default, WSL distributions have outbound internet access through the host's network. This means a user with WSL installed can run network tools (nmap, Impacket, Responder) from within the WSL environment, and the traffic originates from the Windows host's IP address. Windows Firewall rules do not automatically apply to the WSL virtual network interface in the same way as the host network interface. Hardening: configure the host Windows Firewall to block or restrict traffic on the WSL vEthernet interface (vEthernet WSL) -- specifically block inbound connections to WSL from the internal network and restrict WSL outbound to only the services the WSL distribution needs. In network monitoring, add detection for unusual port scanning or network enumeration traffic originating from IP addresses of developer workstations during non-development hours. WSL should be treated like a privileged toolset: appropriate for specific roles with monitoring, not a default unmonitored capability.
The bottom line
WSL requires an explicit enterprise policy decision. The default (enabled with no monitoring) is the worst security posture. Block WSL via GPO for all standard business user roles. For developer endpoints where WSL is needed, configure Defender AV to scan the WSL filesystem, deploy MDE Linux sensor or auditd within the WSL distribution, and monitor WSL process creation via Sysmon or MDE. Treat developer workstations with WSL as higher-risk endpoints that warrant enhanced monitoring.
Frequently asked questions
Can EDR products detect attacks run from within WSL?
It depends on the EDR product and configuration. Microsoft Defender for Endpoint with the MDE Linux sensor configured within the WSL distribution provides full process and network visibility for WSL activity. CrowdStrike Falcon has a WSL sensor available. SentinelOne has WSL coverage in their endpoint agent. Products without specific WSL support see WSL activity only at the Windows host process level (wsl.exe, wslhost.exe process creation) but not the individual Linux process and file operations within WSL. Check with your EDR vendor for their specific WSL coverage statement and configuration requirements.
Does WDAC or AppLocker apply to WSL binaries?
Windows Defender Application Control (WDAC) and AppLocker apply to Windows PE executables and do not natively block Linux ELF binaries running within WSL. WDAC can control whether WSL itself (wsl.exe) can run -- blocking wsl.exe effectively blocks WSL use. But if WSL is allowed to run, the Linux binaries executed within it are not subject to WDAC or AppLocker policies. This is a key gap: an application control policy that blocks common Windows attack tools (PowerShell in constrained mode, Mimikatz.exe) does not block the equivalent Linux tools run from WSL.
How do I check if a user ran specific commands in WSL?
Within the WSL distribution, the Linux command history is stored in ~/.bash_history or ~/.zsh_history. If the user has not cleared this file, historical commands are visible. For forensic investigation: access the WSL filesystem from Windows at \\wsl$\Ubuntu\home\username (while WSL is running) or directly at the .vhd file for offline analysis. Auditd configured within WSL provides structured audit records. Without auditd configured beforehand, .bash_history is the primary post-hoc forensic source within WSL.
Is WSL 1 safer than WSL 2 from a security perspective?
WSL 1 translates Linux system calls to Windows kernel calls without a separate Linux kernel -- the Linux processes run in the Windows process space and are more visible to Windows security tools. WSL 2 uses a lightweight VM with a real Linux kernel, which creates a more isolated environment with less Windows-layer visibility. From an enterprise security perspective, WSL 1 provides more transparency to Windows-side monitoring tools. However, most Linux distributions now recommend or require WSL 2 for compatibility. The practical answer: for security visibility, configure MDE Linux sensor or auditd within WSL 2 rather than attempting to rely on WSL 1 compatibility for monitoring purposes.
Can an attacker use WSL to download and execute malware that bypasses Windows Defender?
Partially. Files downloaded within WSL to the WSL filesystem (/home/user/malware) are initially not scanned by Windows Defender because the Defender AV agent does not scan the WSL virtual disk by default. An attacker can download a Linux ELF binary, compile exploit code, or fetch scripts within WSL without triggering Windows Defender signature detection. However, once a file from WSL is accessed via the Windows filesystem path (\\wsl$\Ubuntu\...) or copied to the Windows filesystem, Windows Defender scans it. Configure Defender's 'Scan mapped network drives' setting and deploy the MDE Linux sensor within WSL to close this gap. MDE Linux sensor detects malicious Linux processes regardless of which filesystem they originate from.
How do you enforce enterprise WSL policies at scale using Intune and what specific settings should be configured?
WSL enterprise policy configuration requires the WSL Intune MDM policies available in Windows 11 22H2 and later. Configure via Intune Settings Catalog (or custom OMA-URI for older builds) under the 'Windows Subsystem for Linux' category. Key policies: set 'Allow WSL' to Disabled for endpoints where WSL has no legitimate business purpose (most enterprise desktops). For environments where WSL is needed: set 'Allow WSL2' to Disabled if you require WSL 1 for its greater Windows-layer visibility. Set 'Allow the debug shell' to Disabled to prevent access to a root WSL shell that bypasses normal Windows security controls. Set 'Allow custom kernel configuration' to Disabled to prevent users from loading custom Linux kernels. Enable network mirroring mode (set NatNetwork to mirrored in .wslconfig) so WSL traffic uses Windows Firewall rules rather than a separate virtual switch. Deploy the MDE Linux sensor in WSL by including the MDE onboarding script in your WSL provisioning workflow -- MDE detects malicious Linux processes in WSL 2 environments where Windows Defender has no native visibility.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.