Hack Lab Part 3: Installing the Victim Machine on a Virtual Network and Basic Exploits

This post is part three in our tutorial series on how to set up a home hacking and security testing lab. If you followed along in parts one and two, you have installed a Kali virtual machine in VirtualBox on your primary computer, and have begun exploring your home computer network with nmap and Wireshark, both of which come bundled in Kali.

In the present article, we will walk through the creation and installation of our victim machine, a virtual instance of Metasploitable2, and then configure our first lab network: a completely virtual internal network inside VirtualBox. We'll place the Metasploitable2 victim machine and the Kali attack machine on the virtual network, and conclude by showing one way to begin exploring and exploiting Metasploitable's various vulnerabilities with Kali, and then provide some resources for further study.

On that note, it must be stated at the outset that Metasploitable is an intentionally insecure machine, with a ridiculous number of vulnerabilities. It should never be exposed to the internet, or to an untrusted network. This is why we will connect it to a completely virtual network, one that cannot even be accessed by the host machine that is running VirtualBox.


Installing Metasploitable2 in VirtualBox
There are number of subtle differences between creating a Metasploitable virtual machine and creating a virtual instance of an everyday operating system such as Kali in VirtualBox, as wel shall see. Metasploitable2 is a prepackaged system intended for security testing and practicing common exploit techniques. Once the machine is set up, it does not require any updates or further configuration as was the case with Kali.

The first step, of course, is to download a copy of the Metasploitable2. Metasploitable2 was developed by Rapid7, the IT security group that created the Metasploit Framework, "a tool for developing and executing exploit code against a remote target machine," as noted at Wikipedia. The Metasploit Framework, as you may know, is also bundled in Kali, and the intentionally vulnerable Metasploitable2 system was created to provide a way to test the sorts of exploits that can be launched from Metasploit, among other tools.

You can download Metasploitable2 from Rapid7, but it is also available from other sources such as SourceForge. Once you've downloaded the file, unzip it, and place it wherever you prefer. I keep all my virtual machine .iso files and the like in a dedicated folder.

In the Metasploitable2 download, you'll notice a few differences from your Kali download. For Kali, we used the .iso disk image file to install the system on the machine. There is no .iso file for Metasploitable2. Instead we are instead going to install the Metasploitable.vmdk file, which stands for virtual machine disk format.

Start up VirtualBox and click "New" to begin setup of the victim system. Name the new virtual machine, select its type and version. I've just used the defaults here: Ubuntu, 32 bit. Click "Next".

Since we will not be using the Metasploitable system directly, but rather only interacting with it as a target, we can lower the amount of RAM we allocate for it.  I've chosen 384 MB as the initial setting. After you get it up and running, you might find that you can reduce it even further. In my experience, response times begin to noticeably lag around 256MB of RAM. Click "Next".

We do not need to create a virtual hard drive for Metasploitable. Instead the .vmdk file will act as a virtual hard drive itself. Select "Use an existing virtual hard drive file", then click the file-browser icon, navigate to your Metasploitable download files, and select the .vmdk file. Click "Create".

The newly created instance should now appear in your VirtualBox interface. Notice I have grouped my kali1 instance and my Metasploitable2 instances inside a folder labeled 'lab'. Grouping becomes very helpful once you have more than a couple virtual machines set up.

Now we need to tweak a couple settings for our Metasploitalbe virtual machine. Open the Settings window. I uncheck 'Floppy' in the boot order under the System menu, though this is not very important. In the Network settings, you'll notice that the default is the same as it was for Kali: there is a single network adapter enabled with NAT, natural address translation.

We're going to change NAT to an internal VirtualBox network. In the "Attached to" drop down menu, change adapter one by attaching it to "Internal Network". You can also name your new virtual network. The default name is 'intnet'. I'm going to call mine 'labnet'. Click OK.

We're not quite ready to fire up our victim system just yet. Or at least, I'm not, because I've chosen a new name for my internal network. My experience with internal networks in VirtualBox has been a bit inconsistent. I clearly recall that the first time I used an internal network, it just worked and no further config was necessary. On another computer, I later found that the default internal network 'intnet' had to be configured as you would any custom internal network. If you fire up your Metasploitable virtual machine, log in and find that you have a functioning ip address, you're all set and can skip the following section. Otherwise, read on.

Configuring the VirtualBox Internal Network
I have to now enable the VirtualBox internal network 'labnet' to which I've just attached my Metasploitable virtual machine. If we take a look at the VirtualBox user manual section on Internal Networking, we read:

Unless you configure the (virtual) network cards in the guest operating systems that are participating in the internal network to use static IP addresses, you may want to use the DHCP server that is built into VirtualBox to manage IP addresses for the internal network. Please see Section 8.35, “VBoxManage dhcpserver” for details.

Rather than set up static ip addresses for our virtual machines on the virtual internal network, let's set up the virtual dhcp server. Reading through the VirtualBox user manual section on managing the dhcp server, we can conclude that running the following command in a terminal on the host computer will appropriately configure the internal labnet network.

VBoxManage dhcpserver add --netname labnet --ip 192.168.1.1 --netmask 255.255.255.0 --lowerip 192.168.1.2 --upperip 192.168.1.255 --enable

What's going on here? Let's parse this command.

• There is the command for the VirtualBox dhcp server: VBoxManage dhcpserver
• We want to create a new network, therefore: add
• We indicate the name of the new network: --netname labnet
• We specify the ip address of the dhcp server itself: --ip 192.168.1.1
• We specify the subnet or netmask: --netmask 255.255.255.0
• We specify the lower ip address for the server: --lowerip 192.168.1.2
• We specify the upper ip address for the server --upperip 192.168.1.254
• Finally, we enable the network so it starts any time a machine on the network is started: --enable

If successful, you can now fire up your new victim system and it will automatically be connected to the newly-configured internal virtual network. Go to the VirtualBox interface, select the system and click Start. This is the Metasploitable login screen:

Run ip addr or ifconfig to confirm that the system has been given an ip address and make a note of it. The victim is prepped. Did I mention? Metasploitable is an intentionally insecure machine, with a ridiculous number of vulnerabilities. It should never be exposed to the internet, or to an insecure network!

Now let's put our attack machine on the internal network. Network adapters can be changed in this manner even if the machine is running, though in my experience, this can also lead to minor glitches in the functioning of the VM, so I usually shut down if I'm going to change network settings for a VM.

Select your Kali instance in the VirtualBox application interface, click Settings, go to the Network settings. Change the adapter from Bridged to Internal Network, and select the name of your newly created internal network. I also "Allow All" in promiscuous mode under the advanced settings, as this allows the Kali network interface to detect any and all packets to and from the other virtual machine (as well as the host computer, if it were able to connect to the same network). Click OK.

Start up Kali and log in if the machine is not running. Check ip addr or ifconfig to make sure you have gotten an ip address from the virtual dchp server. If so, you're all good! Open up the Ice Weasel browser that comes bundled with Kali. In the address bar, enter the ip address of your Metasploitable instance. When the page loads, you should see the web interface that is pre-configred on the Metasploitable virtual machine. It comes packaged with 5 different websites/webapps that are intentionally insecure: TWiki, phpMyAdmin, Mutillidae, DVWA, WebDAV:

At this point, you now have a virtual internal lab network running on your host computer, and two virtual machines running on that network: your Kali attack machine and your Metasploitable victim machine. Remember, this network is completely internal to VirtualBox. Your virtual machines cannot communicate with the host computer over this network and the host computer cannot communicate with the virtual machines over this network. They are isolated.

Exploring Metasploitable's Vulnerabilities
Now the real fun begins! The first thing you might do here is passive network monitoring to see what kind of packets, if any, the victim machine is sending out over the network. Fire up Wireshark inside Kali, and start a capture on the appropriate interface for the lab network. (See part two of this series on how to configure Wireshark for live capture.)

From the packet capture, you'll soon notice that Metasploitable sends out workstation and workgroup announcements every couple of minutes for services that are running on it. If you inspect those packets more closely, you'll find that those packets contain a good deal of information about the host machine sending them, as well as about the services running on it.

An an exercise, confirm by inspecting the packets you've captured that Metasploitable is: 1) a workstation, 2) a server, 3) a print queue server, 4) a Xenix server, 5) an NT Workstation, 6) an NT Server, and 7) a Master Browser. You can doubly confirm that the machine is running such services by browsing its shares over the network in the file manager. But where can we find the network login credentials to view the shares?

Now that we have some idea of what we're dealing with, let's conduct a few port scans of the victim system to see what vulnerabilities that might expose. Let's just go through some of the various default scan types built in to Zenmap to see what they bring to light.

A ping scan reveals that the host is up. A quick scan identifies 18 open ports, among them the reserved ports for ftp, ssh, telnet, smtp, htttp, mysql and so on. A regular scan identifies 23 open ports. An intense scan also reveals 23 open ports, but it also provides operating system and version information, along with more detailed information about the services running on the various ports. For example, it notes that anonymous ftp login is allowed on port 21, identifies the SSH server's hostkey fingerprint, and so on. Run the more intensive scans to see what else you can find.

As an exercise, analyze the command options used in the various Zenmap scans to determine why those particular scans revealed that particular information.  

It is worth noting here that a couple leads for tracking down Metasploitable's network login credentials are provided already in the simple quick scan. However, it is indicative of the system's complete insecurity that these leads make the question of determining the network login credentials moot. Can you identify any such lead and why it moots our earlier question?

If you've followed along this far, you're probably asking yourself: what's next?  (That is, if you haven't jumped ahead already.) Well, you now have a fully functioning virtual hacking lab outfitted with one of the most powerful attack systems and one of the most vulnerable victim systems around. It's time to start exploring some of the more involved tools bundled in Kali and see what other kinds of weaknesses you can identify and exploit in the various services running on the victim machine, including in the five websites and applications running on the system.  That, however, is beyond the scope of the present article, but here are some resources to help get started:

• Metasploit Unleashed, an introduction the Metasploit Framework
• Burp Suite's introductory tutorial documentation
• OWASP-ZAP, the OWASP Zed Attack Proxy Project website

Like nmap and Wireshark, all three of these tools are listed in Kali's "Top Ten Security Tools" menu.

That concludes the present article. In part four of the series, we'll set up an external local area network and demonstrate how it is possible to steal login credentials from a victim machine logging in to a compromised router. As always, questions, comments, suggestions and criticism are welcome below.

Hack Lab Part 2: Exploring Your Home Computer Network with Kali Linux

This article is part two in our tutorial series on how to set up a home hacking and security testing lab. If you followed along in part one, installing a Kali Linux virtual machine in VirtualBox, you have installed VirtualBox on the primary computer for your home lab and created a Kali Linux virtual guest on this host machine. The Kali system has been fully updated and VirtualBox Guest Additions have been installed on it. Finally, your Kali VM has a single network adapter running in bridged mode and you have set up an administrator account on the Kali instance. 

Creating and configuring the virtual network setup outlined in the introduction, which we will do in part three of this series, requires a few more steps: we still have to download and install Metasploitable, set up the virtual network, etc. But if you're like me, you're probably already itching to start playing with all the toys Kali has to offer, if you haven't already!

Home Network Analysis 101
This article will show how some of the tools that come bundled in Kali can be used to explore your existing home computer network, and test whether you can successfully identify all the devices that are connected to it. In particular, we'll take a look at a set of tools that come bundled in Kali that can be used for network analysis: nmap/Zenmap and dumpcap/Wireshark.

These will come in handy in our eventual testing lab, but they can obviously also be used to explore your home local area network as well. Nmap is a command line network scanner, and Zenmap is a graphical interface to nmap. Dumpcap is a command line network traffic monitor, and Wireshark provides a powerful and versatile graphical interface to monitor network traffic and analyze network packet capture files.

Here's a simple experiment. Do you happen to know how many devices are currently connected to your home network? Can you identify all of them off the top of your head? Try to do so, and make a list of them. At the very least, we know there will be at least three: the Kali guest, the host machine you are running Kali on, and your router. There may also be more computers or cell phones connected to it, and maybe even your television, refrigerator or coffee maker!

We are first going to use nmap to see if we can identify any such devices on the network, and perhaps detect one or two that we did not think or know were connected to it. We'll then configure Wireshark and run a packet captures to get a sense for the normal traffic on the network, and then run another capture to analyze just how an nmap network scan works.

Determining Your IP Address
Before we can scan the network with nmap, we need to identify the ip address range we would like to examine. There are a number of different ways to determine your ip address on a Linux distribution such as Kali. You could use, for example, the ip or ifconfig commands in a terminal: ip addr, or sudo ifconfig.

(Note that if you are using an administrator account inside Kali, which is considered a best practice, when a non-root user enters a command such as ifconfig into a terminal, the shell will likely respond by complaining "command not found". In Kali, sensitive system commands like ifconfig have to be run as root. To access it from your administrator account, all you need to do is add "sudo" to the front of the command: sudo ifconfig.)

These commands will provide you will a wealth of information about your network interfaces. Identify the interface that is connected to the LAN (likely eth0), and make a note of the ip address indicated after "inet" for the ip addr command, or after "int addr:" for the ifconfig command. That is your ip address on your local area network. Here are a couple ifconfig and ip addr outputs posted by the Ubuntu Journeyman:

As you can see here, the ip address for this machine is 192.168.1.4.5. Yours is likely something similar to this: for example, 192.168.1.123 or 10.0.0.56 etc. Notice in the ip addr output above, the ip address is: 192.168.4.5/24.  That means 192.168.4.5 is the ip address of that specific machine, while the /24 at the end indicates the address space for the LAN's subnet, which in this case are all the addresses from 192.168.4.1 to 192.168.4.255.

If we were to scan this local area network with nmap, we would want to scope out all the addresses in the network's range, which means 192.168.4.1, 192.168.4.2, 192.168.4.3, 192.168.4.4, and so on, all the way to 192.168.4.255. One shorthand way of notating this is: 192.168.4.1-255. Another common shorthand is 192.168.4.0/24.  Of course, if your address were 10.0.0.121, then the shorthand would be: 10.0.0.1-255 or 10.0.0.0/24. 


Host Discovery
Let's assume your Kali VM has the ip address 192.168.1.5 on a subnet with possible host addresses from 192.168.1.1 to 192.168.1.255. Now that we know Kali's ip address and the address range we want to take a look at, open up a terminal and type: nmap. This will provide you with a long list of all the options available within the nmap program. Nmap is a powerful program and there are a lot of options! Perhaps the simplest possible network scan that can be conducted with nmap is a ping scan, for which we use the -sn option.

Now type nmap -sn 192.168.1.1-255 into your terminal and hit enter. (Don't forget to substitute the address range for your network if it is different from this!) This scan will tell you how many hosts nmap discovered by sending a ping echo request to each of the addresses in the range x.x.x.1-255, and provide you with a list of the ip addresses of the hosts that returned a ping reply. This is host discovery 101. Here is the ping scan output from nmap on a simple local area network I set up for the purpose:

The ping scan found 5 hosts up with the addresses: 192.168.1.1, .2, .3, .5 and .6.  Note that in the wild, this method of discovery may not work, as it is becoming increasingly common for administrators to configure their systems so that they do not reply to simple ping echo requests, leaving a would-be ping scanner none-the-wiser about their existence.

Did your scan find the same number of hosts that you had presumed were on your network? Were there more or less?

We can use the default nmap scan to further investigate known hosts and any potential ghost hosts the ping scan may or may not have uncovered. For this, simply remove the -sn option from the command above: nmap 192.168.1-255. Here's the output of the default nmap scan on the same network as above:

Nmap has returned much more information. It found three open ports on the router at 192.168.1.1, as well as an open web server port on host 192.168.1.2.  All scanned ports on the remaining hosts were closed.

You can also use nmap to further investigate known hosts. The -A option in nmap enables operating system detection and version detection. Pick out a couple of the hosts discovered by your nmap scans, for which you already know the operating system type and version. Now scan these hosts with nmap for OS and verstion detection by adding them to your host address target list, separated by commas.  For example, if I would scan the router and web server discovered above for OS and version detection with the command: nmap -A 192.168.1.1,2. This will return more information, if any is determined, on those hosts.

You can obviously also run an OS and version detection scan over the whole network with the command: nmap -A 192.168.1.1-255. Depending on the number of hosts on your network, this scan could take a couple minutes to complete. If you press <Enter> while the scan is running, it will give you an update on its progress.

If there are more and a handful of hosts on your network, the output can be hard to parse in the terminal. You could send the output to a file with:  nmap -A 192.168.1.1-255 > fileName.txt. Or you could use one of nmap's own built-in file output options.

But this is also where Zenmap comes in quite handy. Open up Zenmap from Applications->Kali Linux->Information Gathering->Network Scanners. If you are running as an administrator and not root, as you should be, you will get a message stating that not all of nmap's functionality can be accessed without root privileges. Root is not necessary for basic scans. However, you can run Zenmap as root by opening a terminal and typing: sudo zenmap. The Zenmap interface:

The Zenmap interface is pretty straightforward. Enter the target ip address or address range into the target field. Changing the scan profile from the drop down menu changes the scan command. You can also manually enter or edit commands in the command field. After you run a scan, Zenmap also helpfully breaks down the results for you, providing host details, port lists, network topology graphics and more.

Play around with the various built-in scan types. Can you identify all the hosts on your home network with a ping scan? a regular scan? an intense scan? Can you identify all the open ports on those hosts? If you have a laptop or another device that you frequently use to connect to the internet over public wi-fi hotspots, you can also do intensive scans of those devices to determine if there are any open ports that would represent a potential security vulnerability. Identifying open ports is important for vulnerability assessment, because these represent potential reconnaissance or attack vectors.


Network Traffic Capture and Analysis with Wireshark
Nmap scans a network and probes hosts by sending out ip packets to, and inspecting the replies from, its target at a given address. With 255 addresses to scan along with 1000 ports on all discovered hosts in the default scan of the subnet above, that's a lot of network traffic! What does the packet traffic generated by a scan look like on the network?

To answer this question, we can use Wireshark and dumpcap. Dumpcap, as its name implies, is a command line tool that dumps captured network traffic. Wireshark provides a graphical user interface to analyze these sorts of dump files, which are collections of all the network traffic to which the given network interface was privy.

If run with the proper privileges, Wireshark can capture live network traffic as well. In Kali, you can find Wireshark under: Applications->Kali Linux->Top 10 Security Tools. Unless you have already configured Wireshark with the appropriate settings, when you open it for the first time you will be informed by the "Capture" panel that "No interface can be used for capturing in this system with the current configuration."

In its documentation, Wireshark recommends appropriate settings to enable capture privileges. This also suggests confirming that Wireshark can also be run as root. To run Wireshark as root, you can log in as root, or run sudo wireshark in a terminal. When you run Wireshark as root, you will first be given a usage warning and provided with sources for how to set up proper privileges. This forum post on AskUbuntu boils the process down to three simple steps.

Now that you've enabled live captures in Wireshark, let's run one! Click "Interface List" in the Capture panel of the default view. Choose the interface that is connected to the network (it will indicate your ip address on that network), and click Start.

This will immediately begin a live capture of all the packets on the network to which the interface has access. At the very least, it will detect: 1) packets it sends out, 2) packets it receives directly, 3) packets it receives indirectly if they are broadcast to all the hosts on the network.

If you have never viewed a network packet capture before, you may be surprised what you can see, and what information is simply being broadcast over the network. You'll probably find messages from your router, you'll see internet traffic packets if you are viewing a webpage in a Kali browser, or on Kali's host computer (depending on whether or not Promiscuous Mode is enabled in the VirtualBox advanced network settings for your Kali machine). You might find that one device is especially chatty for no good reason. There might be devices pathetically sending out calls to other devices that have been removed from the network, such as a laptop searching for a printer that has been turned off, and so on.

The default Wireshark packet capture interface numbers each packet it captures, and then notes the time after the capture began that it received the packet, the ip address of the source of the packet, the ip address of the destination of the packet, the protocol, the packet's length and some info. You can double click an individual packet to inspect it more closely.

If you ping your router (which you should have been able to identify via nmap analysis) from Kali, you'll see all the requests and replies, obviously, since the Wireshark capture and the ping are running on the same machine. But the Kali guest shares its interface with the host machine. If you enable promiscuous mode in the advanced network settings inside VirtualBox for your Kali instance, when you ping your router from the host machine itself, the Wireshark capture will similarly allow you to see all requests and replies, they're going over the same interface! If you disable Promiscuous Mode, on this other hand, this will not be the case. In this case, packets to and from the host computer will not be picked up, as if it were a completely separate physical machine. Similarly, if you ping your router from a different computer, you will not see the request/reply traffic at all, though perhaps you might pick up an ARP if the requester does not already know the (hardware) address of the request's intended recipient.

After getting a feel for what the base level network traffic looks like on your network, start a new capture, and then run a simple scan from nmap or Zenmap, and watch the result in Wireshark. When the scan is finished, stop the capture and save the file. Capturing the simple nmap ping scan from above on my network resulted in a file with over 800 packets! Now you can analyze the network traffic generated by the scan itself. You'll probably want to play around with Wireshark for a bit to get a sense of what it offers. There are tons of menus and options in Wireshark that can be tweaked and optimized for your own ends.

Well, that's it for this article. In part three of our hack lab tutorial series, we'll install our victim machine, an instance of Metasploitable2, in VirtualBox and set up a completely virtual lab network to explore some more tools that are bundled in Kali. As always, comments, questions, corrections and the like are welcome below.

Hack Lab Part 1: Installing a Kali Linux Virtual Machine in Virtualbox

In this article, which is the first part in our tutorial series on how to set up a home hacking and security testing lab, we will walk through the creation and installation of a Kali Linux virtual machine inside VirtualBox. This system will then function as our main monitor and attack machine in subsequent tutorials. After setting up the virtual system, we will:

1. run a live Kali session
2. do a full install
3. update the system
4. install the VirtualBox Guest Additions
5. configure appropriate user accounts
6. and finally switch over to a bridged network adapter in preparation for the next tutorial in the series

The whole process may take a few hours to complete, more or less, depending on the specifics of your own situation, ex. computer, internet connection speed, and so on. This session took me about three hours from beginning to end.


Virtualization
There are a number of different free virtualization packages available online. For this tutorial series, we've chosen to go with VirtualBox because it's open source, beginner friendly, and there is a lot of documentation and support information that can be found for it online, especially regarding the systems that we will be installing. For example, since Kali and Metasploitable are derived from the Debian Linux distribution, support information on other Debian-based operating systems such as Ubuntu or Crunchbang is often also applicable to Kali and Metasploitable, as we shall see in this and subsequent articles.

The first step is to download and install the VirtualBox software package onto the primary computer chosen for your lab setup. Make sure you download the right version for your operating system and hardware architecture (32 bit vs. 64 bit). Instructions for installation on various operating systems are readily available if you run into any snags. Also make sure to keep a handy copy of the VirtualBox user manual, which comes packaged with the software and can also be found online.

Once you install VirtualBox and run it for the first time, you'll be presented with the application's welcome prompt, which provides an orientation for the interface. Poke around in the menus to get a feel for the software.

Next, download a copy of the Kali Linux operating system .iso disc image. Again, make sure you download the proper ISO file for your computer's architecture. Depending on the speed of your internet connection, this may take some time, as both the 32 bit and 64 bit files are 3GB in size. Kali's documentation can be found here.

As Kali is a security sensitive system, once you have downloaded the file, it is recommended to check its SHA1SUM hash value against the one supplied on the download page to make sure the file had not been corrupted in transit. For more on how to check a file's hash value, follow the link to our previous article providing an overview of the process.

If you plan on playing around with a number of different virtual guests on your computer, it is probably a good idea to create a permanent folder somewhere on your system where you will keep all the necessary operating system .iso files.

Creating a Virtual Machine
Now let's return to VirtualBox and set up the virtual machine on which we will install the Kali operating system. Open VirtualBox and click "New". Provide a name for your Kali virtual guest system. Choose Linux as the type and Debian as the version, since Kali is derived from Debian Wheezy. As you can see below, I'm using the 32 bit version. Click Next.

Choose the amount of memory you want to allocate to the virtual instance once it is up and running. In my experience, Kali can use a lot of RAM, and the computer I'm running it on has a fair amount to spare, but for now I'm going to leave it at the default of 512MB.  You can also adjust these settings later to optimize them for your own setup. In my experience, Kali runs pretty well in VirtualBox even on a laptop with only 4GB of RAM, though you may have to conserve by shutting down memory intensive applications running on the host computer. After you've set your memory size, click Next.

Choose whether you want to create a virtual hard drive for the virtual machine. We're going to need one for our home lab, so check "Create a virtual hard drive now", then click Create.

For the "Hard drive file type", check "VDI (VirtualBox Disk Image)", then click Next.

In the "Storage on physical hard drive" window, you'll probably want to choose "Dynamically allocated." This means that space will not be taken up on your physical hard drive until it is actually written to the virtual disk. If you choose "Fixed size" then the virtual disk drive will take up a set amount of space on your physical hard drive even if that space has not been written to by the virtual machine. Click Next.

In "File Location and Size," choose where you want the hard drive files for the virtual system to be stored by clicking on the folder icon. I just use the default folder. This is where VirtualBox will store all files related to your virtual machine. Also, on this screen you may increase or decrease the amount of hard drive space you want to be allocated for the virtual instance. 8 GB is the default. I'm going to push mine up to 10 GB. Click Create.

The new virtual system should now appear in your Virtualbox interface. As you can see I have three folders in my left sidebar, and have placed the kali1 instance I just created into a new "lab" group. In the main interface we can see the settings for the new systems, which are a mixture of defaults and configuration settings we determined ourselves in the creation phase. Before starting up the instance for the first time, I usually adjust a few settings first.

Click "Settings" for your new virtual machine. I'm going to add a description under the General menu, because I have other Kali instances on my computer.

In the System menu, under Motherboard, I uncheck "Floppy" in the boot order.

Also in the System menu, under the Processor sub-menu, we have to check "Enable PAE/NX" for Kali to operate properly.

Finally, under the Display menu, I add more Video Memory to the default 12MB, bumping it up here to 36 MB to start. Again, this can be adjusted later to optimize your particular setup.

That's it for now. Browse through the other menus. Notice in the Network setting we can add up to 4 different network adapters for our virtual machine. Later we will play around with the network setting, after we've fully installed the Kali operating system. For now, a single network adapter running on NAT (i.e. Natural Address Translation) will suffice for our purposes.

Click "OK" to save your changes.

Fire up your new machine by double clicking it, or single clicking it and then clicking Start. You will be prompted to "Select start-up disk". We now have to choose the startup disk for our new virtual machine. This is the Kali .iso file we downloaded earlier. Click the folder icon and navigate to the folder where you've stored the Kali .iso file on your host computer. Select it, then click start.

Booting into a Kali Live Session
Kali should boot as if you were booting a real physical machine from a cd with the Kali operating system file on it. Notice that if you click inside the guest window, your mouse pointer will be "captured" by the guest. From then on, your keyboard and mouse activity will control the virtual machine. To switch back to using your host machine, you have to hit the host key, which by default is Right-Control on my computer. It may be different depending on your operating system. The Virtualbox interface will tell you what the "Host Key" is in the bottom right of the window.

From this menu, you can boot into a number of different types of live session, or you can do a full install of Kali on the virtual hard drive we previously created inside Virtualbox. As we shall see, there are numerous advantages to doing a full install of Kali for the purposes of our home hacking lab, but one of the advantages of a live session is that we can jump right in without any further configuration. Let's select the default Live session. Here is the Kali Desktop after booting into live session (note the time and day, yes, this is how I prefer to spend Saturday evening):

You will soon notice that there are certain limitations to the virtual machine's interface. For example, your mouse wheel will not work, you cannot enlarge the size of the screen, or go full screen, there is no tab completion in the terminal, and there are other interace issues as well. This is not a limitation of the live session, or Kali itself, but rather of the virtual machine we've created. However, all these issues can be addressed by installing the Virtualbox Guest Additions, but we'll save that for our future full install of the system.

Notice also that there are limitations to the default NAT networking interface. Under NAT (natural address translation) the Kali guest is not treated as its own independent node on the wider local area network. It does not have an independent ip address on the local area network. Its virtual ip address is translated by the ip address of the host machine. This can be addressed by adding a second network adapter to the virtual system or changing the present one, as we shall see later on.

However, despite these limitations, you can already begin exploring the ridiculous number of tools that come bundled with Kali. Here are Kali's Top Ten Tools:

Since all appears to be working well, let's take a snapshot of the virtual machine. VirtualBox snapshots are a way to keep a log of your virtual machines in a given state. If you are experimenting with a new configuration, and everything suddenly goes to hell, you can always revert back to your previous snapshot like nothing happened. Go to the VirtualBox interface window, select your Kali guest, click "Snapshots" in the upper right. Take a snapshot by clicking on the camera icon. Name the snapshot, and give it a description. Now, if we seriously screw up something on the machine, we can always just revert to this prior state of the system.

Now let's reboot to do a full install. Click the root menu item in the top right of the Kali Desktop window. Then choose reboot or do a full shut down and boot from the VirtualBox interface. In the process, you will be prompted to remove the disk from the system. Of course, we are using a virtual disk image, so there is no physical disk that needs to be removed. Just click enter to continue. Now reboot . . .  OH NO!!!!! "FATAL ERROR: No bootable medium found! System failed."

If you've been following along thus far, you've likely just been delivered this disturbing warning by your virtual machine upon reboot. It's a good thing we took that snapshot! Actually, this was only to be expected. Remember when you had to remove the virtual disk from the machine upon shutdown or reboot? Well, we now have to re-insert the virtual disk, that way we can reboot into Kali and move on to a full install of the operating system. So solve this "Fatal Error," with your virtual machine still running:

1. Point your mouse toward the Oracle VM VirtualBox application menu on your host machine and find the Devices dropdown menu
2. Select "CD/DVD devices"
3. Select "Choose a Virtual CD/DVD disk file..."
4. Select or navigate to your Kali .iso operating system file
5. Close the virtual guest by exiting the window and powering off the machine 

After the machine closes down, restart it from inside VirtualBox, it should boot into Kali from the newly inserted virtual disk.

Full Installation of Kali in VirtualBox 

Now let's move on to our full installation of the Kali virtual instance. Once your system reboots into the main menu, choose the Install option and hit enter.

The installation process will begin straight away. Note that over the course of the installation, the various menus are not graphical interfaces. You cannot point and click, you have to enter info via the keyboard, and use the arrow keys to navigate. We're not going to do anything fancy here for the purposes of this simple home lab setup. In most cases the defaults will suffice. Simply follow the directions on each page. This process took about an hour on my computer. Here's the first screen:

1. Choose your language.
2. Select your location.
3. Select your keymap.
4. Enter the new host's name. It simplifies things to choose the same name you chose for your VM inside VirtualBox, but these need not be the same name. You can also always change both names later if you so wish.
5. Enter a domain name. I'm going to leave it blank and hit enter.
6. Enter a root password, then re-enter to confirm. These will be the credentials for the root super-user on the system. Be sure to make a note of the password you've chosen.
7. Select your time zone.
8. Partition Disks, select 'Guided - Use Entire Disk'. Not to worry, here 'Entire Disk' means the virtual hard drive we created upon initial setup of the VirtualBox machine. In my case, this will eventually claim up to 10GB on my harddrive, as this was the size I specified when I created the VM.
9. Select disk. This is the virtual hard drive we configured earlier.
10. Select partition scheme. Let's choose default, all files in one partition.
11. Confirm selections, or go back if necessary.
12. Select yes, to commit the changes by writing them to disk.
13. Select network mirror if any. None is needed for this home lab setup.
14. Select proxy if any. None is needed for this home lab setup.
15. Install grub boot loader (default).
16. Installation complete! Select continue.

Let the machine do its thing, and then reboot the system. Upon reboot, log into kali using 'root' as your username along with the password you chose for root during installation.

Congratulations, you now have a virtual instance of Kali Linux installed on your computer! But we're not done with our configuration of the new virtual machine just yet. We still have to update the software on the system, and then we're going to install the VirtualBox Guest Additions in order to enable full screen mode, tab completion in the terminal and so on. This process might take you another hour or so, depending on your internet connection.

Updating Kali and Prepping for Guest Additions
If your host computer is connected to the internet, you should have internet connectivity from inside your Kali VM over your NAT adapter. You can check this by opening up the bundled Ice Weasel browser and making sure you can get online. Ice Weasel can be opened by clicking the icon next to the Places drop down menu in Kali. You can also try pinging google.com or some other website from inside a terminal. You can open a terminal by clicking the terminal icon next to the Ice Weasel icon. We are going to need a working internet connection to update the system.

Let's update the system. Open a terminal in Kali and enter the following command:

apt-get update

This will make sure Kali checks the most recent repository for any software updates. Once this process completes, enter:

apt-get dist-upgrade

This will update all software on the Kali system. Depending on your internet connection, this may take some time. The process lasted around 15 minutes for me this time around. Once that is complete, you now have a fully updated Kali virtual machine. But we are still lacking some basic functionality, so now we're going to install the VirtualBox Guest Additions.

Installing Guest Additions in VirtualBox can be tricky. To prepare the system to handle the Guest Additions, we have to run a couple more commands inside the terminal, so open up a new terminal shell and run the following series of commands, one after the other, after each completes:

apt-get clean
apt-get autoclean
apt-get update
apt-get install build-essential linux-headers-`uname -r` dkms

Notice that `uname -r` is inside backticks, not single quotes in the final command here. Yes, this matters. The backtick key should be located just above the tab key on your keyboard. This series of commands was suggested on this CrunchBang forum post, and it has yet to fail me in setting up Guest Additions for a Debian-based machine inside VirtualBox. Once this process has completed, we can now install the Guest Additions themselves.

Installing VirtualBox Guest Additions in Kali
While engaged in the Virtual system, in the Oracle VM application menu, go to the Devices dropdown menu again. Notice the "Insert Guest Additions CD" option. Select it. You will get a pop-up inside Kali asking you if you want to run the file. If it succeeds, great! If not, that's not a problem. In my experience, it has never worked off the bat, so I click cancel.

Selecting the "Insert Guest Additions CD" menu option has inserted a virtual disk into your virtual machine. The files on this disk can be found in the folder: /media/cdrom/. Confirm that they are there by navigating to this folder in the graphical file system manager or in a terminal.

To install the Guest Additions for Kali, we need to run the VBoxLinuxAdditions.run file on the Guest Additions cd. However, you cannot simply run the file from the /media/cdrom/ directory. First we need to copy it and change its permissions.

Copy the file to your Desktop from inside a terminal with the following command:

cp /media/cdrom/VBoxLinuxAdditions.run /root/Desktop

You should see a copy of the file appear on the Desktop.  Change to the Desktop directory inside the terminal:

cd /root/Desktop

Change the permissions on the file with the following command:

chmod 755 VBoxLinuxAdditions.run

Run the additions file:

./VBoxLinuxAdditions.run

Success? Success!

If you experience any snags along the way here, you'll have to do some trouble shooting. There is a ton of info online regarding installation of Guest Additions in VirtualBox VMs, likely in large part because the process can be tricky. Remember also, that support info for other Debian-based systems such as Ubuntu and CrunchBang will also apply to Kali in many cases. But the series of commands above has yet to fail me.

Upon successful installation of the Guest Additions, we have to shut down the machine for the updates to take effect. Reboot and log in as root again. Once the system reboots, the simplest way to confirm that the Guest Additions have been successfully installed is to see if you can maximize the window for the guest system. You should now also have code completion in the terminal, among other things. You can now eject the Guest Additions virtual CD from the Virtual cd drive. Click the Computer icon on the Desktop, then click eject under the devices menu.

We now have a fully updated fresh install of a Kali virtual machine with the VirtualBox Guest Additions installed. Let's shut down the machine, take a snapshot and switch the network adapter into bridged mode in preparation for the next tutorial.

Switching to Bridged Networking
After the VM has shut down and you've taken your snapshot, open up the settings of your new virtual system and go to the Network menu. Unless you've already chaned these settings, you should have network Adapter 1 enabled, and attached to NAT. Change the attachment to a bridged adapter. This will allow our guest to act as an independent host on our local network, rather than have its address translated by the host computer the virtualization software is running on.

Finally, the adapter Name has to connect up to the appropriate network adapter of the host machine, i.e. the one that is actually connected up to your local network, whether it is a wireless connection, an Ethernet connection, or whatever. The appropriate one should be selected by default. Click Okay.

Start up the guest. Open a terminal and ping a known website or host, or use a browser to visit a web page. If it works, CONGRATS! You're in bridged mode.

If you have no networking capability, and can't even ping other computers on your home network, let along a website. You have to do some trouble shooting. Here are some troubleshooting questions:

• Are your networking settings correct in VirtualBox?
• Is the adapter for the guest machine connected to the right interface on the host computer?
• Is Kali's /etc/network/interfaces file structured properly?
• Is the appropriate interface up as indicated by ifconfig?
• Have you tried restarting Kali's networking service?
• Is Kali's /etc/NetworkManager/NetworkManager.conf file structured properly?
• Have you tried restarting the network-manager service?  

As the old saying goes, when all else fails, read the manuals!  

Setting up an Administrator Account
If you've followed along this far, you are now logged into your Kali VM as root, have a fully updated system, and the VirtualBox Guest Additions installed. It is not good to get into the habit of running everything in Kali as root. Best practices dictate setting up an administrator account and using sudo to run security-sensitive commands.

Create an administrator account by going to the root dropdown menu in the top right of the Kali Desktop. Then select: root => system settings -> user accounts -> create an administrator account. Create an administrator account with a separate password.  Then log out, and log back in with your new admin account.  Using an administrator account such as this creates a bit of extra work (ex. having to use sudo for otherwise everyday commands such as ifconfig, having do to a bit of extra configuration for applications such as Wireshark and Zenmap), but it is a good habit to get into so as to avoid becoming careless with the root account. After setting up an administrator account, shut down the machine and take another snapshot.

In part two, we will use two tools bundled in Kali to explore your home local area network. Thanks for following along. As always, leave any questions or comments below. 

Hack Lab Intro: How to Set up a Home Hacking and Security Testing Lab

Introduction

This series of articles comprises an introductory tutorial on how to set up a home lab to experiment with common hacking and information security testing tools. Our setup will  allow us to explore the sorts of computer and network vulnerabilities that can be encountered on the internet, and to test the security of our own home computer network and networked devices, all from within an isolated and secure working environment. The series is geared toward individuals who have little or no prior experience with virtualization software or common hacking and security testing tools, but are interested in exploring network and computer security.

Over the course of the tutorial series, we will create two separate network configurations. The first will be a completely virtual environment populated by two virtual guest systems running inside a single host computer. This requires nothing more than an internet connection for the necessary downloads, and a computer with relatively modest RAM and disk resources.

The second configuration will be an everyday local area network of the sort that can be found in many homes, but which is isolated from the internet and where we can strictly control and monitor all network traffic. This setup is slightly more involved in terms of hardware than the first, requiring also a spare router.

Our monitoring and attack system in both configurations will be an instance of a Kali Linux virtual machine running inside an installation of the VirtualBox software package on our primary computer. Kali is a Linux operating system distribution intended for security testing and digital forensics.

In the first completely virtual network environment, our victim will be an instance of  Metasploitable2, a virtual machine that exhibits vulnerabilities that can be found on  everyday computer systems and software configurations. As noted at Offensive Security, "Metasploitable is an intentionally vulnerable Linux virtual machine. This VM can be used to conduct security training, test security tools, and practice common penetration testing techniques."

In the second network configuration, we will use the Kali Linux virtual machine to compromise an everyday local area network router of the sort that can be found on many home networks, in order to demonstrate just how easy it can be to steal login credentials  passed from another computer on the network.

The tutorial is broken down into four parts:

• Part 1 covers the installation of VirtualBox and provides a walk through of a full installation of a Kali virtual machine on your primary lab computer. Along the way, we'll take a short detour on how to quickly run live Kali sessions without a full installation of the machine.

• Part 2 demonstrates one way to begin exploring your existing home network with Kali Linux, and test whether you can successfully identify all the devices that are connected to it.

• Part 3 covers the installation of the Metasploitable virtual machine and the configuration of a completely virtual internal network environment inside VirtualBox. We'll then place the Kali VM on this network and offer tips and resources on how to probe the victim machine for vulnerabilities by exploiting the tools that are provided by Kali.

• Part 4 provides details on setting up our second network configuration, which models an everyday home local area network. With the attack machine, we'll conduct a simple man-in-the-middle attack against the network's router, and demonstrate a serious security vulnerability by stealing login credentials sent to it from the victim machine, in this case, the host computer. 

Ashes To Ashes, Sludge To Sludge: Once You've Died, Get Liquefied?

Here's some news that's sure to brighten/frighten you for Halloween season:  now, instead of traditional burial or cremation, after death you have the option to be liquified.

It might make your skin crawl, but that's just because you still have skin to worry about.  For those who are planning what they want done with their body when their spirit has hit the road, the new "alkaline hydrolysis" may be the best final answer.  This way, you won't take up too much space or badly impact the environment after you've crossed the finish line in the human race.

According to the mirror.co.uk, the process is simple:  a body is put into a stainless-steel container with water and potassium hydroxide, then pressurized and heated for about three hours, like a creepy crock pot.  A green and brown syrup with an odor like...well, like a dissolved corpse...will be what remains of your remains, as well as a fine white ash.

Yay, my sweet embrace of death will be ecologically friendly!  This totally makes up for all the littering I did in the '50s.  (Image courtesy bioresponsefuneral.com.)

It won't take up the space a conventional burial would, it won't emit various effluvia into the atmosphere like a cremation, and the cask-distilled small-batch human juice won't be accidentally mistaken for shots if you have an Irish funeral.  The you-goo is disposed of by your mortician, but the ash is returned to to whom you bequeathed it, and it can still be kept in a vessel or distributed back to the earth if desired.

So if you haven't got the budget or archers sufficiently skilled in firing flaming arrows for your postmortem party, here is an option for a clean and earth-friendly exit.  Good going!

If there's a way death can be "healthy", this is it.  (Image courtesy snlabetterway.com.) 

Feats From Feet: New Panels Allow Athletes' Footsteps To Power Soccer Stadium

It may seem like just a small step for technology when kinetic foot-pressure-powered tiles can charge some cellphones.  But what about lighting an entire soccer stadium by players' pressing power?  Now, thanks to one company, such a breakthrough is making life better in Brazil.

The Pavegen company manufactures tiles that are pressure-powered to generate electricity.  Already a feature in some European schools as well as at the Paris marathon, the company recently partnered with Shell to create its biggest project yet:  powering a soccer stadium in an impoverished Brazilian favela.

According to gizmag.com, some 200 Pavegen tiles were placed beneath fresh Astroturf, with other tiles along the sidelines. Use of local labor made the project personal to the community. Pavegen's 28 year-old founder/CEO Laurence Kemball-Cook said, "In the two weeks on site in the community, children helped complete the installation. It was a real life science experiment that didn’t stop when school ended for the day."

The tiles will provide up to 10 hours of illumination on a full battery charge, with nearby solar panels aiding the power. The push-powered pitch has been in use for about a month now and has already caused the community to rally for renovations and improvements in the area, showing this has been a great idea from soles to goals.

A pitch that's not pitch black:  Pavegen's tiles prove effective for large-scale illumination.  (Image courtesy goodnewsnetwork.org.)

Space Station Sunday: Extravehicular Excellence

Good morning space fans!  It's shaping up to be an exciting week on the ISS, with astronauts Reid Wiseman and Alexander Gerst preparing to conduct an EVA (Extravehicular Activity, a.k.a. spacewalk) on Tuesday.  They have already donned and inspected their spacesuits in a pre-excursion examination, which is important due to the fact that micro-gravity can increase astronauts' height by up to 3 inches (so it's necessary to check that no one got too big for their space britches.)

According to nasa.gov, the purpose of the spacewalk will be to move a pump unit out to external stowage, and to install the Mobile Transporter Relay Assembly, a backup power source for the ISS's Mobile Transporter (which moves the exterior machinery of the Mobile Servicing System - including the Canadarm 2 - into proper worksite locations.)  NASA has released a wonderfully-detailed, point-by-point video simulation of what exactly will transpire on the spacewalk.

On this EVA, Astronaut Gerst will become the third German ever to spacewalk.

Astronaut Wiseman was recently featured on NBC's Nightly News with Brian Williams, elucidating his thoughts on why his job is the best in (and over) the world.  An enthusiastic former Naval pilot, he and new ISS crewmate Barry "Butch" Wilson showed their support for their fellow sailors during a Navy/Air Force football game.

Ships, starships, whatever.

In other news, this week the ISS confirmed the name change on their official Twitter handle to @Space_Station.  Check it out for videos, images, and commentary to keep you updated on everything orbital and awesome.  Short astronaut-shot space and ISS experiment videos can also be accessed on Vine via #SpaceVine.

We wish Astronauts Reid and Gerst the best of luck on their upcoming EVA.  See you next Sunday...watch this space!

Alexander Gerst enjoys Casual Friday last week on the ISS, as this week his spacewalking outfit will be much more cumbersome.