*** 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 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.
Ubuntu, openSUSE and SUSE Linux Enterprise Server in the Microsoft Store |
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:
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
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.
This comment has been removed by a blog administrator.
ReplyDelete