Windows Subsystem for Linux puts a full Linux environment inside a managed Windows endpoint, and most Windows security tooling cannot see what happens in it. A WSL 2 distribution runs in a lightweight utility virtual machine with its own kernel, filesystem, package manager and user accounts, yet it can read the Windows user's files, launch Windows programs and reach the same networks. Developers rely on it, which makes banning it impractical in many organisations, while attackers value it because a virtual instance hides activity from host-based agents. This guide covers how identity and access work across the Windows and Linux boundary, the Intune and Group Policy controls Microsoft provides, Microsoft Defender for Endpoint visibility, a hardening baseline and the common mistakes. It is written for endpoint engineers, SOC teams and security architects responsible for developer workstations.
Key takeaways
- WSL is a separate operating system on the endpoint. It has its own users, root account, packages and credentials, and Windows Update, Windows antivirus and Windows vulnerability management do not reach inside it.
- The Windows user is the real security boundary. Root inside WSL does not grant Windows administrator rights, but every WSL process can read and write whatever the Windows user can, through the /mnt/c automount.
- Control it centrally with the WSL policies. Intune settings catalog and the WSL ADMX expose Allow WSL, Allow WSL1, debug shell, disk mount, custom kernel, networking and firewall settings; Microsoft recommends Disabled for each in an enterprise baseline.
- Visibility needs the Defender for Endpoint plug-in. It reports process, file and network events from WSL 2 distributions as separate devices, but antimalware, vulnerability management and response actions are not available for those devices.
- Developer secrets move into the distribution. SSH keys, cloud CLI credentials and kubeconfig files in Linux home directories sit outside Windows credential protection and outside most secret scanning.
How identity and access work in WSL
WSL 2 runs each distribution in a shared utility VM using a Microsoft-built Linux kernel. When a user runs wsl.exe, the session starts as the distribution's default Linux user (set in /etc/wsl.conf under [user] default), usually an account created on first launch with passwordless or password-protected sudo to root. Microsoft's enterprise guidance states the security model plainly: a Linux user with root inside WSL does not gain Windows administrator rights, and Windows file access uses the permissions of the Windows user who ran wsl.exe, so running bash from WSL has the same permission level as running PowerShell as that user.
| Boundary | Default behaviour | Security consequence | Control |
|---|---|---|---|
| Windows drives | [automount] enabled=true mounts fixed drives under /mnt via DrvFs | Linux tools can read, modify or encrypt the user's Windows files | Disable automount for restricted distros; rely on NTFS permissions |
| Windows interop | [interop] enabled=true, appendWindowsPath=true | Linux shells launch Windows binaries (cmd.exe, powershell.exe) as the user | Set interop enabled=false where not needed |
| Linux filesystem from Windows | Distributions are reachable at \\wsl.localhost\<Distro> | Windows processes running as the user can read Linux home directories and keys | Treat the distro as part of the user's data |
| Root in the distro | Default user typically has sudo | Full control of the Linux side, including disabling logging inside it | No Microsoft control for Linux root; harden images |
| Startup command | [boot] command runs as root when the instance starts | Persistence point inside the distro | Monitor wsl.conf changes |
| Network | NAT mode by default; localhostForwarding=true | Services in WSL are reachable from the host and may be exposed by port forwarding | Hyper-V firewall, mirrored mode, firewall=true |
Per-distribution settings live in /etc/wsl.conf; global WSL 2 settings live in %UserProfile%\.wslconfig, which the user owns. Changes apply only after the subsystem fully stops, about eight seconds after the last shell closes or after wsl --shutdown.
Admin roles and privileged access
- Who can enable WSL: installing the WSL feature and distributions has historically needed local administrator rights on first setup. Keep developers as standard users, deliver WSL through managed deployment and use an endpoint privilege management tool for elevation. See the Endpoint Privilege Management Guide.
- Linux root is unmanaged: Microsoft lists controlling root access for users and controlling which distributions users can access as currently unsupported. Compensate with approved images (built once, distributed with
wsl --exportandwsl --import) whose default user has no blanket sudo, and with compliance checks. - Debug shell and kernel debugging:
wsl --debug-shelland kernel debugging give access to the utility VM itself. Disable both by policy (AllowDebugShell and Allow kernel debugging). - Privileged access workstations: do not allow WSL on admin workstations or jump hosts used for Tier 0 work; it adds an unmonitored execution environment to the most sensitive endpoint. See the Privileged Access Workstations Guide.
Integrations, API tokens and service accounts
WSL is where developers keep the credentials of non-human identities: SSH private keys in ~/.ssh, cloud CLI credentials such as ~/.aws/credentials, Azure and Google Cloud CLI token caches, ~/.kube/config, package registry tokens in .npmrc or .pypirc, and Git credential helpers. These files sit inside the distribution's virtual disk, protected only by Linux file permissions and the Windows user's profile ACLs. Any malware running as the Windows user can read them through the \\wsl.localhost path, and Windows-side secret scanners and DLP agents often do not inspect the Linux filesystem. Theft from these files is MITRE ATT&CK T1552.001 Credentials In Files and T1552.004 Private Keys.
- Prefer short-lived credentials: use SSO-based cloud CLI sessions and workload federation rather than long-lived access keys. See the AWS Access Keys Security Guide.
- Protect SSH keys: passphrase-protect keys or use hardware-backed keys, and prefer short-lived SSH certificates. See the SSH Key Management Guide.
- Scan before commit: run pre-commit secret scanning inside the distribution, not only on Windows. See the Git Secret Scanning Guide.
- Include WSL in leaver and incident processes: rotating a user's Windows password does nothing for tokens cached in WSL; incident playbooks must list WSL credential stores for revocation.
Logging and detection
Attackers use WSL for two reasons ATT&CK documents: T1202 Indirect Command Execution, which names WSL components and wsl.exe, and T1564.006 Run Virtual Instance, running code in a virtual instance so host security tools cannot see the activity, often with a shared folder into the host filesystem. Linux shell activity inside the distro maps to T1059.004 Unix Shell.
Microsoft Defender for Endpoint plug-in for WSL
- Coverage: WSL 2 distributions and WSL containers on devices onboarded to Defender for Endpoint Plan 2, with WSL 2.0.7.0 or later, on Windows 10 version 2004 (build 19044 and later) and Windows 11. Not supported on ARM64 or multi-session Windows.
- Portal view: each WSL instance appears as a separate Linux device tagged WSL2, with a link to the Windows host; the timeline shows file, process and network events and alerts are generated.
- Gaps: antimalware, threat and vulnerability management and response commands are not available for the WSL device. WSL 1 is not supported, custom kernels and kernel command lines are not supported, onboarding can take up to 30 minutes and short-lived instances may not appear.
- Health: run
healthcheck.exefrom the plug-in's tools folder and track the health state per device.
Host-side signals
| Signal | Source | Why it matters |
|---|---|---|
| wsl.exe, wslhost.exe or bash.exe launched by Office, browsers, script hosts or services | EDR process events, Sysmon process creation | Indirect execution from an unusual parent (T1202) |
New distribution registered or imported (wsl --import, --install) | Process command lines, new ext4.vhdx files in user profiles | Unapproved Linux environment |
| Windows binaries spawned with a WSL process as parent | EDR process tree | Interop used to pivot back to Windows |
| Changes to .wslconfig or /etc/wsl.conf | File monitoring | Networking, kernel or boot command tampering |
| Bulk writes to /mnt/c paths from WSL processes | Plug-in file events | Ransomware or staging through the shared filesystem |
| WSL devices missing from the Defender inventory | Device inventory compared with Intune WSL compliance | Blind spot |
Metrics
- WSL footprint: number of devices with WSL enabled compared with the approved developer population.
- Visibility coverage: percentage of WSL-enabled devices with a healthy Defender plug-in and a WSL2 device record.
- Policy coverage: percentage of devices receiving the WSL settings catalog profile.
- Approved images: percentage of distributions matching the approved list in Intune WSL compliance.
- WSL 1 instances: count of WSL 1 distributions (target zero, as they are outside plug-in visibility).
Hardening baseline
Choosing a posture
| Posture | When to choose it | Settings | Trade-off |
|---|---|---|---|
| Block | No business need; admin and kiosk devices; small organisations without EDR coverage of WSL | Allow the Windows Subsystem For Linux: Disabled; App Control deny rules for wsl.exe, wslhost.exe, wslconfig.exe, bash.exe, lxrun.exe and LxssManager.dll | Developers lose local Linux tooling |
| Managed | Developer and data science populations | WSL allowed, all advanced settings Disabled, Defender plug-in, Intune WSL compliance, approved images | Needs plug-in deployment and image maintenance |
| Isolated alternative | High-risk code or untrusted repositories | Cloud development environments or dedicated VMs instead of WSL | Cost and latency |
Microsoft's App Control for Business recommended block list includes those six WSL components "unless your use scenarios explicitly require them", which supports the Block posture. See the Application Allowlisting Guide.
Managed posture settings
| Intune settings catalog (Windows Subsystem for Linux) | Recommended | Reason |
|---|---|---|
| Allow the Windows Subsystem For Linux | Enabled only for the developer group | Scopes WSL to approved users |
| Allow the Inbox version of the Windows Subsystem For Linux | Disabled | Keeps devices on the updatable Store version |
| Allow WSL1 | Disabled | WSL 1 is outside Defender plug-in visibility |
| Allow the debug shell / Allow kernel debugging | Disabled | Access to the utility VM |
| Allow passthrough disk mount | Disabled | Stops wsl --mount of physical disks |
| Allow custom kernel configuration / kernel command line | Disabled | Custom kernels break visibility and trust |
| Allow custom system distribution configuration | Disabled | Protects the system distribution |
| Allow custom networking configuration | Disabled | Users cannot bypass the managed network mode |
| Allow user setting firewall configuration | Disabled | Keeps Hyper-V firewall filtering on |
| Allow nested virtualization | Disabled | Prevents further hidden VMs inside WSL |
For Group Policy, import the WSL ADMX that Microsoft publishes in the WSL GitHub repository. From Windows 11 22H2 with WSL 2.0.9, Windows Firewall rules apply to WSL distributions by default through the Hyper-V firewall; keep firewall=true and consider networkingMode=mirrored with dnsTunneling=true and autoProxy=true so WSL traffic follows the host's VPN, proxy and DNS controls. See the Windows Defender Firewall Guide.
Rollout
- Discover: report devices with WSL installed, distributions per user (
wsl --list --verbosethrough a remediation script) and WSL 1 instances. - Decide posture per population: block for admin, finance and kiosk devices; managed for developers.
- Deploy visibility first: the Defender plug-in and the Intune WSL plugin (IntuneWSLPluginInstaller.msi as a Win32 app) before restricting, so you can measure impact.
- Pilot the settings catalog profile on a developer ring; collect breakages (custom kernels, nested containers, VPN) and decide exceptions with expiry dates.
- Publish approved images: a hardened distribution exported once, with a non-root default user, auditd or the distro's logging and a package update schedule, since Windows tools cannot patch distro contents.
- Enforce and roll back: widen the profile assignment ring by ring. Rolling back is a change of assignment or a setting back to Not configured; App Control deny rules should first run in audit mode.
Framework mapping
| Framework | Reference | WSL application |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CM-7(2) Prevent Program Execution, CM-11 User-installed Software, SI-4 System Monitoring | Block or scope WSL; govern distributions; monitor with the plug-in |
| NIST CSF 2.0 | PR.PS-05, DE.CM-09 | Unauthorised software prevented; runtime environments monitored |
| CIS Controls v8.1 | 2.5 Allowlist authorised software, 4.1 Secure configuration process | Approved images and settings baseline |
| MITRE ATT&CK | T1202, T1564.006, T1059.004, T1552.001 | Detections in the signals table |
Common misconfigurations
- Assuming EDR covers WSL: without the plug-in, Windows EDR sees wsl.exe start and little else. Even with it, there is no antivirus scanning or response action inside the distribution.
- Leaving WSL 1 distributions: older installs convert slowly; WSL 1 is unsupported by the plug-in, so these become the blind spot an attacker chooses.
- Never patching distributions: Windows Update does not update distro packages, so WSL images age with known vulnerabilities and outdated OpenSSL, sudo and libraries.
- Treating Linux root as harmless: it cannot become Windows admin, but it can read every developer token in the distro, disable in-distro logging and write through /mnt/c to the user's documents and repositories.
- Letting users own networking and firewall: leaving Allow custom networking configuration and Allow user setting firewall configuration enabled lets .wslconfig move traffic outside the host's controls.
- Ignoring persistence points:
[boot] commandin wsl.conf, shell profiles and imported distributions survive reboots and are rarely in Windows persistence hunts.
Practitioner checklist
- Inventory WSL-enabled devices, distributions and WSL versions; convert or remove WSL 1.
- Block WSL with policy and App Control deny rules on admin, kiosk and non-developer devices.
- Assign the WSL settings catalog profile with every advanced setting Disabled for developer devices.
- Deploy the Defender for Endpoint plug-in for WSL and alert when a WSL-enabled device has no healthy WSL2 device record.
- Deploy Intune WSL compliance to enforce approved distributions and versions.
- Publish hardened, regularly patched distribution images and distribute them with wsl --import.
- Move developer cloud and SSH credentials to short-lived, SSO-based or hardware-backed forms and scan inside WSL for secrets.
- Hunt for wsl.exe launched by unusual parents and for changes to wsl.conf and .wslconfig.
- Add WSL credential stores to leaver and incident revocation playbooks.
Standards and references
- Microsoft Learn: Set up WSL for your company
- Microsoft Learn: Intune settings for WSL
- Microsoft Learn: Microsoft Defender for Endpoint plug-in for WSL
- Microsoft Learn: Advanced settings configuration in WSL
- Microsoft Learn: Evaluate compliance for Windows Subsystem for Linux
- Microsoft Learn: Applications that can bypass App Control and how to block them
- MITRE ATT&CK: Run Virtual Instance
- MITRE ATT&CK: Indirect Command Execution
Related NHI Mgmt Group resources: Windows Endpoint Hardening Guide · Microsoft Defender for Endpoint Guide · Microsoft Intune Guide · Engineering Workstation Security Guide · Kali Linux for Authorised Testing Guide