Build Your Own Pentesting Lab.
part 3: the machines you’re allowed to break.

An attack machine with nothing to attack is just a really cool Linux desktop. Time to give it something to do. We’re deploying vulnerable targets and locking the whole thing inside an isolated network.

The scenario: BrightPath’s network in miniature

BrightPath Financial has a bunch of servers sitting behind a firewall. A web application that customers log into. A Linux server running internal services. Some old boxes that nobody has patched since the last administration. Your job is to test all of it for weaknesses before someone with bad intentions finds them first.

But you’re not touching the production network yet. You’re building a miniature version of it in your lab. Think of it like a scale model of a city that architects use before constructing the real thing. Same layout. Same types of buildings. Same streets connecting them. Just smaller and completely disposable.

Metasploitable 2 represents BrightPath’s internal Linux servers. The ones running outdated services, weak passwords, and misconfigurations that nobody has gotten around to fixing. DVWA represents the customer-facing web application. The one that probably has SQL injection in the login form because the developer who built it left the company three years ago and nobody’s reviewed the code since.

And the isolated network we’re about to create? That represents BrightPath’s internal network. A closed environment where your machines can communicate with each other but can’t reach the outside world. Just like a real corporate LAN during an internal pentest.

By the end of this post, you’ll have the full lab running. Three machines. One network. Zero connection to anything real.

Setting up the isolated network (Host-Only)

This is the most important step in the entire series and it’s the one most tutorials gloss over. If you get the networking wrong, your lab isn’t isolated. Your attack traffic leaks onto your real network. Your vulnerable VMs are exposed to the internet. That old Metasploitable machine with default passwords? It’s now reachable by anyone on your WiFi. Don’t let that happen.

VMware has three network modes. Let’s understand them so you know what you’re choosing and why.

NAT (Network Address Translation)
  VMs share your host's IP to reach the internet.
  VMs can reach the internet. Internet can't reach VMs.
  We used this in Part 2 to update Kali.

Bridged
  VMs get their own IP on your real network.
  They appear as separate devices on your WiFi/LAN.
  Other devices on your network can see them.
  NEVER use this for vulnerable VMs. Ever.

Host-Only                          ← THIS IS WHAT WE WANT
  VMs can talk to each other and to the host machine.
  VMs CANNOT reach the internet.
  Nothing outside your computer can reach the VMs.
  Completely isolated. Perfect for a pentest lab.

We want Host-Only. Every VM in the lab gets connected to the same Host-Only network. They can all see each other. Nothing else can see them. That’s the whole point.

Creating the Host-Only network in VMware:

Windows:

VMware Player on Windows usually creates a Host-Only network automatically during installation called VMnet1. To verify it exists or create one:

1. Open "Virtual Network Editor"
   → search "vmnetcfg" in Start menu
   → or find it in VMware's install folder

   If Player doesn't include it (common on free version),
   you can still select "Host-Only" in each VM's settings
   and VMware will use the default VMnet1.

2. If the editor is available:
   → Click "Change Settings" (needs admin)
   → Find VMnet1 (Host-Only)
   → Make sure "Connect a host virtual adapter" is checked
   → Subnet IP: 192.168.56.0  (or leave the default)
   → Subnet Mask: 255.255.255.0
   → DHCP: Enabled (so VMs get IPs automatically)
   → Apply

macOS (Fusion):

1. Open VMware Fusion
2. Go to VMware Fusion → Preferences → Network
3. You should see vmnet1 (Host Only) already listed
4. If not, click the "+" to add a new network
   → Uncheck "Allow virtual machines on this
      network to connect to external networks"
   → Uncheck "Provide addresses on this network via DHCP"
      (actually leave DHCP on for now, easier for beginners)
5. Note the subnet. Default is usually 192.168.56.0/24

Linux:

# check existing virtual networks
vmware-networks --list

# if vmnet1 (host-only) doesn't exist, create it
# open the virtual network editor
sudo vmware-netcfg

# Or edit the config directly:
sudo nano /etc/vmware/networking

# You should see something like:
# answer VNET_1_HOSTONLY_NETMASK 255.255.255.0
# answer VNET_1_HOSTONLY_SUBNET 192.168.56.0
# answer VNET_1_DHCP yes

Importing Metasploitable 2 (your Linux target)

Metasploitable 2 is a Ubuntu-based Linux VM that was designed by Rapid7 to be the worst server on the internet. Default credentials everywhere. Unpatched services running on every port. Known vulnerabilities stacked on top of each other like a Jenga tower held together by hope. It’s perfect.

Step 1. Extract the download.

Windows:  Right-click the .zip → Extract All
macOS:    Double-click the .zip
Linux:    unzip metasploitable-linux-2.0.0.zip

You’ll get a folder with a .vmx file and some .vmdk disk files inside.

Step 2. Open in VMware.

Same as Kali. In VMware, click Open a Virtual Machine. Navigate to the extracted folder. Select the .vmx file. Click Open.

VMware might ask if you moved or copied this VM. Click “I Copied It.” This tells VMware to generate new unique identifiers for the VM so it doesn’t conflict with anything else. Doesn’t actually matter in our lab but it’s good practice.

Step 3. Change the network to Host-Only.

Before you power it on, click Edit virtual machine settings. Find the Network Adapter. Change it from NAT (or whatever it defaulted to) to Host-Only.

This is critical. Metasploitable has no firewall. No updated packages. Default passwords on everything. If you leave it on NAT or Bridged, it’s exposed. On Host-Only, it’s safely locked inside the lab network.

Step 4. Boot it up.

Power on the VM. It boots to a text-based login screen. No desktop environment. No GUI. Just a terminal. This is normal. Metasploitable is a server. Servers don’t need pretty interfaces. They need open ports and the default credentials are:

Username:  msfadmin
Password:  msfadmin

Log in. You should see a command prompt. Now let’s grab the IP address:

ifconfig

Look for eth0 and the inet addr line. It’ll be something like 192.168.56.101 or whatever your Host-Only DHCP assigned. Write this IP down. You’ll need it in Part 4 when you point your attack tools at it.

If it says there’s no IP or the interface is down, DHCP might not have assigned one yet. Try:

sudo dhclient eth0
ifconfig

That forces a DHCP request. You should get an IP now.

Setting up DVWA (your web app target)

DVWA is a web application built in PHP that’s intentionally full of security vulnerabilities. SQL injection. XSS. Command injection. File inclusion. CSRF. It’s basically a checklist of everything OWASP warns you about, wrapped in a web app you can actually attack.

There are a few ways to get DVWA running. The easiest for our lab is to install it directly on Metasploitable 2, since that machine already has Apache and PHP running. But that ties two targets together on one machine, which is messy. The cleaner approach is a separate VM.

Here’s the quickest clean setup: a lightweight Linux VM running DVWA.

Option A: Use a pre-built DVWA VM (fastest)

Several people have built pre-packaged DVWA VMs that you just download, import, and boot. Search for “DVWA VM download” or “Damn Vulnerable Web Application VM.” VulnHub has several options. Download the .ova or .vmdk file, import it into VMware the same way we imported the others.

Option B: Install DVWA on a fresh lightweight VM (more control, more learning)

If you want to understand what’s happening under the hood (and you should, because setting up a LAMP stack is a real sysadmin skill), here’s how to do it on a minimal Debian or Ubuntu Server VM.

First, create a new VM in VMware using a Debian or Ubuntu Server ISO. Give it 512MB RAM and 8GB of disk. Set the network to Host-Only. Install the OS with defaults. Then once you’re logged in:

# install the LAMP stack
sudo apt update
sudo apt install apache2 mariadb-server php php-mysqli php-gd git -y

apache2 is the web server. mariadb-server is the database (MySQL-compatible). php and its modules run the DVWA application. git is how we’ll download DVWA.

# clone DVWA into the web root
cd /var/www/html
sudo git clone https://github.com/digininja/DVWA.git
sudo chown -R www-data:www-data /var/www/html/DVWA

That downloads DVWA and gives the web server ownership of the files so Apache can serve them.

# create the config file from the template
cd /var/www/html/DVWA/config
sudo cp config.inc.php.dist config.inc.php

Now we need to set up the database. Open the config file and check the database credentials:

sudo nano /var/www/html/DVWA/config/config.inc.php

# find these lines:
# $_DVWA[ 'db_server' ]   = '127.0.0.1';
# $_DVWA[ 'db_database' ] = 'dvwa';
# $_DVWA[ 'db_user' ]     = 'dvwa';
# $_DVWA[ 'db_password' ] = 'p@ssw0rd';

# leave them as they are. now create that user in MariaDB:

# set up the database
sudo mysql -u root

# inside the MariaDB prompt:
CREATE DATABASE dvwa;
CREATE USER 'dvwa'@'localhost' IDENTIFIED BY 'p@ssw0rd';
GRANT ALL PRIVILEGES ON dvwa.* TO 'dvwa'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Now tweak a couple PHP settings that DVWA needs:

# find your php.ini
php --ini | grep "Loaded"

# edit it (path may vary by PHP version)
sudo nano /etc/php/8.2/apache2/php.ini

# find and change these:
#   allow_url_include = Off   →   allow_url_include = On
#   allow_url_fopen = Off     →   allow_url_fopen = On

# restart Apache
sudo systemctl restart apache2

Now get the DVWA machine’s IP:

ip a | grep inet

Write down this IP too. You now have two target IPs: Metasploitable and DVWA.

We’ll finish the DVWA setup from the browser in Kali once we confirm the network works. Which brings us to the next step.

Switching Kali to the isolated network

Remember in Part 2 we left Kali on NAT so it could reach the internet for updates? Time to cut the cord.

In VMware, select your Kali VM. Click Edit virtual machine settings (or the wrench icon). Find the Network Adapter. Change it from NAT to Host-Only. Click OK.

That’s it. Kali is now on the same isolated network as Metasploitable and DVWA. It can see them. They can see it. Nobody outside your computer can see any of them.

If Kali is already running, you can apply the change without rebooting. Inside Kali, open a terminal:

# release old IP and get a new one from the Host-Only DHCP
sudo dhclient -r eth0
sudo dhclient eth0

# check your new IP
ip a | grep inet

Kali should now have an IP on the same subnet as your targets. If Metasploitable is on 192.168.56.101 and DVWA is on 192.168.56.102, Kali should be something like 192.168.56.103. All in the same neighborhood.

Verifying everything can talk to each other

This is the moment of truth. Three VMs. One network. Let’s make sure they can all see each other. And let’s make sure they can’t see anything they shouldn’t.

From Kali, ping both targets:

# replace with your actual target IPs
ping -c 3 192.168.56.101    # metasploitable
ping -c 3 192.168.56.102    # dvwa

You should see replies from both. Three packets sent, three packets received, 0% packet loss. If you see “Destination Host Unreachable” or 100% loss, something’s wrong with the network config. Check that all three VMs are on the same Host-Only network in VMware settings.

Verify isolation — make sure you CAN’T reach the internet:

# this SHOULD fail
ping -c 3 8.8.8.8
ping -c 3 google.com

Both should time out or say “Network is unreachable.” That’s what you want. If you CAN reach 8.8.8.8, your network isn’t isolated. Go back and check the VMware network settings. Make sure it’s Host-Only, not NAT.

Run a quick nmap scan to confirm Metasploitable is as exposed as it should be:

# quick scan from Kali targeting Metasploitable
nmap -sV 192.168.56.101

You should see a bunch of open ports. FTP on 21, SSH on 22, Telnet on 23, HTTP on 80, SMB on 139 and 445, MySQL on 3306, and more. If you see 15+ open ports and services, Metasploitable is working correctly. It’s supposed to look terrifying. That’s the whole point.

Finally, finish the DVWA setup from Kali’s browser:

Open Firefox in Kali. Navigate to http://[DVWA-IP]/DVWA/setup.php. You should see the DVWA setup page. Scroll to the bottom and click “Create / Reset Database.” It’ll create the tables it needs. Then it redirects you to the login page.

DVWA login:
  Username:  admin
  Password:  password

Yes, the password is “password.” This is a vulnerable web app. On purpose. We’ve been over this.

Once logged in, go to DVWA Security in the left sidebar and set the security level to Low. This makes all the vulnerabilities easy to exploit while you’re learning. You can increase the difficulty later once you know what you’re doing.

What you’ve actually built and why it matters

Take a step back and look at what’s running on your computer right now.

┌──────────────────────────────────────────────────┐
│              HOST-ONLY NETWORK                    │
│              (completely isolated)                │
│                                                   │
│   ┌──────────┐  ┌────────────┐  ┌────────────┐  │
│   │   KALI   │  │  METASPLOI │  │    DVWA    │  │
│   │  .56.103 │  │  TABLE 2   │  │   .56.102  │  │
│   │          │  │  .56.101   │  │            │  │
│   │ attacker │  │ linux tgt  │  │  web tgt   │  │
│   └──────────┘  └────────────┘  └────────────┘  │
│                                                   │
│   ✅ all three can ping each other                │
│   ❌ none of them can reach the internet          │
│   ❌ nothing outside can reach them               │
└──────────────────────────────────────────────────┘

You’ve built a miniature corporate network. In BrightPath terms: Kali is your pentester workstation. Metasploitable is the server closet full of legacy Linux boxes. DVWA is the customer-facing web app. The Host-Only network is the internal LAN.

This is the exact same topology a real pentester uses during an internal engagement. The only difference is the scale. Instead of hundreds of servers, you have two. Instead of a physical switch, you have a virtual network. The methodology, the tools, and the workflow are identical.

And here’s what most people miss: setting up this lab is itself a marketable skill. You just configured a hypervisor, deployed multiple virtual machines across three different operating systems, set up LAMP stack, configured database users, built an isolated virtual network, and verified it with network scanning tools. That’s not just “learning about pentesting.” That’s systems administration, networking, and security rolled into one project.

Final checklist: is your lab ready?

# 1. all three VMs are set to Host-Only networking
#    check in VMware → VM Settings → Network Adapter

# 2. all three VMs have IPs on the same subnet
ip a | grep inet   # run on each VM

# 3. Kali can ping Metasploitable
ping -c 3 192.168.56.101

# 4. Kali can ping DVWA
ping -c 3 192.168.56.102

# 5. Kali CANNOT reach the internet (this should fail)
ping -c 3 8.8.8.8

# 6. nmap scan shows Metasploitable has 15+ open ports
nmap -sV 192.168.56.101

# 7. DVWA is accessible from Kali's browser
#    http://[DVWA-IP]/DVWA/login.php
#    login: admin / password

# 8. DVWA security level is set to Low
#    DVWA Security → set to Low → Submit

# 9. snapshot taken of all three VMs in this state
#    this is your "lab ready" restore point

# 10. you wrote down all three IP addresses
#     Kali: _______________
#     Metasploitable: _______________
#     DVWA: _______________

Ten checks. If they all pass, your lab is built. The playground is open. The attack machine is loaded. The targets are waiting. Everything is isolated. Nothing can leak.

Time to break something.