Open House

As a compatibility layer, the Windows Subsystem for Linux (WSL) allows Linux binaries to run directly on Windows without any modifications. Users can call processes in Linux from Windows and vice versa with WSL, accessing files on both operating systems, sharing environment variables, and linking different commands.

Two WSL versions [1] have significantly different architectures: WSL  1 makes use of a translation layer that implements Linux system calls on top of the Windows kernel and can be achieved on minimal Pico processes and providers (lxss.sys and lxcore.sys) managed by a kernel mode driver. On its WSL blog, Microsoft provides more details on the role and history of the Pico processes [2]. In WSL  2, on the other hand, the source code of the Linux kernel is executed in a virtual machine, sized dynamically by Windows depending on the utilization level [3].

WSL is still in its early stages, but Microsoft is actively developing the project and adding additional features, such as GUI support for a fully integrated desktop experience [4]. The stated goal of WSL is to enable users to use their favorite Linux tools on Windows. However, WSL can also be misused for attacks. To do so, cybercriminals resort to various tactics, techniques, and procedures (TTPs).

TTP 1: Tools

Attackers bypass the requirement to enter a sudo password by passing the -u root argument to wsl.exe, making it far easier to download and deploy arbitrary tools to run or create payloads. Cybercriminals also can add repositories of hacking distributions to deploy tools with a package installer.

In a simple example of this technique, I use PowerShell, which interestingly can also be installed on Linux (Figure 1). What's more, you can easily download the tool from Microsoft's own repository. The obvious problem with this technology is that pwsh runs on Linux. Accordingly, some cmdlets are not available – for example, those for the Common Information Model (CIM) and Windows Management Instrumentation (WMI). However, attackers can execute remote commands from WSL with PowerShell or use PowerShell over SSH to access Windows-specific cmdlets, allowing them to bypass PowerShell script logging.

Figure 1: PowerShell runs on Linux, albeit with missing cmdlets, among other things.

However, the true strength of this attack technique is shown elsewhere: Hackers can develop modular loaders that are located entirely in WSL and then exploit the interoperability to run the Windows modules they need to achieve their goals. In fact, the loader completely disappears off the radar of most security solutions. For several years now, cyberattacks have been popping up time and again that take advantage of precisely this fact [5]: yet another tool in the attackers' arsenal that cyber defenders need to consider.

Containing this TTP is often difficult because installing utilities is basically a legitimate use case. Nevertheless, potentially malicious activity can be identified, for example, by deploying perimeter solutions with an anomaly detection function that includes identifying access to hacking repositories and verifying that the host in question has a legitimate use case for it.

TTP 2: Injecting an Attack Distro

Attackers have two options for installing their own distributions in WSL: They can either import a tarball or install the distribution directly from the Microsoft Store. Basically, any Linux variant will do; it does not have to come from the official Microsoft Store  [6]. Alternatively, the attacker can create their own Linux derivative for WSL with known threats and tools.

The command

PS> wsl --import <Distro>\<Install location> <File>

binds a distribution into WSL. You can currently obtain a whole range of Linux games from the Microsoft Store (see the box "Distributions in the Microsoft Store"). Noticeably, the popular penetration testing distribution Kali Linux is also in the store, which means that any Windows computer with WSL in its IT environment can potentially be turned into a Kali computer. Thanks to Win-KeX, Kali offers a full desktop interface on WSL  2 [7]. Additionally, Microsoft has released a preview of WSL  2 support for running Linux GUI applications [8].

Mitigating such an attack would rely largely on system policies being enabled that prevent the features required to install WSL. If users are allowed to use WSL, you can rely on command-line identifiers to track down potential installation activity.

TTP 3: Redirecting Execution

The Windows doskey.exe [9] utility calls the command-line history, edits the command line, and creates macros. What is exciting here is that macros take precedence over the PATH system variable search, which is why cybercriminals use it to disrupt the execution process.

Macros are instance-bound, however. To make them persist across all CMD instances, you need to create a macro definition file and add it to the AutoRun value under one of two keys, depending on the version of Windows you are using:

HKEY_CURRENT_USER\Software\Microsoft\Command Processor
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor

Alternatively, macros can be exported with the command:

PS> doskey.exe /macros > <file>

Redirecting execution to Linux can lead to persistence over patched binaries.

In a scenario of this type with SSH redirection, Windows uses OpenSSH. The required client is preinstalled in Windows 10 [10]. Even in the absence of SSH, the attacker can create an SSH macro and redirect it to WSL, as shown in Figure 2. It then becomes persistent by exporting the macros and making the necessary registry changes.

Figure 2: Even without SSH, macros can be created and redirected to WSL.

Linux has several SSH backdoors [11]. Popular backdoors include the universal SSH backdoor, which patches SSH and its associated libraries to allow SSH logins with a password set by the attacker. The patched SSH binary also records the usernames, passwords, and IP addresses of all incoming and outgoing SSH requests as plain text in logfiles. As soon as a Windows user logs in to a remote computer by SSH, their credentials are exposed and logged in WSL. Then, attackers use those credentials for lateral movements.

Existing security solutions should be designed to respond to the use of doskey.exe and the corresponding changes in the registry. However, a patched binary is not so easy to detect right away and would require the defender to run a check of the installed components (rpm -Va) within the WSL distributions. Another method is to use popular community tools like Rootkit Hunter to identify potentially malicious code.