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.
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.
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.
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.
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.
For this test lab, we’ll setup the following VMs:
Here is a small diagram of what it will look like once it is setup:
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:
Once you have the VMs built, you’ll need to go through the installation 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.
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.
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.
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 showSet 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 ext0Set 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 int0Install and configure DHCP:
yum install dhcp -yAdd 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 dhcpdConfigure 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/24Modify default firewall zones:
firewall-cmd --change-interface=ens34 --zone=external --permanent
firewall-cmd --set-default-zone=internal
firewall-cmd --complete-reloadInstall open-vm-tools (optional):
yum install open-vm-tools -yAt 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.
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 IPv4Configure 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” -RestartSet 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)
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” -RestartAdd computer to domain:
Add-Computer -DomainName testlab.local -Credential testlab\Administrator -Restart -ForceOnce 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:
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.
Cyber Advisors specializes in providing fully customizable cyber security solutions & services. Our knowledgeable, highly skilled, talented security experts are here to help design, deliver, implement, manage, monitor, put your defenses to the test, & strengthen your systems - so you don’t have to.
Read more from our technical experts...