Introduced in 2016, WSL (Windows Subsystem for Linux) allows developers to run Linux environments and command-line tools directly on Windows machines without the need to use virtualization platforms. Hence, with WSL, developers can run ELF files as they are, which obviously has many advantages.
However, as described here, WSL architecture also creates a new attack surface and enables AV bypass by avoiding Windows user mode hooks. Since WSL processes don’t use Win32 DLLs and interact directly with the Windows kernel, they avoid the standard user mode hooks, usually placed on Win32 API functions.
In this post, we will explain how SentinelOne’s agent monitors and prevents the abuse of WSL processes. We will also demonstrate how Linux ransomware which encrypts Windows user’s files via WSL, is detected by SentinelOne.
This article assumes the reader has prior knowledge of WSL internals. If you’re not familiar with WSL, please refer to this documentation provided by Microsoft.
The Detection-Prevention Challenge
As an AV solution, the main detection challenge is that you can’t rely on standard Win32 User Mode hooks, since WSL processes do not use them (more information about WSL syscalls execution can be found here). When a WSL process executes a user mode API function, it doesn’t pass through Win32 User mode hooks, because they are not loaded into WSL processes. Therefore the call will reach the kernel without being monitored by an AV.
Theoretically, it’s possible to install Linux user mode hooks and inject them to each WSL process. But it should be noted that there are many Linux distributions. The user can download and run a multitude of them on the same machine simultaneously. So it might be hard to stabilize and check each distribution, or find a generic way to communicate from any Pico process scope to the Win32 processes.
However, a suitable solution can be monitoring WSL processes from the kernel. There are multiple methods to implement kernel monitoring:
- Hook LxCore.sys functions – The problem with this option is that LxCore.sys is protected by Patchguard (as any Pico provider), so you can’t modify or hook its functions in order to monitor WSL activity.
- Set LxCore.sys to debug mode – It is possible to set WSL to debug mode and monitor function calls by parsing the debug strings. This method is problematic because it relies on the presence of strings which may be stripped out. Also, it might cause performance issues.
- Use Windows kernel functionality to monitor WSL processes – This is done by using features, such as kernel callbacks registration, kernel ETW events, minifilter driver, etc.
Comparing these three methods, we opted for using the Windows kernel functionality, which enabled us to implement the same detection and prevention heuristics for both Windows and Linux processes.
Preventing Execution of WSL Processes
As WSL is still under development, it is difficult to predict how attackers might abuse it in the near future. Therefore, we recommend users to avoid installing WSL on machines which don’t require using it. Still, in a post-exploitation scenario, attackers can enable developer mode, install WSL and use it for their own needs – bypass AV, gain persistency or privileges and so forth.
Another feature provided by SentinelOne agent is the ability to disable WSL. Customers can set the “Prevent WSL” configuration, which prevents WSL processes from running on the machine, even if WSL is already installed.
Demo – Detecting Linux Ransomware using WSL
For our demo, we downloaded an open source ransomware, named GonnaCry, from Github. We changed its encryption path to encrypt the windows C: drive user’s folder. The C: drive path in the Linux context is found at /mnt/c.
The following video demonstrates two scenarios: The first using an unprotected machine and the second using a machine that has a SentinelOne agent installed. In both scenarios we show the compilation and execution of the ransomware, where the latter shows a successful detection. Note that with SentinelOne, customers can rollback to the latest healthy state of the operating system and restore the original non-encrypted files.