This post is the second of a multi-part blog series that explores and highlights the different risks that Windows Subsystem for Linux (WSL) poses to an enterprise IT environment. Here we examine different TTPs that abuse WSL and assess different methods to defend against such threats.

← Go to Part 1

Attack Tactics, Techniques & Procedures Using Windows Subsystem for Linux

In our previous blog post, we provided some details about Windows Subsystem for Linux, described our test environment, and detailed how an attacker enables WSL. We then analysed an attack tactic, technique, and procedure (TTP) called Proxying Execution.

Here in Part 2, we will look at additional TTPs as well as various threat hunting and system hardening methods that can help defend your enterprise against these threats.

TTP #2: Installing Utilities

Adversaries can bypass the need for a sudo password by passing the argument -u root to wsl.exe. Therefore, installing utilities is a lot easier for them inside WSL. Thus, they can bring down and use any tool of their choice to execute or build their payloads. Additionally, they can add repositories of hacking distributions to bring down tools via the package installer (fig. 1).

Let’s look at one such simple example involving PowerShell.

Interestingly enough, PowerShell can be installed on Linux (fig. 2). Moreover, it will be downloaded from Microsoft’s own repository.

The obvious issue with this technique is that pwsh is running inside Linux and some cmdlets such as those related to CIM and WMI will not be available. However, adversaries can still use PowerShell remoting from inside WSL, or use PowerShell over SSH if they need access to windows specific cmdlets. This will also bypass PowerShell script logs. Although the true strength of this technique lies in building modular loaders residing completely inside WSL that abuse interoperability to execute Windows modules to achieve adversary goals. The loader in effect becomes completely invisible to most security solutions. Some attacks have already been observed taking advantage of precisely this fact.

This adds another tool in an attacker’s arsenal that cyber defences will now need to consider.

TTP #3: Installing Attacker Distributions

Adversaries can install distributions by either importing a tar file or installing it directly from the Microsoft store. Imported distributions can be any Linux flavour and need not be part of Microsoft’s official store. Adversaries can also create custom Linux distribution for WSL with known threats and tools.

A distribution can be imported via the command:

wsl --import <Distro> <InstallLocation> <FileName>

The currently available distributions in the Microsoft store are shown in figure 3.

Interestingly, a popular penetration testing distribution named Kali is also available for installation from the store. Therefore, any windows machine in the environment with WSL can be potentially turned into a Kali machine. Kali on WSL2 also has a full desktop experience via Win-Kex. Microsoft has also released a preview for WSL2 with Linux GUI application support.

TTP #4: Hijack Execution Flow by Redirecting to Linux Utilities

Doskey.exe is a Windows utility that recalls command line history, edits the command line, and creates macros. Interestingly, macros take precedence over the PATH environment variable lookup and thus can be used to hijack execution flow. However, macros are instance bound. Therefore, to make them persistent across all cmd instances we need to create a macro definition file and add it to the AutoRun value under the keys

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

depending on your Windows version. Macros can also be exported by using the following command:

doskey.exe /macros > <filename>

Redirecting execution to Linux can result in persistence via patched binaries. Let’s look at one such scenario by redirecting SSH.

Windows uses openSSH and the SSH client for it comes preinstalled on Windows 10. Even if SSH is unavailable we can still create a SSH macro and redirect it to WSL (fig. 4). We can then make it persistent by exporting the macros and then making the required registry changes.

Linux has several SSH backdoors. One such popular backdoor is the Universal SSH Backdoor that patches SSH and its related libraries to allow SSH logins with an attacker defined password. The patched SSH binary also logs usernames, passwords, and IP of all incoming and outgoing SSH requests in cleartext in log files. Therefore, every time a Windows user uses SSH to login to a remote machine his credentials are leaked and logged in WSL. Attackers can then use those credentials for lateral movement.

Threat Hunting on Windows Subsystem for Linux

Usage of WSL in the environment is suspicious if it’s not part of normally used development tools. Monitor for command lines involving the usage of wsl.exe and bash.exe (fig. 6, 7). Usage of DISM or PowerShell to enable WSL or virtualisation features also indicate suspicious behaviour (fig. 5).

Existing customers of Qualys can use the following QQL (Qualys Query Language) to identify WSL related suspicious behaviour on EDR:

mitre.attack.technique.id:"Q0053" 

Customers can also use Qualys Cyber Security Asset Management (CSAM) to identify all systems in their environment that have WSL enabled by using the query:

services:(name:LxssManager)

The LXSS Manager Service is the service in charge of interacting with the subsystem and can also act as an indicator of its installation (fig 8).

System Hardening to Protect Windows Subsystem for Linux

System administrators can mitigate WSL threats by applying policies against optional features. Virtualization and WSL can be disabled by using the Disable-WindowsOptionalFeature PowerShell cmdlet or the DISM utility. Administrators can also hide the “Turn Windows features on or off” task by setting the NoWindowsFeatures value to 1 in the registry paths:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Programs
and
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Programs 

Logging and auditing of processes via products like EDR can also reduce potential risk.

Conclusion

Windows Subsystem for Linux is a beneficial technology that aims to improve productivity by mixing in applications and utilities from different distributions into the Windows experience. However, such a massive undertaking is bound to have some security implications. As adversaries explore WSL to identify newer TTPs, so too must defenders to protect against them.

In this blog post, we examined some elementary threats that WSL brings to an environment. In the next post, we will explore the different binaries that make up WSL and identify potential abuses.