Skip to main content

Building A Test Lab For Pentesting

We often hear people are interested in becoming involved in offensive security and wondering how they can get started. For many of us, the best learning moments have come from taking the do-it-yourself approach while building out computers and networks, really taking the time to understand how the systems work. These experiences lay the groundwork for developing technical expertise – the skillset of setting up test environments to discover the inner workings of networking, operating systems, development, and security. In this post, we will walk you through how to set up a test lab to start pentesting.

Why Build A Pentesting Test Lab?

There are many pros and cons to setting up a test lab on your own. In general, it will take more time to get set up initially, but this gives you the opportunity to understand the process and have more control to customize your environment. In some cases, it may be extremely valuable to be able to replicate a target environment for fully testing out certain types of exploits or attack chains. The experience of building, troubleshooting, and using your own network can provide deep insights into how vulnerabilities occur.

Requirements For Building A Test Lab

There are a few requirements to address before getting started. For software, you will need a hypervisor for managing virtual machines (VMs). This guide will include instructions for VMware Workstation on a Windows environment. Although the steps will be a little bit different, you can also use VMware Fusion, Oracle VirtualBox, or VMM. Each option should have a comparable set of features. You will also want to use the software vendor’s documentation as a reference to get an idea of how to set things up as you go (links are at the end of this post).

In terms of hardware requirements, you will need a computer that can run several VMs at the same time. The three main components that I’ll address here are CPU, RAM, and disk storage space.

CPU: Not all CPUs support virtualization hypervisors. At a minimum, your CPU must support Intel VT-x (virtualization technology). You may need to verify that it is enabled in the BIOS.

Enabling Intel Virtualization in BIOS for building a pentest test lab by White Oak Security.
Figure 1 Enabling Intel Virtualization in BIOS

RAM: The more RAM that you have on your system, the more memory you can allocate to VMs and the more VMs you will be able to run simultaneously. Most virtual machines will need about 1-2 GB of memory, though Windows-based systems may require more. Depending on the software or services that you plan on running, you may also need to increase accordingly. Your native operating system will also be utilizing RAM, so don’t allocate every last bit of memory to running VMs.

Disk Storage Space: Ample disk storage space will be needed to ensure that you can build as many virtual machines as needed. Solid state drives have come down in price over time, so getting a 1TB SSD shouldn’t be too expensive and it will more than accommodate all the VMs you might want to build.

Setting Virtual Networking

Before diving into building VMs, we will first need to check out the virtual network settings that your hypervisor configures out of the box. By default, VMware creates two special networks: VMnet1 (host-only) and VMnet8 (NAT). On both of these networks, your hypervisor will install a virtual adapter on your native host and a virtual DHCP server that will allocate addresses to any VMs that are attached to the networks. We don’t necessarily want to use this, as we’ll be setting up DHCP and Domain services manually, so we will need to set up a custom host-only virtual network without the attached host adapter and DHCP server. Below is an example of what it looks like. Note that both the “Connect a host virtual adapter…” and “Use local DHCP service…” checkboxes are disabled.

Accessing Virtual Network Editor for building a pentesting test lab by White Oak Security.
Figure 2 Accessing Virtual Network Editor
Figure 3 Adding a new network using Virtual Network Editor

Building VMs

For this test lab, we’ll setup the following VMs:

  • CentOS 7 – Virtual Router
    • Configured with 2 interfaces, acting as the gateway for VMnet10
    • VMnet8 – used to connect to the internet via a native host (NAT)
    • VMnet10 –172.16.100.1 (must be static)
    • Running DHCP service for VMnet10 network 172.16.100.0/24
  • Windows Server 2016 – Domain Controller VM
    • VMnet10 interface: 172.16.100.10 (must be static)
  • Windows 10 – Workstation VM
    • VMnet10 interface: dynamically-assigned IPv4 address
  • Kali Linux – Attacker VM
    • VMnet10 interface: dynamically-assigned IPv4 address

Here is a small diagram of what it will look like once it is setup:

Network Diagram for Test Lab, how it works once your VM and pentesting test lab is set up.
Figure 4 Network Diagram for Test Lab

The first step to building virtual machines is to obtain .iso files for the operating systems that you’re going to run. We’ll be using a mix of Windows and Linux distros. Once you have the necessary files, building the VMs should be fairly straightforward. Most of the settings can be left at their defaults. I recommend using descriptive names for each VM, such as “LAB_Win10_Workstation” or “LAB_Cent7_Router” so they can be readily identified. Links can be found at the bottom of this post to the download source for each ISO.

The only settings that will need to be specifically set are the Network Adapters. For each VM, go to the Settings screen and select the Network Adapter to assign them to the custom VMnet10 that we set-up earlier. For the CentOS 7 Router, add a second adapter and configure it for NAT (VMnet8). This is where all network traffic on the test lab will be routed through.

At the end of the set-up, you’ll have the opportunity to make any changes that you want, here are some example settings:

Kali VM Settings demonstrates that you can customize Vm settings.
Figure 5 Kali VM Settings
CentOS Router VM Settings demonstrates the customized VM settings.
Figure 6 CentOS Router VM Settings

Once you have the VMs built, you’ll need to go through the install process for each operating system. Most of the settings can be left at their defaults. For the login credentials, make sure you use something that you will not forget, as you might need to rebuild it if you forget them.

Configure Virtual Machines

At this point, we’ll need to configure networking on the virtual machines. For the CentOS Router, we’ll also set up DHCP and configure it with a basic NAT/IP masquerade setup.

Configure Virtual Router

Below is a breakdown of the commands required to set up the Linux machine as a virtual router. Note that these commands should be run using the root user account.

In order to identify which interface is associated with the external (NAT) interface, you’ll need to compare the settings for the VM and within the CentOS virtual machine.

Identifying MAC on external (NAT) interface for configuring virtual routers, building VMs for pentesting test lab by White Oak Security.
Figure 7 Identifying MAC on external (NAT) interface

Identify which interface is “external” for the test lab based on the MAC address. On this one, ens34 is the external NAT network and ens33 is associated with the internal VMnet10 network.

nmcli device show
Identifying interface associated with external MAC address using nmcli command for building a pentest test lab by white oak security.
Figure 8 Identifying interface associated with external MAC address using nmcli command

Set external interface using command line (dynamic):

nmcli connection add con-name ext0 ifname ens34 type ethernet autoconnect yes
nmcli connection modify ext0 ipv4.dns 1.1.1.1
nmcli connection modify ext0 connection.zone external
nmcli connection up ext0

Set internal interface using command line (static):

nmcli connection add con-name int0 ifname ens33 type ethernet autoconnect yes ip4 172.16.100.1/24 gw4 172.16.100.1
nmcli connection modify int0 ipv4.method manual ipv4.dns 172.16.100.10 ipv6.method ignore ipv4.never-default yes
nmcli connection modify int0 connection.zone internal
nmcli connection up int0

Install and configure DHCP:

yum install dhcp -y

Add the following lines to the dhcpd.conf file:

default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;
authoritative;
subnet 172.16.100.0 netmask 255.255.255.0 {
range 172.16.100.128 172.16.100.254;
option routers 172.16.100.1;
option subnet-mask 255.255.255.0;
option domain-name-servers 172.16.100.10;
}

Run and enable DHCP server:

systemctl enable dhcpd
systemctl start dhcpd

Configure routing and NAT for internal virtual network:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -w net.ipv4.ip_forward=1
firewall-cmd --permanent --direct --passthrough ipv4 -t nat -I POSTROUTING -o ens34 -j MASQUERADE -s 172.16.100.0/24

Modify default firewall zones:

firewall-cmd --change-interface=ens34 --zone=external --permanent
firewall-cmd --set-default-zone=internal
firewall-cmd --complete-reload

Install open-vm-tools (optional):

yum install open-vm-tools -y

At this point, basic networking should be available on the network, including DHCP which will provide clients with dynamic IP addresses and connectivity options. Although we set up DHCP to provide clients with a DNS server on the network, we have not yet configured DNS, which will be provided by the domain controller.

Configure Domain Controller

For the test lab, we’ll configure the Windows 2016 server with a basic Active Directory set-up. First, you’ll need to configure a static IP address and networking information. You also will want to change the hostname to something more indicative of a domain controller, such as “dc01”. For all commands, you’ll need to open a PowerShell window as an administrator.

Determine interface index for Ethernet0 adapter:

Get-NetIPAddress -AddressFamily IPv4
Identify InterfaceIndex of Ethernet0 for building a test lab by white oak security blog.
Figure 9 Identify InterfaceIndex of Ethernet0

Configure networking via PowerShell command line for interface index 5:

New-NetIPAddress -InterfaceIndex 5 -IPAddress 172.16.100.10 -PrefixLength 24 -DefaultGateway 172.16.100.1
Set-DnsClientServerAddress -InterfaceIndex 3 -ServerAddresses (“127.0.0.1”,”1.1.1.1”)
Rename-Computer -NewName “dc01” -Restart

Set local administrator account password (this account will become the domain admin account upon installation of domain services):

Get-LocalUser -Name Administrator | Set-LocalUser -Password (Read-Host -AsSecureString)

(Enter password interactively)

Install Active Directory and set up server as Domain Controller (you will need to setup a DSRM password, which is used for booting the DC into safe mode):

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName “testlab.local” -InstallDns

(Enter DSRM password interactively)

Figure 10 Example Active Directory install steps

Configure Windows 10 Workstation

Once you have your domain controller setup, the final step in setting up the target virtual machines will be to attach the workstation to the domain. Once again, you’ll want to rename the host to something more descriptive, representing a real network setup.

Configure networking via PowerShell command line (will reboot afterwards):

Rename-Computer -NewName “workstation01” -Restart

Add computer to domain:

Add-Computer -DomainName testlab.local -Credential testlab\Administrator -Restart -Force

Next Steps

Once everything is set up, you should be able to log into your Kali attack VM and it will obtain a DHCP lease just as the Windows 10 machine does. From here, you should be able to access the network with everything configured in a baseline state. Out of the box, Windows configurations are fairly secure by default, although in the real world this will change substantially based upon the use case and functionality needed for the domain. Even so, there are many initial steps that can be taken to assess the network. To start, a quick Nmap scan can be used to probe the domain controller, as shown below:

Figure 11 Nmap scan of the domain controller for building a pentesters test lab by a white oak security expert.
Figure 11 Nmap scan of domain controller

In the next post in this series, we’ll walk through a few different attack scenarios and their pre-requisite conditions. As we continue, we’ll be adjusting the domain and lab environment to represent a more realistic configuration beyond the straight-out-of-the-box setup.

MORE FROM WHITE OAK SECURITY 

White Oak Security is a highly skilled and knowledgeable cyber security testing company that works hard to get into the minds of opponents to help protect those we serve from malicious threats through expertise, integrity, and passion. 

Read more from White Oak Security’s pentesting team.

References

VMware Workstation documentation: https://docs.vmware.com/en/VMware-Workstation-Pro/index.html
Oracle VirtualBox documentation: https://www.virtualbox.org/wiki/Documentation
Virtual Machine Manager documentation: https://virt-manager.org/
RedHat VMM documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_getting_started_guide/chap-virtualization_manager-introduction
CentOS download: https://www.centos.org/download/
Windows Server 2016 evaluation copy: https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2016
Windows 10 evaluation copy: https://www.microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise
CentOS network configuration: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_ip_networking_with_nmcli
CentOS dhcpd configuration: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-dhcp-configuring-server
CentOS firewalld configuration: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using_firewalls
Active Directory reference: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-domain-services
PowerShell 5.1 reference: https://docs.microsoft.com/en-us/powershell/module/?view=powershell-5.1