DFIR vs WSL: digital forensics where two worlds meet

In brief

A talk with a negative result, and that is its main value: the Linux subsystem in Windows has practically no forensic artifacts of its own — no ETW providers, no text logs, no databases, only indirect traces in the registry and a couple of logs. What WSL2 does have is three properties that attackers make use of: Windows executables can be launched from a Linux distribution, the host file system is mounted inside it, and the network stack is isolated — that is, Sysmon and EDR on the host do not see the network activity. Then come three public cases (an ELF ransomware at Qilin affiliates, a stealer through npm typosquatting), the ways of persistence and of delivering a custom distribution, and the conclusion: there is no separate "WSL forensics", what is left is Windows forensics plus Linux forensics inside ext4.vhdx. Separately the speaker takes apart how a false list of groups appeared in publications, and calls it neural slop.

Key points

• An honest frame right away: "there won't be any bone-crushing digital forensics here, because, as it turned out, there are no forensic artifacts specifically related to this component".
• Checked by hand: there are no ETW providers that would write WSL events into the Windows Event Logs — a search of the extracted manifests for occurrences of "Subsystem" and "Linux" comes up empty. There are no text logs and no SQLite databases either; all that remains are indirect mentions in the event logs and in the registry.
• The history of the component: WSL1 — 2016, WSL2 — 2019. Separately, the EasyWSL tool turns images from Docker Hub into a full-fledged WSL distribution with import and export, and in 2025 Microsoft released the code — some of the drivers and libraries remained proprietary.
• The difference between the versions: WSL1 had a translation layer, Linux system calls went through the Windows kernel. In WSL2 a Linux virtual machine is spun up, and the distributions live inside it — there can be several of them at once, for example Kali and Ubuntu.
• Peculiarity 1: Windows executables can be run from a distribution — it is enough to type notepad.exe. For a SOC this looks like the wsl.exe process launching notepad.exe.
• Peculiarity 2: the Windows file system is mounted into every distribution, and copying works both ways. An important detail for analysts: file operations from WSL into the host file system are handled by the system process dllhost, and "in some EDR solutions there are simply no detection rules for this behavior".
• Peculiarity 3: the WSL2 network stack is fully isolated, so Sysmon or an EDR on the host will not see the network connections — all of it happens inside the virtual machine. "That's why attackers in some cases took advantage of exactly this".
• A practical detail about access: through wsl.exe you can get a listing of the distributions and run a command, and moreover "into every Linux distribution installed on the system we can easily log in as root" — no password is prompted.
• Launching Windows binaries from a distribution is disabled by two lines in the configuration file /etc/wsl.conf. Copying: from Windows into a distribution — via a UNC path of the form \wsl$ with the name of the distribution, from a distribution to the host — via the /mnt directory.
• A methodological aside: two or three sources claimed that WSL had been used by well-known groups (Turla, FIN7, Ryuk were named), but there are no other mentions of this anywhere. The speaker's conclusion: it was "just some kind of neural slop, where the person didn't actually check what was written", and collected data on groups has to be double-checked.
• Case 1 (2017): a company reported that it had found an ELF file that interacted with WSL — "there are no specifics, none at all".
• Case 2 (early February 2026, Qilin affiliates): entry into the infrastructure through RDP or an already present RAT, then activation or deployment of WSL (in the second case full control rights are needed), loading the ransomware in ELF format and running it in the WSL environment. Since the Windows file system is mounted, the ELF goes through the files on NTFS — the output is encrypted user files on the host Windows.
• Case 3 (August): npm typosquatting — around 40–50 packages with names differing by a swap of two adjacent characters or by an "l" replaced with a one. The delivered script checked whether the system was Linux, then, by two environment variables, whether it was WSL, after which it downloaded a stealer, copied it from WSL into the Windows file system, launched it and stole credential data.
• Two vectors: from the side of the distribution (a malicious script or package) and from the Windows side (access to the host with privilege escalation). In the second case what matters is whether WSL is installed: if it is not, admin rights are needed to enable the WSL and Hyper-V components; if it is — downloading a distribution is enough.
• Persistence 1: in /etc/wsl.conf, in the boot section, the command key sets the command that is run at the launch of the distribution — in the example this is a reverse shell that gives the attacker a shell on the victim's machine.
• Persistence 2 via a WSL plugin — it "mostly won't work": a digital signature from a trusted authority is needed, otherwise you will have to disable the distrust of self-signed certificates. If a signature has been stolen, a DLL with a payload is signed (for example, downloading a beacon) and registered in the registry; the payload fires when the WSL service restarts or at system startup.
• Delivery: an open project on GitHub builds a custom WSL distribution with a payload — in the demonstration a calculator is launched when you enter the distribution. The build runs on Alpine Linux, the result is around 10 MB.
• Detection: the registry has a key with the list of installed distributions — the name, the path and the name of the virtual disk. In the indirect logs the main occurrence is the virtual disk file, ext4.vhdx by default: it can be used both to set up rules with a SOC and to search by hand.
• Simpler ways of delivery: pack a small distribution into an archive and import it, specifying the path to ext4.vhdx, or bring nothing from your own server at all — download an image (Kali, for example) with the winget utility from the store or from the repository. The traces of winget are useful for the defense: its logs keep the command itself, whether it succeeded and the fact of an installation.
• A SpecterOps study is mentioned: processes in the Linux container can be launched directly through a COM interface, without wsl.exe — the researchers got to this after the WSL code was published.
• The final conclusion: since there are no artifacts of its own, "we come back to the standard" — Windows forensics on the host plus Linux forensics inside the distribution. The order of steps: first the base artifacts and logs of Windows (is WSL installed, are the components enabled, are there distributions); if a distribution appeared at an odd moment and nobody uses it — a triage or copying ext4.vhdx and analyzing it; as an incident responder — form a hypothesis based on current TTPs and then work through the Linux artifacts and logs.

Tools, artifacts, technologies

• WSL1 (a system call translation layer) and WSL2 (a Linux VM on Hyper-V), the WSL service and separate distributions, EasyWSL, the opened WSL code (2025).
• Artifacts and traces: the registry key with the list of distributions (name, path, virtual disk), ext4.vhdx, indirect entries in the event logs, winget logs, the dllhost process during file operations, wsl.exe as the parent process when Windows binaries are launched.
• Configuration and persistence: /etc/wsl.conf (disabling the launch of Windows binaries; the boot section with a command), WSL plugins and a signed DLL, Secure Boot as an obstacle.
• Exchange paths: the UNC path \\wsl$, the /mnt directory.
• The attacking side: ransomware in ELF format (Qilin affiliates), a stealer through npm typosquatting, a reverse shell, a beacon, a custom distribution on Alpine Linux (~10 MB), delivery through winget and the Microsoft Store.
• The defending side: Sysmon, EDR, the Windows Defender plugin (turned out to be useless for logs), the SpecterOps study on launching through COM.

Legal and organizational context

There is no legal or procedural content — the talk is purely technical, addressed to DFIR specialists and to SOCs. There is one organizational recommendation and it comes in an answer to a question: restrict the use of WSL for users and monitor the enabling of the components, since only a handful of people need the subsystem — "hardly some accountant or lawyer".

Questions from the audience

• 1 (name not given): can auditing be set up inside the Linux subsystem and the logs be output to a path mounted on Windows? → Yes, most likely this is a workable option. The speaker had tried that route through WSL plugins, found the Windows Defender plugin and hoped that it would at least save logs to files — it turned out it does not. Plugins would in principle fit (running inside the Linux VM, collecting logs from all the distributions at once), but Secure Boot will have to be disabled and a self-signed certificate trusted. The practical conclusion: either restrict WSL and monitor the enabling of the components, or put your own monitoring tool inside the distribution and copy what it collects to the host.
• 2 (name not given): do modern EDRs look inside Hyper-V containers? → There is no direct answer: "I don't have that kind of analytics or statistics"; international vendors, by his observation, are introducing such functionality, about the Russian market he does not know. Since the main cases appeared in 2026, "apparently there is some need after all to dig deeper" into the Linux VM.
• 3 (the same questioner): is the mere fact of Hyper-V starting up already a signal? → "It will be a signal, 100%", but context is needed: it makes more sense to target those users who genuinely need the tool.
• 4 (the same questioner): can the virtual disk of a distribution be encrypted so that a forensic examiner gets nothing without a key, with the key fetched, say, over DNS? → Technically possible, but attackers will not do it: they need to get the matter through to the ransom without errors — "you come into the chat to talk with them, and they go: OK, great, send us some files to check", and if the files cannot be recovered, "they won't get their potential money".

The speaker's position

A rare talk built on a negative result and stating so outright: there are no artifacts, there will be no magic log, work with the standard means of the two operating systems. The strongest episode is the analysis of how an unreliable claim about groups spread through publications, and the refusal to repeat it. Where there is no data, the speaker says he does not have "that kind of analytics or statistics" instead of giving estimates. The other side: the attacking part is worked through noticeably better than the defensive one, and he cannot offer any specific means of detection — the limit of the recommendations comes down to "restrict and monitor the enabling of the components".

Quotes

• "…as it turned out, there are no forensic artifacts specifically related to this component".
• "Sometimes it happens that in some EDR solutions there are simply no detection rules for this behavior".
• "It turned out to be just some kind of neural slop, where the person didn't actually check what was written".
• "Since our host system is Windows, this is Windows forensics".
• "Potentially you can do that, but attackers are unlikely to…"