Over the years when presenting at conferences, user groups, and customer presentations I have often talked about some of the “new ways” to help learn tools and techniques in information security. One of the resources I specifically recommend is using Docker containers and Windows Subsystem for Linux to quickly experiment with tooling without the need to manage a virtual machine or other infrastructure.
I have often been asked to expand upon this topic so I wanted to document some of these methods in this blog post. More specifically we will be discussing the following methods for experimentation:
- Using Windows Subsystem for Linux (WSL)
- Using lightweight Docker containers to test specific information security tools
- Using the official Kali Docker Container to quickly test a wider variety of tools
- Building a highly customized Docker Container with a UI to provide easy testing of GUI based tools.
Please remember, the purpose of my process in this post is to provide additional options for you to quickly test and help learn information security tools. These methods will not appeal to everyone and many of my methods do not fit “best practices”. Now that we have that out of the way, I do feel that this can prove useful for those getting started in learning and exploring information security tooling.
Our experiments as noted in this post generally require the following:
- Windows 10 Pro with Update May Update 1903
- Hyper-V Feature Installed
- Windows Subsystem for Linux (Ideally V2 installed)
- Docker for Desktop Installed
I am using Windows 10 Pro with the May 1903 Update. This version will give you the best experience and access to Windows Subsystem for Linux v2.
I have the Hyper-V Role installed as it is needed for Docker Desktop Community Edition. Docker for Desktop is a free download and allows us to run Windows and Linux containers on Windows 10.
This configuration allows for a rapid authoring and deployment of Docker containers and Linux application usage through WSL. This means I have a variety of options to rapidly test information security tooling without having to go through the typical virtual machine management process or managing a lab. While having a virtual lab is extremely advantageous, having additional options to run experiments right from your workstation very quickly is also very useful.
Setting up Windows Subsystem for Linux
Windows Subsystem for Linux is a compatibility layer for running Linux binary executable natively on Windows 10 1607 and later. An interesting fact about WSL is that it isn’t based on virtual machines or containers. WSL provides a layer for mapping Windows kernel system calls to Linux kernel system calls. This allows Linux binaries to run in Windows unmodified. WSL also seamlessly maps Windows services, such as the file system and networking that Linux can access.
A Note About WSL 2
In May 2019, WSL2 was announced in preview. WSL 2 has all the same capabilities as WSL but has file system performance increases and full system call compatibility. WSL 2 uses a real Linux kernel to run ELF64 Linux binaries on Windows!
Even though WSL2 is still in preview – I would highly recommend installing and using WSL2 You can then follow the Windows Subsystem for Linux Installation Guide for Windows 10 documentation to install a Linux distro of your choice.
Testing Information Security Tools with Windows Subsystem for Linux
Now that we have configured WSL2 on our workstation, we can immediately start using it.
In my example, I am using the Ubuntu distribution. The WSL Kali distribution is also a great choice. On my workstation I use WSL for a variety of development purposes as well so I wanted a slightly lighter-weight experience so I choose the Ubuntu distribution.
Starting up your WSL instance is as simple as clicking a desktop icon, and immediately we have access to our Linux shell experience. Once I have my shell up and running, one of the first things I do is put a few essentials on my WSL instance. This includes GIT so I can clone GitHub repositories, next I’ll load a variety of frameworks such as Python and any text editors of choice (in my case Nano). Since our WSL IS an actual Linux instance we can install these applications just as we normally would with APT on a Debian based distribution:
sudo apt-get install -y python git nano
Now that we have the essentials we can start running some experiments!
One of my favorite things test is Password Spraying. It’s very simple to do and can be very effective, especially giving how easy it is to initiate. Let’s do some password spraying in our new WSL2 instance!
First, we need some scripts! I suggest the password spraying script: spray by Jacob Wilkin for its ease of use and effectiveness. First, we will clone the password spray script repository and use the scripts and resources to initiate a password spray against a domain machine!
# Clone the Repository git clone https://github.com/Greenwolf/Spray.git # Browse to the new folder cd Spray # Start the Spray.sh script with parameters (smb spray, Target, Usernames List, Passwords List, Timeout value, Domainname ) sudo /spray.sh -smb 192.168.15.1 name-lists/statistically-usernames/jsmith.txt passwords-English.txt 1 35 MyDomainName.com
What’s great about this example is now I have a tool running in a Linux instance on my Windows machine that I can call anytime in seconds. I enjoy using WSL on my desktop as in some cases it allows me to eliminate the need to jump to another virtual machine or ssh session as I can run my tools right from the Linux kernel on my Windows 10 desktop. It also tends to be faster than spinning up new Docker containers and is a great choice to test smaller scripts/applications.
Tool Learning via Docker with Dockerized Applications
For the rest of this post, we will be running experiments with Docker. While we will be running Docker on WINDOWS we will be running Linux containers. “Windows Containers” are an option but don’t have the same level of popularity or support that Linux Containers have, especially given the progress of .NET CORE support for Linux.
For my first example, I will be generating a lightweight container with Alpine Linux and NMAP. I will use a dockerfile to define my base image and then add NMAP. This will generate a container image that I can run anytime with alpine Linux and NMAP setup and ready to go. The best part? This container is only 20MB, which allows me to start the container and use this tool nearly instantly anytime, anywhere.
First, we define our dockerfile:
# Base from Lightweight Alpine Linux FROM alpine:latest # Install NMAP RUN apk add nmap --no-cache && rm -f /var/cache/apk/*
Now that we have a container image defined, we can initiate a docker build command to generate our new container (in my example named: “nmaptest”). This builds a new Docker container image that we can run interactively. This allows us to enter the container right directly and run NMAP.
docker build . -t nmaptest docker run -it nmaptest nmap -sn 127.0.0.1
This illustrates that we can use a very lightweight container to test individual tools in a “One Container, One Tool” model. This is a good option for trying to learn a specific tool. We can certainly use this method for more complex tools as well but this will require additional steps in our dockerfile.
Tool Learning via Docker with Kali Docker
If you don’t want to build a complex dockerfile yourself, you may be pleased to know that Kali Linux also has its own Docker Container! This provides a solid base instance for easy installation and testing of components from other Kali Metapackages. The Kali Docker Container has all the sources for Kali tool built-in but NOT the tools themselves.
Kali Linux Docker container By downloading the Kali Linux Docker – you can simply run the container and have command line access to a base Kali instance.
# Download the Container Images docker pull kaliLinux/kali-Linux-docker
For our first example we’ll perform the following steps:
- Run the Kali Container in interactive mode.
- Add sqlmap the “Automatic SQL injection and database takeover tool”
- Run Sqlmap.
This allows us to quickly get up and running with a more sophisticated tool than NMAP from our previous example. Since the Kali Linux container has many of the source lists and prerequisites ready we can very easily run sqlmap with minimal effort.
# Run the Container docker run -it kaliLinux/kali-Linux-docker # install sqlmap apt-get update && apt-get install -y sqlmap # Run the sqlmap wizard sqlmap --wizard
Using this base docker container image, you could easily customize your containers to run other kali compatible major tooling frameworks such as Burpsuite and Metasploit.com and smaller more laser-focused tooling such as BeEF, Hydra, and The Backdoor Factory
Alternatively, we could simply install one of the Kali Metapackages and have all the tools I would normally have in some of the larger Kali desktop images. Let’s run our Kali container again but this time let’s install the “kali-Linux-top10: Top 10 Kali Linux Tools” Package and run Metasploit:
# Run the Container docker run -it kaliLinux/kali-Linux-docker # install SQL MAP apt update && apt-get install -y kali-Linux-top10 # Start Metasploit msfconsole # Connect to MetaSploit DB (Note you will need to start PostgreSQL first) db_connect # Start wmap (Note you will need to create sites/targets to proceed) load wmap
This illustrates that we can use large containers to test multiple tools and frameworks in a “One Container, Many Tools” model. This is an option for trying to learn a broader set of tools.
Tool Learning with Highly Experimental UI Enabled Docker Containers
In this example, we will go far outside the traditional microservices use-case of docker, and we will be adding UI components to a container and remotely logging into a containerized Ubuntu OS preloaded with a variety of tools and utilities.
For demonstration, I have set up a repository with dockerfile and scripts to build and run this container.
NOTE – This is a very larger container not optimized for build performance and will take approximately 30 minutes to build.
This dockerfile is much more complex than our previous examples and will execute the following steps:
- Create a new image based on the latest Ubuntu Container Image
- Add VNC & noVNC for remote UI access
- Add the XFCE UI Components on the container
- Install a wide variety of tools, frameworks, and security tools.
- Initiate noVNC so we can access the UI of the container via a web browser.
DISCLAIMER This dockerfile results in 3.5 GB Container. This is NOT how you should build your containers. This is strictly a method used to experiment with Docker containers and to attempt to try out new security tools. DO NOT run this in your production environment. Only run this is network isolated dev environment as this container runs everything as root and has very weak security, plus the vnc password is in the repository 🙂 If you actually want to use please be responsible and make changes to the dockerfile and startup script to add the appropriate level of security & best practices you feel comfortable with.
We can run this container by performing the following steps:
- Cloning the Repository
- Building the Container Image
Run the container Image and map external port 6901 to the exposed port 6901 in our container for noVNC access via the browser.
git clone https://github.com/leeberg/BlueWhale.git docker build . -t sectoolstester docker run -it -p 6901:6901 sectoolstester:latest
Now that the container is running, Port 6901 will be exposed to a noVNC instance. This allows me to “Login” to my container providing access to the GUI of the operating system just as if I was using traditional RDP or VNC.
Now I have a container with a functional GUI operating system that is also preloaded with many tools ready to use. In my example dockerfile I have included a suite of development, database, and information security tools. I have also placed a “Tools” directory on the desktop with nearly 100 information security-related repositories as well. After building the initial docker container, we can start this instance and have access to all of these resources from a single command line.
Here are a few more examples of items/use cases included in this particular container.
Many InfoSec Tools and Browser Support
This illustrates an extreme use case whereas we can use an extremely large container to test multiple tools and frameworks with a UI in a “One Container, Many Tools” model. This is an option for trying to learn a broader set of tools and/or build a quick deployment lab instance of Linux.