Windows Subsystem for Linux (WSL)

What it is

The Windows Subsystem for Linux runs Linux user space on Windows 10 and 11. WSL1 translates Linux system calls through a kernel driver (lxss.sys / lxcore.sys) and stores the Linux file system as ordinary NTFS files. WSL2 runs a real Linux kernel in a lightweight Hyper-V utility VM, with the distro's file system inside an ext4.vhdx virtual disk. For an investigator a WSL distro is a second operating system on the same disk: its shell history, SSH keys, cron jobs and dropped tools are Linux artifacts, and most Windows telemetry never sees what happens inside it.

Location

What it proves

• Installation: an Lxss subkey shows a distro was registered for that user, with its name and storage path.
• Execution of WSL: Prefetch and Amcache entries for wsl.exe, bash.exe, wslhost.exe or the distro launcher (ubuntu.exe, kali.exe) prove WSL was started, and when.
• Linux activity: .bash_history, /var/log, /tmp, /etc/passwd, crontabs and SSH material inside the distro show what was done in Linux.
• File exchange: paths like \\wsl$\Ubuntu\home\... or \\wsl.localhost\... in ShellBags, LNK files and Jump Lists prove Windows applications browsed the Linux file system. Inside Linux, /mnt/c/... in shell history shows the reverse.

It does not give you per-command Windows evidence. Linux processes run under WSL do not generate Prefetch files for the ELF binaries, and in WSL2 they run inside a VM outside most Windows process telemetry. Absence of Linux history is also weak evidence: HISTFILE can be unset, and history is only flushed when the shell exits cleanly.

Key fields

Timestamps

• Lxss subkey LastWrite (FILETIME, UTC): registration or last configuration change (conversion, default user change).
• Prefetch / Amcache for WSL binaries: first and last launches in UTC.
• ext4.vhdx $SI modification time: roughly the last time the WSL2 VM wrote to the distro.
• Inside the distro: ext4 inode times (atime, mtime, ctime and crtime) in Unix epoch, UTC. In WSL1, Linux times are stored in NTFS extended attributes alongside normal NTFS timestamps, so both sets exist and can disagree.

Retention and clearing

A distro persists until wsl --unregister <name>, which deletes the rootfs or ext4.vhdx without prompting; the Lxss key disappears with it. The deleted VHDX may be recoverable from unallocated space or Volume Shadow Copies, and the $MFT and USN journal keep its file name and deletion time. Uninstalling the Store app also removes the package folder. Windows-side execution traces follow normal Prefetch and Amcache retention.

Collection

# Registered distros for the current user
Get-ChildItem 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss' |
  ForEach-Object { Get-ItemProperty $_.PsPath } |
  Select-Object PSChildName, DistributionName, BasePath, Flags, DefaultUid, PackageFamilyName
wsl --list --verbose

:: Stop the VM so ext4.vhdx is no longer locked, then copy it
wsl --shutdown
robocopy "%LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalState" E:\case\wsl ext4.vhdx /COPY:DAT

On a triage image, collect every user's NTUSER.DAT, the LocalState folders and any custom BasePath. For WSL1, copying rootfs with Windows tools loses Linux permissions and extended attributes; prefer a raw image or an NTFS-aware collector.

Parsing tools

• Registry Explorer / RegRipper for the Lxss key in offline hives.
• PECmd and AmcacheParser for WSL binary execution.
• Arsenal Image Mounter, qemu-nbd or guestmount on Linux to mount ext4.vhdx read-only; The Sleuth Kit and Plaso (dfVFS) can read VHDX and ext4 directly.
• Once mounted, treat it as a Linux system: shell histories, auth.log, crontabs, ~/.ssh, package manager logs. The linuxforensics.app cheat sheets cover those artifacts in depth.

Investigation tips

• On a server or finance workstation, any Lxss key is worth a question. Check whether the WSL optional feature or VirtualMachinePlatform was enabled recently and by whom.
• PackageFamilyName empty plus an odd BasePath means wsl --import of a custom tarball: attackers use this to bring a preconfigured distro with tools already inside.
• Attackers favour WSL2 to run Linux tooling (scanners, tunnels, credential tools) out of reach of Windows EDR hooks. Network connections from WSL2 appear to come from the VM's virtual adapter; correlate with firewall logs and SRUM for wslhost.exe or the vmmem / vmmemWSL process.
• Search Windows artifacts for \\wsl$ and \\wsl.localhost paths, and Linux history for /mnt/c/Users/: that is where data crosses between the two worlds.
• DefaultUid 0 means the distro logs in as root, which removes sudo traces from auth.log.