Investigating Malicious Activity in WSL Environments
Background: Some XDR and EDR solutions are not effective when dealing with threats hidden inside WSL. In certain cases, it can also be challenging for digital forensic specialists to detect threats within WSL or to analyze the behavior of malware operating inside it.
For this reason, our article will be divided into two parts:
- How to identify threats in a running WSL instance from the Windows host through correlation
- How to detect malicious files even if WSL has been removed from the system
When WSL is running processes, you can detect suspicious activity from the Windows side without entering the WSL instance. For example, an administrator inspecting the Windows process tree may notice a process invoking network calls that appear to originate from WSL. Because Netcat (nc) is not installed on Windows by default, seeing network behavior tied to a non-Windows binary is a strong indicator of activity inside WSL.
To investigate, correlate any observed “living-off-the-land” binaries (LOLBINs) and unexpected child processes with the Windows components that spawned them. If you observe processes or binaries that are not native to Windows (or not normally present on the host), treat that as suspicious and investigate further — they may represent a hidden threat running inside WSL.
Let’s now deep dive into artifact discovery. When a user removes or interacts with WSL, the related data remains in an unencrypted form under:
C:\Users\
This state can appear in two formats: As a .vhdx file, As a regular folder tree
To analyze the .vhdx, simply copy it to another location and open it with a tool such as 7-Zip. This allows you to view all artifacts related to the Linux filesystem directly.
Conclusion: WSL is one of the most widely used implementations, relied on by millions of software engineers worldwide. However, it also introduces significant risks if a threat actor gains a foothold inside it. For example, an attacker could steal SSH keys or other sensitive credentials.
In many cases, WSL-related threats can arise from supply chain attacks, especially through the daily use of package managers and dependencies across different programming languages.