Setting Up Your Own Virtual Pentest Lab – Part 2

posted in: pentesting basics | 0

Part 2 – Loading and Installing Vulnerable VMs to ESXi

Okay, so now we have this nice ESXi server sitting there like a “blank canvas” so to speak.  Well the next step in setting up our own pentest lab is to start loading and installing virtual machines (VMs) onto the server and letting them run.  There are obviously a myriad of options you have at this point in how you want to set up your lab, but let’s simply start with the steps to gather some vulnerable-by-design VMs and getting them up and running in our lab.  Fortunately for us, there are a lot of resources on the web these days where we can download vulnerable distributions.  I will try to share with you a list of  some of my sources, but Google will also be your friend here as well.

 

Step 1)  Collect your vulnerable VMs

In order to begin hacking away, we need some VMs to actually hack.  While we could build some ourselves, that doesn’t supply us with the same effect as attacking something completely blind.  So let’s find some VMs that are built for us with known vulnerabilities.  A quick Google search for “vulnerable by design” will lead you directly to an excellent blog by g0tmi1k, and an excellent blog post about the multiple resources for hacking and vulnerable distributions.  The link is here:

http://g0tmi1k.blogspot.com/2011/03/vulnerable-by-design.html

Here are some other sources, but keep in mind this is not exhaustive:

Metasploitable 1: http://updates.metasploit.com/data/Metasploitable.zip.torrent

Metasploitable 2: http://sourceforge.net/projects/metasploitable/files/Metasploitable2/

Kioptrix has several challenges: http://www.kioptrix.com/blog/

This should give you a good starting point for collecting vulnerable VMs.  For the remainder of this post, I’ll be using the pWnOS VM as the sample.  But you can repeat this process for all of the vulnerable distros you collect.

NOTE: Remember that by proceeding to install and run these VMs you are introducing vulnerabilities into your network, so please be careful and take the necessary precautions to isolate these VMs and your ESXi server.  If you are confused by this warning, please email me and I can help explain further.  

 

Step 2)  Download and Install VMware Converter

You may be wondering why this step is included, especially if you have acquired a VM that was already created for some form of VMware product, such as VMware Workstation or Fusion.  Well, it is important to keep in mind that ESXi requires VMs to be in a format unique to ESX, even if the VM was generated for a different VMware product.  Thus if you have a VM that is not an ESX version, then it must be converted.  Fortunately, VMware has provided a product that allows for conversions of multiple VM formats, including 3rd party VM formats (i.e. non VMware).

So in order to proceed you will need to download VMware vCenter Converter.  This is a free download and you can obtain the software plus any more information about the product here: http://www.vmware.com/products/converter/.  This product can only be installed on a Windows machine.  It is a standard installation wizard, and I recommend simply choosing any default settings for the installation, but feel free to set it up however you would like.  The primary goal for this utility, for me, is to get all of my pentesting VMs installed and running correctly on my ESXi server.

 

Step 3)  Convert VM and Upload to ESXi

Now that we have collected our vulnerable VM (or any VM for that matter) and we have installed VMware vCenter Converter we can proceed to convert the VM and upload it directly onto our ESXi datastore.  When you first fire up VMware Converter you should see this:

 

Go ahead and select “Convert Machine” from the top right.  This will present you with the screen to select the VM source you will be converting.  Make sure you also select the source VM type.  This is nice because you also have the option to convert your physical machine or even convert an ESXi Infrastructure VM back to a workstation VM.  In the case of pWnOS, it is a VMware virtual machine.

NOTE: Keep in mind that I have not uploaded anything to the ESXi server, the source VMs are all stored on my local workstation/laptop. 

 

Once you have selected your source information, click next.  Now you’re presented with the destination information.  Notice that you have the option to select the destination type.  This ia a very convenient feature because not only can you convert to a VMware Infrastructure VM, but you can also convert to a different type of VMware workstation VM.  So if you needed to convert it to a different version of VMware Fusion or Workstation, for example, this tool allows for that.  In our case, we are selecting a VMware Infrastructure virtual machine as the destination type, and you’ll notice that it is asking for the ESXi server details.  Entering in our server information and credentials allows the converted VM to be uploaded immediately to our server instead of storing the converted VM locally and manually uploading to our datastore.  I find this feature very convenient.

 

Hit next and now you’ll probably get your certificate warning.  Remember that unless you’ve installed a certificate other than the default with ESXi, you’ll get these warnings.  While it’s okay to “Ignore” this error, remember that you can ignore it because you have first hand knowledge of the server and its authenticity.  In general, do not get in the habit of ignoring certificate warnings, but in this case it’s okay.

 

Once you’ve authenticated you can select what you want to name your converted VM on your server (notice that as you add machines you can search for machine names, to ensure that you don’t introduce duplicates).

 

Once you’ve selected your name (normally leaving the default is fine), hit next and now you can select your datastore and VM version.  If you have more than one datastore, you can select to deploy to whichever datastore you like.  The VM will automatically populate into your inventory.  With respect to VM version, version 8 is the latest, as of now, and this shouldn’t have an impact for our purposes, but if you need version 7 for compatibility reasons, feel free to use it.

 

Once you’re comfortable with the Destination information, hit next and you’ll see the options for the VM.  These are all configurable, and while I recommend using the defaults, you may need to adjust some of these.  Feel free to adjust these options based on your ESXi configuration and needs.  However keep in mind that depending on the VM, you may run into some issues when deviating from the default.  You can always adjust the settings once the VM is deployed.  I did not make any adjustments, and left the defaults.

 

Once you’re finished with the options, see the summary and verify everything looks okay.

 

If everything seems okay, click Finish, and the conversion will begin.

 

Step 4)  Launch and Verify

If no errors occurred during the conversion, you should now see the VM in your inventory.  Go ahead and hit the play button to fire up the VM, you’ll notice the messages in the bottom of the console.

 

Once the machine is powered on, you can view the console to verify things seem okay.

 

Notice we have a login prompt which means things have loaded okay.

 

So now what?  How do we find the IP address?  How do we get into the box?  Well, that’s the entire point, you have to figure that out on your own 😉

 

Conclusion

That concludes the basics of setting up your own virtual pentest lab.  These same principles obviously apply to setting up your own virtual lab in general, but the goal now is to begin collecting VMs and practicing your skills.  Your lab is now your own canvas so organize and configure as you please.

 

Happy hacking!!

 

Nuggets to Remember:

  • When deploying vulnerable VMs, take the time to read the README files and any configuration issues.  Sometimes there are specific services with unique configurations and you want to take care not to destroy those settings when converting your VM.  This is kind of a live-and-learn troubleshooting tip.
  • Always protect your network!  Don’t expose your entire home LAN or lab to the world.  Take care to protect and isolate your network appropriately.
  • Currently, this setup is fairly flat in terms of network architecture, but try to set up separate subnets within your ESXi configuration to help simulate different environments.  This will help simulate realistic environments and will help you practice breaking through multiple networks.
  • As you can see in some of the images above, I’ve loaded a lot of VMs already.  I tend to work through a few at a time while keeping several suspended.  Feel free to run as many as you want at one time to simulate a network on which you can conduct discovery scans, etc.
  • DON’T CHEAT!!  As you collect vulnerable VMs, there are already a lot of writeups out there on how to get in.  Try not to reference these and attempt to get into the boxes on your own.  Once you’re in, then feel free to reference others to see what you did differently or the same.