Windows Subsystem for Linux (WSL) is a feature in Windows that allows users to run a real Linux user space directly inside Windows, without needing a virtual machine or dual-boot setup. This feature is commonly used by different types of users such as developers, security teams, system administrators and home labbers.
Users can install a wide variety of Linux distributions directly from Microsoft store, via the control panel or using the command line. The default distribution is (unsurprisingly) Ubuntu, but this can be modified to any of the available distributions and even ones not listed, making the options pretty much endless.
The Ingenuity of Windows
After installing WSL, you can just type “WSL” in a command prompt, and it will open the Linux command prompt. Behind the scenes the flow is a little weird:
- When typing WSL, the system opens the WSL file found in the environmental path C:\Windows\System32 called wsl.exe.
- The registry key “Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\MSI\InstallLocation” is queried.
- Wsl.exe from system32 opens wsl.exe in the path specified in the registry key above, the default being “C:\Program Files\WSL\”.
- The 2nd wsl.exe opens, loading all the relevant configuration files and showing the Linux command prompt.
It’s not clear why this works the way it does. It could potentially have something to do with changes from WSL 1 to WSL 2, the current version.
From Subsystem to Subversion
Because of the way WSL is executed, there are two possible ways it can be abused.
- Modifying the registry key “Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\MSI\InstallLocation” to another path with a malicious file with the name “wsl.exe” would cause the file to be executed instead of the legitimate WSL.
- Replacing the wsl.exe file in “C:\Program Files\wsl\” with a malicious binary would have the same effect as above.
Bash Wait, There’s More!
Bash (Bourne Again Shell) is a command-line shell and scripting language used on Unix-like systems to run commands and automate tasks. It was introduced to Windows along with WSL, and it shares similar problems.
When executing bash.exe, it looks at the same registry key and behaves in the same way, meaning that both issues mentioned above are also present with Bash.
How to catch a rogue penguin
In order to detect an abuse of these issues, here are various things that we need to look out for:
Modification of the wsl.exe File in Program Files:
SecurityEvent
| where EventID == 4663
| where ObjectName =~ "c:\\program files\\wsl\\wsl.exe"
| where AccessMask =~ "0x2" or AccessList in~ ("%%4417", "WriteData")
| project-reorder Computer, Account, Process, AccessMask, AccessList, TimeGenerated
Registry modification to the InstallLocation key:
SecurityEvent
| where EventID == 4657
| where ObjectName has "\\Lxss\\MSI" and ObjectValueName =~ "InstallLocation"
| extend ['OperationType'] = extract("%%190+[0-9]",0,EventData)
| extend OperationType = replace_string(['OperationType'],'%%1904',"New Registry Value Created")
| extend OperationType = replace_string(['OperationType'],'%%1905',"Existing Registry Value Modified")
| extend OperationType = replace_string(['OperationType'],'%%1906',"Registry Value Deleted")
| project-reorder Account, Computer, EventData, OperationType, ObjectName, ObjectValueName, OldValueType, OldValue, NewValueType, NewValue, ProcessName, TimeGenerated
Make sure the key is monitored properly, as explained here.
Execution of wsl.exe from an Unusual Path:
SecurityEvent
| where EventID == 4688
| where NewProcessName endswith "\\wsl.exe"
| where NewProcessName !in~ ("c:\\windows\\system32\\wsl.exe", "c:\\program files\\wsl\\wsl.exe")
| project-reorder Computer, Account, NewProcessName, CommandLine, ParentProcessName, TimeGenerated
Conclusion
This is not considered a vulnerability by Microsoft, mainly because no boundaries are crossed. To perform any of the changes to either the registry keys or the files you will need access to a privileged account. Nevertheless, this is still an exposure that attackers could potentially use to evade defenses by masquerading as a legitimate tool (T1036.005) and for proxy execution using a system binary (T1218).
It is important to remember that there is a wide variety of binaries and tools available in Windows that attackers can use for malicious purposes, with more coming to light every year. Some of them have been seen in the wild while others only in posts like this one. That said, even if something wasn’t used in the wild, it’s wise to remember that most of the incidents in the world are not publicly documented and some of the tools could’ve been used in the past already.
About the Author
Liran Ravich is a Security Architect at CardinalOps, specializing in detection engineering and security operations. Prior to this role, he worked at the Israeli National Cyber Directorate (INCD), where he worked within the national CERT and held various cybersecurity roles across government agencies. He is also an active contributor to the MITRE ATT&CK framework since version 12.