Vlad Ioan Topan

My playground

Setting Up a Pentesting Lab

leave a comment »

Setting Up a Pentesting Lab

October, 2015 – version 1.0


There’s a recent surge of information about pentesting on the Internet (as opposed to, say, a few years ago, when finding relevant information took you on an exciting ride through the dark side of the Internet, occasionally grabbing a few parasites along the way). Pentesting is a relatively new business, "extorting" amazing amounts of money from organizations on the premise of bringing safety to their data. I say extorting because on one hand, most evil "hacking" nowadays involves breaking your website rather than your Internet-exposed, non-web servers via vulnerabilities in software out of your control, so the better solution is to permanently audit your code, not to see if it can be broken at a specific moment in time. On the other hand, given the volume of software you now depend on for running an Internet-facing server, the probability of exploitable vulnerabilities being present is about one, and there’s very little you can do about that. Properly configured software and piling on defensive mechanisms would help, but in any large enough network that quicly becomes unfeasible. Still, people are willing to pay astounding amounts of money for the illusion of safety, so here we are.


Pentesting is a code word for hacking, but when a "good guy" does it (in order to assess the security status of a network). That guy used to be called a "white hat hacker", but the less emphatic "pentester" is now used. The full name "penetration testing" is also used, but the short hand "pentesting" is preferred, probably because it does not contain the word penetration.

A pentesting lab allows you, the "security researcher", to practice exploiting sofware vulnerabilities and to develop exploits for newly found vulnerabilities. It essentially involves:

  • some sort of virtualization solution (usually VirtualBox or VMWare Player, but if you’re ambitious enough, a dedicated host running something like ESXi is better);
  • inside that environment, a variety of vulnerable operating systems ("targets") are deployed; some as old as Windows XP / Ubuntu 6.06 for studying basic buffer overflows or ancient bugs, and some as recent as Windows 8.1 (or even 10) / Ubuntu 15.10 for testing the latest privilege escalation exploits;
  • on the VMs you want vulnerable software (which sometimes is the actual OS, but more often third party software) and debugging tools (such as the Immunity Debugger);
  • an additional VM is often used as a pentesting OS, because having the tools pre-packaged and playing well together out of the box is nice to have; Kali is the most common choice, but other options do exist.

Virtualization software

Installing a free virtualization solution such as VMWare Player or VirtualBox should be easy enough; for the rest of this text I’ll be describing VirtualBox, but the same concepts apply to any other similar software.

Setting up networking

The target VMs and the pentesting VM should be able to connect to each other, but only the pentesting VM may have occasional access to the Internet (for updates), preferrably when not connected to the network containing the target VMs. To achieve this, an internal network is used by configuring the virtual network adapter for each target VM this way: VM right click->Settings…->Network->Attached to: Internal Network; the default "intnet" name may be used, or a custom one can be specified. All VMs connected to an internal network with the same name will "see" each other by magic performed by VirtualBox. They will also get a dynamic, unique IP address via DHCP, if it is enabled for the given internal network. To enable it, run something like this in a console:

"c:\Program Files\Oracle\VirtualBox\VBoxManage" dhcpserver add --netname "intnet" --ip --netmask --lowerip --upperip --enable

Change the "intnet" name to the same one you use for the VMs, and the IP ranges if needed. To make sure it’s created and enabled, run:

"c:\Program Files\Oracle\VirtualBox\VBoxManage" list dhcpservers

Doing this while a target VM is running may be glitchy (the DHCP server won’t work); restarting both the VM and VirtualBox might help with that.

If you want the host to be connected to the same network as the targets (use this option with great care, especially if you run untrusted binaries, such as precompiled exploits, on the target VMs), use host only adapters, which connect the VMs to each other and to the host.

On the VM side of things, enable DHCP networking and make sure the default firewall is disabled (all Windows versions since XP have it on by default), or at least poke holes through it for the apps you want to exploit remotely.

Setting up the target OSes for virtualization

On VMs where they are available, the VirtualBox Guest Additions greatly improve performance. The Guest Additions CD is part of the VirtualBox Extension Pack and must be downloaded separately (due to different licensing); it is available on the VirtualBox download page and is cross platform. After installing the Extension Pack, run the VM and click Devices->Install Guest Additions CD Image…. The process is automatic on Windows; on Linux, you may need to mount the CDROM and run the installation manually.

Shared folders are helpful to install software on the VMs (never give read-write access to entire volumes; create a specific shared folder and use that).

The shared clipboard is useful to copy values and commands to/from the host (Devices->Shared clipboard->Bidirectional).

Virtual machines


Download Kali and install it. Configure Metasploit and you’re good to go.

If your host is also a Linux machine, don’t forget to put your SSH public key in Kali root’s authorized_keys to simplify the process.

De-ICE 1.123

As a first target VM, a pre-built VM specially designed for pentesting such as De-ICE 1.123 is a good choice, as it has a set of vulnerable applications already installed and configured. De-ICE does not need to be installed (the OS runs directly from the ISO image and thus changes to the disk are non-persistent), so the VM does not require an attached hard disk.

Windows XP

As a second VM, Windows XP should be an easy target (both for the installation process, and for any actual pentesting). You need an ISO image of the OS installation disk (as with all the other OSes for the lab). Microsoft provides images for MSDN subscribers (e.g. Windows 8.1), but only for their currently supported OSes (8.1 and 10 at this time), and obviously only if you’ve purchased them. Downloadable ISOs for Windows XP SP3 still exist (e.g. xpsp3_5512.080413-2113_usa_x86fre_spcd.iso), but since Microsoft no longer supports Windows XP, I expect them not to be available for long. Using an old installation CD you have is also an option; use a CD ripping tool to obtain the ISO image.

This version of Windows (particularly pre-SP3) employs very few defenses against software exploitation, so it’s particularly useful for learning simple overflow exploits without having to worry about DEP/ROP.

Ubuntu 15.10

A recent Linux, such as the latest version of Ubuntu, is a good choice as a target VM particularly for web vulnerabilities; Apache and nginx are easy to install/configure. Most public vulnerabilities are in older versions than what you can get from the repos, but recent privilege escalation exploits (LPE) do exist.

More Windows / Linux versions

As OSes progress, developers attempt to make software vulnerabilities harder to exploit; a wider selection of OS versions, particularly for Windows, will allow you to develop exploits from very simple (on the still-used Windows XP) to very complex (involving ROP chains and dealing with ASLR, on post-Windows 7 versions). Evolving versions of the kernel are also available this way, which is particularly relevant to privilege escalation exploits.

Pre-built targets

The go-to pentesting target OS is Metasploitable, which is specially designed for testing the Metasploit framework, but can also be attacked "manually".

Aa growing number of pentesting target OSes (like the previousely mentioned De-ICE 1.123) are collected at vulnhub.com. Some of them (particularly the ones prepared for CTF competitions) are difficult to break, but some are easier. All of them are Linux based, so for exploiting actual vulnerable applications on Windows see the next section.

Software for the VMs

Debugging software

On Windows machines, having debugging software specifically designed for developing exploits is very useful. Immunity Debugger is a very popular choice (32 bits only), often accompanied by mona.py (to install mona, download and copy it to the C:\Program Files\Immunity Inc\Immunity Debugger\PyCommands folder).

Vulnerable applications

Although attacking vulnerabilities you compiled yourself in a test binary does have some pedagogic merit, there’s far more to gain from attacking actual vulnerabilities in public applications. The easiest way to find such apps is to approach the problem from the other end and look for exploits on sites which collect them, and then try to find a version of the application which is vulnerable to that exploit.

  • exploit-db is the best known exploit repository (started from the now defunct Milw0rm archive, and continuously updated since).
    • Some of the exploits have locally-archived copies of the vulnerable apps, you can find them in the page header.
  • PacketStorm is another well known repository, and it allows better exploit filtering. To find remotely-exploitable overflows, for example, build an URL manually by appending the appropriate tags to the find-by-tag URL:

Old versions of applications

After finding out which version of a software you need, getting an actual copy of the installation kit may prove challenging, particularly for very old, not very well known or very large applications. The following software repositories might help, as they retain older versions:

If all else fails, search the web for the specific version (it helps a lot if you can find the actual filename the kit used to have).

Written by vtopan

October 13, 2015 at 9:27 PM

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: