Windows Subsystem for Linux and Forensic Analysis

*** EDIT 2017-10-17 ***

Windows Subsystem for Linux was in Beta at the time of writing and all artifacts/ paths mentioned relate to installation of WSL/ 'Bash on Ubuntu on Windows', using the methodology detailed in this post. Installation of a Linux userland via the Windows Store causes notable files to be located elsewhere within Windows. This is addressed in my addendum post 'Further Forensicating of Windows Subsystem for Linux'.

*** /EDIT 2017-10-17 ***

This is the first of two posts on the topic of the Windows Subsystem for Linux. In this pair of posts I hope to highlight the importance of being aware of Windows Subsystem for Linux when analysing certain systems, methods to identify its presence and forensically interesting artifacts for analysis. As with my last pair of posts, it seemed logical to break this topic down into two posts, a primer on Windows Subsystem for Linux (WSL) and how to identify it is installed on a system you are analysing, and a second post on the location of forensically interesting artifacts and other considerations during analysis.

Windows Subsystem for Linux

On 02 August 2016 Microsoft released Windows 10 Anniversary Update, and with it they handed users the Windows Subsystem for Linux (‘WSL'). WSL lets developers run Linux environments (including most command-line tools, utilities, and applications) directly on Windows, unmodified, without the overhead of a virtual machine. The majority of people I know (myself included) use Windows Subsystem for Linux to install 'Bash on Ubuntu on Windows', indeed Ubuntu was the only userland available at release although openSUSE and SUSE Linux Enterprise Server are both now downloadable and Fedora is apparently in the wings.

Still more recently Microsoft announced that they were bringing WSL to Windows Server. Microsoft consider this a Beta feature for Windows 10; however I believe it will be fully supported as of Fall Creators Update, expected to launch next month.

Evidently this is a feature in its infancy, with various aspects still only available via the Windows Insider program and further additional userlands (e.g. Fedora) promised, but yet to materialise. While WSL was initially marked as a beta feature at release, that hasn't stopped lots of keen users from installing it.

Personally, I installed Anniversary Update on my day-to-day system as soon as it was available and enabled Windows Subsystem for Linux immediately thereafter, the prospect of being able to drop into Bash and use Linux native commands was too much to resist. Since then I have employed the update and added WSL to my analysis machines and workflow. I was also able to run the old SIFT bootstrap script (with some modification) to install the myriad of tools available within SIFT to my WSL system. Full disclosure, this was a messy process which I have attempted to emulate more recently using SIFT CLI without success (yet!), I have not rolled this out to any of my analysis systems and I wouldn't recommend doing as such.

Windows Subsystem for Linux has recently garnered attention from the infosec community due to the perceived risk of 'bashware', i.e. the use of WSL to run malware which may be able to bypass Windows security software and protections. At the time of writing I believe that this has only been performed as a proof of concept and I am unaware of any instance where it has been seen in the wild. With this development in mind, analysis of artifacts associated with WSL will need to be a consideration when performing certain investigations. But this is by no means the only reason to be aware of forensic artifacts associated with WSL.

I have worked cases where the crux of the matter related to actions performed by the suspects while using Cygwin, in other cases all malicious activity was performed within a virtual machine running Linux on a Windows host. In both these scenarios it is easy for an investigator who has fallen into the Windows Forensics mindset to completely miss the presence of Linux artifacts which require analysis, and the same issue arises when we are confronted with a system with WSL enabled.

Installing Windows Subsystem for Linux

Analysis of a system with WSL does not require the investigator to install WSL themselves, however it will likely prove useful for testing the behavior of artifacts and validating statements in this post. With that in mind, the full official instructions are available here, but the edited highlights are as follows:

With Internet Access

Ensure you are running Windows 10 Anniversary Update or later (build 1607+) on a 64-bit system.

Enable WSL via the Windows Features dialog accessible from Control Panel -> Programs -> Programs and Features -> Turn Windows features on or off and select the check box for Windows Subsystem for Linux (Beta), per the below screenshot:

Alternatively, the same can be achieved with the PowerShell command:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Next we need to install the distribution of choice.

Members of the 'Windows Insider Program' can download Ubuntu, openSUSE or SLES via the Microsoft store. Once installed, select launch and you will be prompted to create a UNIX user account. Once the account is created you are good to go.

The process is slightly more involved if you aren't a member of the Windows Insider Program. The installation can be performed by running the bash command command, however you will need to enable Developer Mode first. Enable Developer mode via:

Settings -> Update and Security -> For developers and select the Developer Mode radio button.

Once developer mode is enabled, launch a command prompt and execute the command 'bash', this will prompt you to accept the license with 'y' and once accepted the Ubuntu user-mode image will be downloaded and extracted.

A new "Bash on Ubuntu on Windows" shortcut is added to the start menu, or alternatively it can be accessed by running the 'bash' command from the command prompt again. When you first launch Bash you will be prompted to create a UNIX user account. Once the account is created you are good to go. Note however that while the version at the windows store is relatively up to date this version is not, and as such it is advisable to run 'apt-get update' at this time.

Without Internet Access

The above instructions require an internet connected machine, which is a no go for many lab environments. Unfortunately, Microsoft do not offer an offline installer so we have to find an alternative solution.

There are two methods I have identified to get around this. The easier of the two is to use a program LxRunOffline (https://github.com/DDoSolitary/LxRunOffline) written by DDoSolitary which (per the readme) "uses InternetOpenUrl() in wininet.dll to download the files required. This application uses EasyHook to inject code to its process, and hooks this function and some others related. Then the download requests can be redirected to local files". This does of course require you to trust the code written by an internet stranger within your airgapped lab, or to perform a full code review and compile it yourself. Full instructions for the process are available here and consider it "at your own risk".

My preferred method is to host the Canonical image on a temporary internal web server, intercept the request made by lxrun to Microsoft's servers with fiddler and redirect to the downloaded version. Instructions are provided here.

Whichever method you use, once installed a new "Bash on Ubuntu on Windows" shortcut will be added to the start menu. You can access Bash by clicking the shortcut or by running the 'bash' command from a command prompt. When you first launch Bash you will be prompted to create a UNIX user account.

Detecting Windows Subsystem for Linux (BETA)

Note these locations relate to the Beta version of WSL. Installations via the Windows Store are now located within the associated App install folder.

Enabling Windows Subsystem for Linux and installing one of the available userland offerings causes a huge number of changes to a system. There are a number of things you can look out for to confirm its installation. The simplest indicator of WSL being installed for at least one user is the presence of the Bash executable at:

%systemroot%\System32\bash.exe

i.e. 'C:\Windows\System32\bash.exe

Additionally, the installation of 'Bash on Ubuntu on Windows' results in the creation of a 'HKLM\COMPONENTS\CanonicalData' key, as well as a huge number of other keys associated with enabling WSL, enabling developer mode and installing Bash. I have focused on Ubuntu in this post because at the time of writing it is the default userland and installation of alternatives requires membership of the Windows Insider program (or a manual unsupported installation). As other userland offerings reach general release we will start to see them in the wild more often, although I anticipate Ubuntu will remain dominant for some time.

It should be noted that installation of WSL is on a per user basis, this is of particular importance as we look to forensically interesting artifacts. On a multiuser system each Windows user has to install Bash independently, the associated filesystem is within the user's %localappdata% location and notable registry keys are stored within their NTUser.dat. Subsequently, on disk you can also look out for the presence of the Linux filesystem (for each individual user) located at:

%localappdata%\Lxss\rootfs

i.e. 'C:\Users\[Username]\AppData\Local\Lxss\rootfs'

In addition to checking for the presence of the Bash executable or the 'Lxss\rootfs' directory, the existence of the following registry key within an individual users NTUSER.DAT indicates that Bash is installed and configured for that user:

NTUSERDAT\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss

We will revisit this key and its contents when we look to forensically interesting artifacts in my next post.