WSL forensics: finding Linux distributions in the registry

WSL forensics is the part of a Windows investigation that most analysts skip, and attackers know it. The Windows Subsystem for Linux gives a user a full Linux environment on a Windows host — a separate filesystem, a separate process tree, a separate set of tools — and almost none of what happens inside that environment lands in the Windows event logs, Prefetch, or the usual execution artifacts you lean on. The one place the host reliably admits a Linux distribution ever existed is the registry: the Lxss key in the user's NTUSER.DAT. If you are not parsing it, you are walking past the front door of a whole second operating system.

This post is about that key, what it proves, what it does not, and how to pivot from a registry value to the distro's filesystem.

The Lxss key

The data lives under HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss in the user's NTUSER.DAT. WSL is configured per user, so this is a per-user artifact with clean attribution — the hive owner is the person who installed and ran the distribution.

Directly under Lxss you get one subkey per installed distribution, named with a GUID, plus a DefaultDistribution value at the root pointing at the GUID of whichever distro launches when you type wsl with no arguments. Each GUID subkey is the interesting part. The values that matter, and the ones the wsl plugin on this site pulls, are:

DistributionName: the human-readable name, e.g. Ubuntu-22.04, kali-linux, Debian. This is what the user typed wsl -d against.
BasePath: the directory on the Windows filesystem where the distribution's root filesystem lives. This is the pivot.
State: an integer status flag. In practice 1 is the normal "installed and ready" state. Treat the exact semantics of other values as version-dependent and verify against the live system rather than asserting from the registry alone.

The plugin keys on DistributionName — a GUID subkey with no DistributionName value is skipped as not a real distribution record. The output is one row per distribution: Distribution, Base path, State.

Other values you will commonly see in a GUID subkey, which the plugin does not currently surface but which are worth reading manually:

DefaultUid: the default Linux UID the distro launches as. 0 means it launches as root, which is worth a second look — a distro configured to drop you straight into a root shell is not the default Ubuntu install experience.
Flags: a bitmask controlling interop behavior. The bits historically include Windows-process interop, appending the Windows PATH, and automatic mounting of Windows drives under /mnt. I would not hang a conclusion on the exact bit values without confirming against the WSL version in question; the field has changed across WSL1, WSL2, and the Store-distributed wsl.exe.
Version: distinguishes WSL1 (a syscall translation layer, distro files sit as loose files on NTFS) from WSL2 (a real Linux kernel in a lightweight VM, distro files live inside a virtual disk). This distinction drives where the filesystem actually is — more on that below.

What it proves

A populated Lxss key proves one thing cleanly: a Linux environment existed on this Windows host, installed under this user's profile. That sounds modest. It is not.

The reason it matters is everything WSL does not generate. Process creation inside the distro does not raise Windows Security 4688 events. Binaries run inside the distro do not get Prefetch entries — Prefetch tracks the wsl.exe/wslhost.exe plumbing, at most, not nmap or python3 running inside the guest. AmCache and Shimcache track Windows PE execution, not ELF binaries inside an ext4 volume. UserAssist records the user double-clicking the Ubuntu tile once; it does not record the four hours of work that followed inside the shell. The user's bash history, the tools they compiled, the files they staged, the outbound connections they opened — all of that happens inside a filesystem the host's logging subsystem barely acknowledges.

So the Lxss key is the thread you pull. It does not tell you what was done inside the distro. It tells you that there is an inside, and where to find it.

The forensic pivot: BasePath to the filesystem

BasePath is the value that turns a registry finding into a filesystem investigation. It points at a directory, typically something like C:\Users\jdoe\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04LTS_<publisher-hash>\LocalState for a Store-installed distro, or a path the user chose for a manually imported one.

Inside that directory, for a WSL2 distribution, you are looking for the virtual disk:

<BasePath>\ext4.vhdx

That single file is the entire Linux root filesystem. It is a standard Hyper-V VHDX containing an ext4 volume. You can mount it read-only on an analysis workstation (wsl --mount --vhd <file> --bare, or any tooling that reads VHDX and ext4) and then you are doing ordinary Linux forensics: /home/<user>/.bash_history, /var/log, /etc/passwd, /root, cron, systemd units, SSH keys and known_hosts, package manager logs, whatever the user left behind. Carve it, hash it, timeline it like any Linux image.

For a WSL1 distribution the files are not in a VHDX — they sit as ordinary files on NTFS under the BasePath (often a rootfs subdirectory). That is easier to acquire but has its own quirk: the Linux metadata (permissions, ownership, symlinks) is stored in NTFS extended attributes, so a naive copy can lose it. Acquire with tooling that preserves EAs.

Either way, the move is the same: read BasePath from the registry, go to that location on disk, and recover the distro filesystem from your acquired image. The ext4.vhdx is part of the user's profile, so it is in your forensic image already — it gets backed up by VSS, it survives in file-history copies, and a deleted distro may leave a recoverable VHDX in unallocated space.

Why WSL is an anti-forensics surface

None of this is hypothetical. WSL has become a favored evasion technique precisely because of the logging gap described above. The pattern, defensively, looks like this:

An operator who can run code on the host installs or imports a WSL distribution — wsl --install, or wsl --import of a tarball they supply. Importing is the quieter route: it does not touch the Microsoft Store and it lets the operator ship a pre-built rootfs with their tools baked in.
Tooling that would be flagged or logged as a Windows binary — recon utilities, tunnelers, credential tools — runs as ELF binaries inside the distro instead, where Windows EDR has historically had weaker visibility.
The distro can reach back into the Windows filesystem (/mnt/c) and, with interop enabled, launch Windows processes — so it is not a sandbox, it is a launch pad with reduced telemetry.
When finished, wsl --unregister deletes the distribution and removes the Lxss GUID subkey.

That last step is the one to watch. Unregistering removes the live registry record, but the ext4.vhdx deletion and the key deletion both leave traces: VSS snapshots predating the unregister will still carry the Lxss subkey with its BasePath, and recovered deleted cells in the hive may still hold the DistributionName and BasePath values. A hive that shows the Lxss key present but empty, with a recent LastWrite, is itself a tell — same logic as a cleared UserAssist Count subkey. Pull every NTUSER.DAT you can from snapshots and diff the Lxss contents across time.

Modern EDR has closed some of this gap, with vendors adding WSL-aware visibility, but coverage is uneven and depends entirely on the product and configuration on the host you are examining. Do not assume the guest was monitored. Assume it was not, and go get the filesystem.

Putting it together

The workflow for a single host:

Parse the user's NTUSER.DAT and read HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss. Note every DistributionName, its BasePath, the State, and manually check DefaultUid, Flags, and Version in each GUID subkey.
A root DefaultUid of 0, a Kali or other offensive-tooling distro name, or a manually imported distro in a non-standard path are all reasons to prioritize that distro.
Go to each BasePath in your acquired image. Recover ext4.vhdx (WSL2) or the loose rootfs (WSL1).
Mount read-only and run Linux DFIR: shell history, logs, package installs, SSH artifacts, file timelines.
Check VSS for Lxss subkeys that no longer exist in the live hive — evidence of an unregistered distribution — and for older ext4.vhdx copies.

The registry step is small. It is also the only step that tells you the other steps are necessary.

Tools

RegRipper's wsl plugin. Lists installed Windows Subsystem for Linux distributions from the Lxss key — name, base path, state. Read the plugin source to confirm exactly which values it extracts on your RegRipper version, since the value set has drifted across WSL releases.
Eric Zimmerman's RECmd with a batch file targeting Lxss for CSV output.
The parser on this site surfaces the Lxss distributions in its tree view — you can analyze NTUSER.DAT in your browser with nothing uploaded. See the RegRipper plugins reference for the full artifact catalog, and the installed-software plugin notes for the complementary "what was installed on this host" picture.
For the filesystem step, anything that mounts VHDX and reads ext4: wsl --mount --vhd, libguestfs, or a Linux analysis VM.

Frequently asked questions

Where does Windows record installed WSL distributions? Under HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss in the user's NTUSER.DAT. Each installed distribution is a GUID-named subkey holding DistributionName, BasePath, State, and related values; a root DefaultDistribution value names the default.

What is the BasePath value for? It is the directory on the Windows filesystem where the distribution's root filesystem lives. For WSL2 that directory contains ext4.vhdx, the virtual disk holding the entire Linux filesystem; for WSL1 it holds the loose root files on NTFS. It is the pivot from the registry into Linux forensics.

Why is WSL a forensic blind spot? Activity inside a WSL distribution — ELF process execution, shell history, network connections, files staged inside the guest — largely escapes Windows execution artifacts and event logging. The Windows side may only show that the distro was launched, not what happened inside it.

Does the Lxss key prove a Linux environment was used? It proves one was installed under that user. To establish what was done you must recover and examine the distro filesystem (ext4.vhdx or rootfs), where the bash history, logs, and tools live.

Can a WSL distribution be deleted to hide activity? Yes — wsl --unregister removes the Lxss subkey and the VHDX. But VSS snapshots and recovered deleted hive cells frequently still carry the DistributionName and BasePath, and an empty Lxss key with a recent LastWrite is itself suspicious.