Windows Subsystem for Linux (WSL)

Cartoon penguin with big eyes, yellow beak, and black and white body against a blue background.

WSL is a Windows feature that allows you to run a complete Linux environment, including command-line tools and applications, directly on your Windows machine without a virtual machine or dual-boot setup. WSL 1 uses a translation layer for compatibility, WSL 2 makes use of virtualization. Seems cool for attackers to use, Lolbin, Linux, potential logging evasion through virtualization, application bypass..

Exploring WSL:

Install from a pre-set list of distributions.

Screen showing a command prompt with a list of valid Linux and Unix-based operating system distributions for installation, including AlmaLinux, Debian, Fedora, SUSE, Ubuntu, Arch Linux, Kali Linux, openSUSE, Oracle Linux, and their various versions and code names.

Upon install we see the following execution flow. We also see the child wslhost.exe of the initial distro install command, within that argument is a distro ID which is displayed every time a wsl session is started.

A screenshot of a computer terminal log showing timestamps, file paths, commands, process IDs, and initiating process IDs related to Windows Subsystem for Linux (WSL) and Kali Linux installations.

You can reg query this GUID against the host to reveal the distro name. This GUID will be bespoke to that device.

Command prompt window showing Windows registry query for Kali Linux current version and details

A ShellLinkCreateFileEvent will generate off the back of an LNK creation from the install by the parent of Windows Subsystem for Linux Service. This will indicate the distro installed.

Screenshot of system process details including timestamp, file path, and command line information.

Now let’s test both command and execution within the session to evaluate the telemetry in Defender.

Testing the below Linux commands provided zero evidence in process events. But as expected, network events are still present however there is no indication of process name or PID.

  
whoami
curl -s "https://api.ipify.org?format=json"
wget -qO- https://api/ipify.org

For execution I tested nmap. Again, zero indication of process or file telemetry. However we can identify the initial pull from apt-install using the displayed user agent ‘Debian APT-HTTP’. This is a useful indicator and can provide insight into package requests. This will also be visible in any proxy logging.

  
sudo apt install nmap
nmap -sS --top-ports 100 -T4 -sV scanme.nmap.org

Screenshot of network request details showing timestamp, action type, method, user agent, URI, host, and remote IP address.

WSL is cross directional, Windows commands and binaries can still be executed within the WSL session.

For example running Calc.exe from within the WSL will provide process logging.

A screenshot of a command prompt window showing system file paths and process information for calc.exe and wsl.exe.

Executing cmd.exe /c "net localgroup Administrators" does the same. Execution shown under wsl.exe.

Computer terminal displaying commands related to network local group management and process initiation, including 'net localgroup Administrators', 'cmd.exe /c

Files part of the subsystem are stored in \\wsl.localhost\(distroName)\*. There is zero logging regarding this path including file or process events from Defenders perspective. The only visibility is within the alert story from a detection.

Screenshot of a Windows Security alert indicating malware detection, showing details of a suspicious file named mimikat.exe interacting with lsil.exe, with a virus total detection ratio of 65/72.

To provide insight into WSL events, install the WSL plugin.

https://learn.microsoft.com/en-us/defender-endpoint/mde-plugin-wsl