Windows Subsystem for Linux (WSL) has transformed the developer experience on Windows. However, it has also quietly created a powerful hiding place for attackers.
With WSL2, Microsoft moved from lightweight translation to a whole virtual machine (VM) model. That architectural change gives adversaries a semi-isolated Linux environment running inside Hyper‑V that is rarely monitored by traditional endpoint security tools.
For red teamers and real‑world attackers, this is a gift. A Windows host with WSL2 effectively contains a second operating system that can run processes, access files, and reach the internal network, often with little or no visibility from EDR.
In practice, operators have used this to pivot from heavily monitored Windows sessions into WSL2 and then freely operate from that enclave – running tools, staging payloads, and harvesting data and credentials with minimal risk of detection.
On many developer workstations, WSL distros are packed with useful loot: unprotected SSH keys, tokens, and credentials in shell configuration files and environment variables, and scripts that hit production services.
Once an attacker gets code execution on the Windows side, WSL2 becomes a natural next step to deepen access and reduce their detection footprint.
The obvious way to reach WSL from a Windows implant is to call wsl.exe directly using something like a Beacon Object File (BOF) that wraps CreateProcess.
Why WSL2 Appeals to Attackers
That lets an operator launch commands inside a chosen WSL distro from their C2 agent. While this “sketchy WSL command” approach works and has rarely been flagged so far, it leaves uncomfortable artifacts: a suspicious command line spawning wsl.exe from a random process, something defenders could easily key on once detections catch up.
Microsoft exposes a friendlier‑looking API via WslLaunch in WslApi.dll, which appears to offer direct programmatic execution inside WSL.
However, decompiling that DLL reveals that WslLaunch formats a command string and spawns wsl.exe via CreateProcess behind the scenes.
In other words, the “official” API does the same thing red teamers were already doing, leaving the same process artifacts.
This explains why there may be little static detection around this pattern: many legitimate applications already behave this way.
To get something stealthier and more flexible, researchers turned to the WSL2 Component Object Model (COM) interface that backs the WSL service.
Microsoft has open‑sourced WSL, and the wslservice.idl file documents an interface exposing lower‑level functions such as CreateLxProcess, which can start Linux processes via COM instead of spawning wsl.exe.
In theory, a BOF could use COM directly to enumerate WSL instances and execute commands without the telltale wsl.exe child process.
In practice, the COM layer turned out to be messy. The WSL2 COM interface has changed aggressively over time while reusing the same CLSID.
Arguments have been added and removed, functions inserted and deleted, and vtable layouts shifted between versions.
Real-World Abuse
A client built from the current IDL worked only against the newest WSL builds; on older systems it crashed due to marshalling mismatches and even ended up calling the wrong methods entirely.
To solve this, researchers leaned on James Forshaw’s OleView.Net to dynamically reconstruct IDL definitions from the proxy stub DLL (WslServiceProxyStub.dll) shipped with each WSL release.
By parsing the internal ProxyFileList structure, they generated version‑accurate IDLs and then headers, mapped out how the interfaces evolved, and implemented multiple interface variants in a single BOF.
At runtime, the BOF reads the WSL version from the registry (HKLMSOFTWAREMicrosoftWindowsCurrentVersionLxssMSI) and selects the matching interface implementation.
The result is “the one WSL BOF”, a Cobalt Strike BOF that can enumerate WSL2 instances and execute commands inside them via COM across multiple WSL2 versions, without explicitly spawning wsl.exe.
The code is ugly and conditional‑heavy, and future WSL releases may break compatibility again, but it turns WSL2 into a first‑class pivot mechanism for red teams.
For defenders, the takeaway is stark: any Windows estate that widely uses WSL2 is exposing a poorly monitored execution environment tightly integrated with the host.
Security teams should start treating WSL2 as part of the attack surface, including monitoring wsl.exe usage, inspecting WSL file systems, and watching for suspicious COM activity targeting WSL services.
Attackers are already treating WSL2 as a stealthy hideout – defenders need to catch up.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.