I've been wanting a safe, isolated environment where I could actually practice security concepts instead of just reading about them. Reading about vulnerabilities and exploits only gets you so far ā€” at some point you need a sandbox where you can break things, fix things, and see how attacks and defenses actually behave on a network.

So I set out to build a small virtual lab on my own machine: a Kali Linux box as my "attacker" workstation, and Metasploitable2 as an intentionally vulnerable target to practice against. This post walks through exactly how I set it up, the mistakes I ran into, and how I verified everything was working before moving on to actual testing.

Problem Statement

Running security tools on a live network ā€” or worse, on your host OS ā€” is a bad idea for two reasons: it's risky (you could accidentally affect real systems), and it's messy (cleaning up after a misconfigured test is a pain). The fix is virtualization: spin up isolated VMs, connect them through a private virtual network, and keep everything contained on your own laptop or desktop.

The goal here was simple: get Kali and Metasploitable2 running side by side, talking to each other on an isolated virtual network, without touching my host system or any real network.

Step-by-Step Setup

1. Install VirtualBox

Grab VirtualBox from the official site: https://www.virtualbox.org/wiki/Downloads. Pick the build that matches your host OS and install it normally.

2. Create and Install the Kali Linux VM

Download the Kali installer image ā€” "Installer Images ā†’ 64-bit ā†’ Everything" is the right choice (skip the Weekly and NetInstaller builds).

When creating the VM in VirtualBox, I used these specs:

Setting Value
Disk space 60 GB
RAM 4 GB
CPU cores 3
OS Type Linux ā†’ Debian 10.x (64-bit)
Boot firmware UEFI

A note on disk size: the default 20GB is too small once you start running heavier tools like Nessus or OpenVAS later on, so I gave it more room upfront.

Boot the VM, choose "Graphical Install" from the menu, and walk through it like a normal Linux install. When it asks where to put the GRUB bootloader, point it at /dev/sda (or /dev/nvme0n1 if that's what shows up). Let it reboot when it's done, then log in.

Once you're in, update everything:

sudo apt update
sudo apt -y upgrade
Enter fullscreen mode Exit fullscreen mode

Check your version to confirm everything's current:

lsb_release -a
Enter fullscreen mode Exit fullscreen mode

3. Install VirtualBox Guest Additions

This step makes the VM way more pleasant to use ā€” proper window resizing, better mouse integration, etc.

sudo apt update
sudo apt install -y virtualbox-guest-x11
sudo reboot
Enter fullscreen mode Exit fullscreen mode

After the reboot, also go into your VM's Settings ā†’ General ā†’ Advanced and set both Shared Clipboard and Drag'n'Drop to "Bidirectional" instead of the default "Disabled." Small thing, but it makes copy-pasting commands between host and VM much easier.

4. Set Up Metasploitable2 as the Target

Metasploitable2 is distributed as a ready-made VMware disk (.vmdk), not an ISO, so the install process looks a little different. Download it from Sourceforge and unzip it somewhere convenient.

In VirtualBox, create a new VM with:

  • Type: Linux
  • Version: Ubuntu (64-bit)
  • RAM: 512 MB is plenty

The key difference from the Kali setup: when it asks about the virtual disk, don't create a new one ā€” point it at the existing .vmdk file you extracted. No install step needed; it boots straight up.

Default credentials are msfadmin / msfadmin.

āš ļø Important: This VM is intentionally riddled with vulnerabilities. Never connect it to anything beyond your isolated lab network ā€” NAT or host-only mode only.

Once you've confirmed you can log in, shut it down and take a snapshot (something like "Clean Metasploitable2 state" works fine as a name). That way, no matter how badly you break it later, you can roll back instantly.

5. Configure the Virtual Network

By default, VirtualBox's plain "NAT" mode doesn't let VMs talk to each other ā€” you need "NAT Network" mode instead.

Go to File ā†’ Preferences ā†’ Network, click the "+" icon, and add a new NAT Network. The default name (NatNetwork) and default subnet (10.0.2.0/24 with DHCP enabled) are fine as-is.

Then, for each VM (Kali and Metasploitable2), go to Settings ā†’ Network ā†’ Adapter 1, and change "Attached to" from "NAT" to NAT Network, making sure the Name field points to your new network.

How to Verify

Once both VMs were up, I checked a few things to confirm the lab was actually working:

  1. Kali boots to a usable desktop ā€” no install errors, guest additions working, window resizes properly.

  2. Metasploitable2 boots and accepts login ā€” confirms the .vmdk was mounted correctly and the NAT Network adapter is active.

  3. Resource usage looks sane with both VMs running ā€” I kept an eye on RAM and CPU through the host's system monitor to make sure I wasn't overcommitting resources.
    (Memory usage sitting around 80% with two VMs plus the host running gave me a good sense of how much headroom I actually have for heavier tools later.)

  4. Basic ping test between the two VMs to confirm they can actually see each other on the NAT Network ā€” this is the real proof the network config worked, since both VMs booting independently doesn't guarantee they can talk to each other.

What I Learned

A few things stood out while doing this:

  • VirtualBox's "NAT" and "NAT Network" modes are easy to confuse but behave very differently. Plain NAT isolates each VM from the others; NAT Network lets them share a private subnet and actually communicate ā€” which is exactly what you need for any kind of attacker/target setup.
  • Snapshots aren't optional when working with intentionally vulnerable systems. The first time I messed up a config on Metasploitable2, having a clean snapshot to revert to saved me from a full reinstall.
  • Resource planning matters more than I expected. Running two VMs plus a host OS at once means watching RAM and CPU closely ā€” giving Kali too much disk/RAM upfront just steals resources you'll want when running heavier tools later.
  • Isolation is the whole point. Keeping a deliberately vulnerable machine off any real network isn't just good practice ā€” it's the difference between a safe learning environment and an actual security incident.

Common Mistakes Table

Mistake Why It Happens Fix
VMs can't ping each other Using default "NAT" mode instead of "NAT Network" Switch both VMs' Adapter 1 to "NAT Network"
Metasploitable2 won't boot Trying to create a new virtual disk instead of using the existing .vmdk Point the VM at the existing disk file during creation, don't create a new one
Kali window won't resize Guest Additions not installed Install virtualbox-guest-x11 and reboot
Clipboard/drag-drop doesn't work between host and VM Shared Clipboard / Drag'n'Drop left on "Disabled" Set both to "Bidirectional" in VM Settings ā†’ General ā†’ Advanced
Running out of disk space mid-lab Allocated the default 20GB to Kali Allocate at least 60GB upfront if you plan to run scanners like Nessus/OpenVAS later

Conclusion

This was a pretty satisfying first step into building out a proper home lab. Nothing here is advanced yet ā€” it's just plumbing ā€” but plumbing matters. Having an isolated, repeatable environment means I can now move on to actually practicing scanning, enumeration, and exploitation techniques without worrying about breaking anything real.