ghosts in the wire (or rock out with your hack out)

setting up and running metasploitable3

Metasploitable 3 is out, and there are some differences from the previous version. The vulnerable system is a Windows box this time, and instead of just downloading a VM image and firing it up, the author(s) have decided to leave it up to the end user to package the VM. This adds a little complexity for us, so I thought I would walk through the steps it took to get me up and running. This really wasn’t terribly difficult, but this is my first time using vagrant/packer and it’s been a long time since I used VirtualBox. Hopefully I remember this all correctly! I did this install on a relatively clean, patched Windows 7 64-bit laptop. I did not track when I had to run installers or cmd windows as Administrator.

Make sure the system you’re installing this to has Internet access, and it’s not just to download the installers. There are various downloads that happen during much of the execution of vagrant. I know. That’s strange to ask security geeks to just trust, but that’s the reality of this method of deployment. If you want to watch it and authorize each access attempt, make sure you have some tea/coffee nearby and a book as my install took about 20 minutes or so.

Download Packer by following its install instructions. Don’t forget to set the PATH variable. I just put Packer inside Program Files.

Install Vagrant 1.8.1. The Metasploitable3 instructions discuss a problem with 1.8.5, so I didn’t even try it. This installed into C:\HashiCorp\Vagrant.

Install VirtualBox 5.0.10.3. The latest version is 5.1.6, but vagrant 1.8.1 during execution will want 5.0.10 and attempt to download/install it. That process never succeeded for me, so I installed this manually.

Install Microsoft Visual C++ 2010 Redistributable. During vagrant’s execution, there was a point where I was stopped and waiting for an SSH connection that never happened (I believe that’s where I needed this). Installing this got me past that hurdle. Note that I’m linking to the 64-bit version.

“Clone this repo and navigate to the main directory.” We get choices here now. You can just download (“clone”) the zip from the GitHub website and call it good. Or you can download and install Git or Github Desktop and make an account. I chose that latter. After I installed GitHub Desktop and created an account, I opened a Git shell from the Start Menu, navigated to where I want to stage my pre-packed VM files, and issued, git clone https://github.com/rapid7/metasploitable3.git This created the “metasploitable3″ folder for me, so I didn’t need to manually create it. For me, this was c:\users\michael\documents\github\metasploitable3\”. The Git shell, incidentally, will open by default in your user documents folder.

Next, run packer build windows_2008_r2.json while in a cmd window inside the folder you cloned metasploitable3 into. This will take a while. I don’t recall having any issues at all with this step.

Now, run vagrant box add windows_2008_r2_virtualbox.box --name=metasploitable3 to add the box to vagrant.

Run vagrant up to start the new VM. This will run a bunch of scripts and you’ll see the box appear and reboot several times if you happen to have VirtualBox running at this point.

About 10 minutes into this process, my box disappeared from VirtualBox and the vagrant window showed a bunch of “from” lines. At this point, vagrant has hit an error and walked a bunch of stuff back. Scrolling up, I found an error from winrm about having more then 50 concurrent operations. (“The WS-Management service cannot process the request. This user is allowed a maximum number of 50 concurrent operations, which has been exceeded…WinRM::WinRMWSManFault“) That sucks. Being new to vagrant, I didn’t really know how to fix the scripts for this error, but I did know how to fix this if I could get into the VM while the scripts were running. I ran vagrant up again and watched the VM console in VirtualBox. After the first reboot, I was able to quickly log into the box (vagrant/vagrant) and run this command: winrm set winrm/config/service @{MaxConcurrentOperationsPerUser="500"} to set concurrent operations to 500. Success!

Save the VM state. I don’t want to do all of this again any time soon, so I saved the VM state so I can keep it in VirtualBox and restore state as needed. Now, I can just right-click my new VM and choose Start whenever I want this system up.

From here, I believe the default settings for VirtualBox allow for NAT connections, so that my Metasploitable3 box has access to the Internet and my own network, plus my network systems can talk to this box. I may have just set this without thinking, and it’s not default. If you’re not on a private network, I suggest keeping this networking to host-only, and instead just install a kali linux or other pen testing VM into VirtualBox.

If you want to use this box inside VMWare or another hypervisor, export the Virtualbox VM as an Open Virtualization Format (OVF or OVA), which VMWare will recognize.

Is this a cool way to distribute a VM? It is if you’re familiar or comfortable with all these steps, probably more so if you go all devops and deploy systems using any sort of container/packer process or you’re a developer that shares VMs a lot. But I’m glad I don’t have to do all these steps for most VMs that I download. For instance, standing up Metasploitable2 doesn’t even require a post since it’s just a download-open-start process. Also, this is sort of what you need to do for a Windows VM these days, unless you want to license them on your own.

Aside: I have no idea how WordPress automatically chose to make the code lines special boxes. Neat, I guess. And I don’t like having to put a check mark into each link to open in a new tab. I do this stuff faster manually typing the dang tags…

Post navigation

2 thoughts on “setting up and running metasploitable3”

Thank you so much for the guide and for the feedback! I actually didn’t realize some of those requirements were necessary for building on Windows. We mostly build on OSX and have just done some minor testing with building on Windows just to make sure it works. I’ll update the docs and the build script with the Visual C++ Redistributable requirement to make that more clear.

Also, I put a PR up to increase the base WinRM connection limits. It should get landed soon so that will no longer be a problem. It does set those values in the Packer build process, though, so it will be necessary to re-build that to get it by default. I’m doing it during the Packer process because that isn’t affected by the issue like Vagrant is. I was attempting to do it through Vagrant at one point but it would run out of connections while trying to set the config value; a chicken/egg problem.

Thanks again for posting this up! If you have any other suggestions or tips please don’t hesitate to let us know.