Building Lab Wintermute: Isolated Pentesting Environment Construction

By now you've got the language down — Python's syntax, the CIA triad, what a CVE actually means when you're reading a report. But knowing the words and saying them in a room are different things. This page is where we stop talking and start building. Lab Wintermute is our authorized training ground: a Kali attacker workstation, a Metasploitable2 server, and a DVWA web target, all locked inside a VirtualBox network that cannot touch anything you care about. I have rebuilt this lab maybe thirty times across different machines, different OS versions, different student cohorts. The steps below are the ones that survive that friction.

Host Preparation and VirtualBox Installation

VirtualBox is free, cross-platform, and sufficient for our needs. VMware Workstation is commercial software with more features; VMware Player is free but feature-limited. I use VirtualBox for teaching because every student can install the same thing regardless of whether their laptop is five years old or brand new. Check for the latest release on the official site rather than trusting whatever your package manager claims is current — the repository lag on some distributions is real.

Download the installer for your host OS. The process is straightforward: run the installer, accept the network driver warnings (VirtualBox installs virtual network adapters that your firewall will notice), and reboot if prompted. On a Kali Linux host, you would launch VirtualBox from terminal with virtualbox, but most of you are on Windows or macOS hosts for this build. That distinction matters later only if you try to follow Kali-specific host instructions from the documentation — Kali's docs explicitly separate "installing VirtualBox on Kali" from "installing Kali inside VirtualBox," and mixing those paths wastes an hour.

Creating the Isolated Network: NAT Network, Not Bridge

Here is the most common failure I see in student labs: they leave the default NAT adapter, which lets VMs reach the internet through the host, or worse they bridge to the physical NIC, which puts their vulnerable targets on the same network as their roommate's laptop. We need something tighter.

In VirtualBox, navigate to File → Preferences → Network → NAT Networks. Click the plus icon to create a new NAT Network. Name it Wintermute-Isolated. Do not attach a DHCP server if you want static control, but DHCP is acceptable for beginners — just note what addresses it hands out. The critical setting: ensure this network has no route to your production network. The NAT Network mode gives VMs outbound internet access through the host's connection while keeping them on a private segment. For true air-gap practice, you can disable the NAT Network's gateway entirely after initial updates, but that is an advanced variation.

Why this matters: A bridge adapter makes your vulnerable VM appear as a physical machine on your local network. Anyone else on that coffee shop WiFi can scan it. NAT Network keeps the traffic inside VirtualBox's virtual switch unless you explicitly punch holes.

Kali Linux: The Attacker Workstation

Kali Linux is a rolling Debian-based distribution maintained for security testing. It is supported on amd64 (64-bit) platforms. You have two paths: download the pre-built VMware image (naming format kali-linux-YYYY.N-vmware-ARCH, though version numbers change continuously as a rolling distribution) or install from ISO into a fresh guest VM. For VirtualBox, the ISO route is cleaner — the VMware images work but need format conversion that confuses beginners.

Create a new VM in VirtualBox: type Linux, version Debian 64-bit. Memory allocation depends on your host; 4 GB is workable, 8 GB is comfortable. The documentation notes requirements vary depending on what you would like to install and your setup, so do not panic if your laptop only has 16 GB total — Kali will run lean if you avoid the heavier GUI options.

Boot the ISO, select graphical install, and proceed through disk partitioning. Installing Kali Linux on hard disk wipes existing data; backup to external media is recommended before any OS installation, even in a VM (snapshot corruption happens). When you reach the network configuration screen, attach the VM to Wintermute-Isolated.

After installation, install VirtualBox Guest Additions for shared clipboard and dynamic resizing. The exact procedure varies by VirtualBox version — mount the Guest Additions ISO from VirtualBox's Devices menu, run the installer, and reboot. If the kernel headers are missing, install them from Kali's repositories (which use Debian's current stable version structure alongside Kali's own).

Set a static IP for consistency. Edit /etc/network/interfaces or use NetworkManager, depending on your Kali version. We will use 192.0.2.10 for the attacker workstation — this is from the TEST-NET-1 documentation range, guaranteed not to route on the real internet.

Verify connectivity before proceeding:

ip addr show
# illustrative output — verify on your target: look for 192.0.2.10/24 on your primary interface ping -c 3 192.0.2.1
# illustrative output — verify on your target: replies from the NAT Network gateway

The First Snapshot: Pre-Engagement Baseline

Before you touch a target, before you run a single scan, snapshot the Kali VM. In VirtualBox, Machine → Take Snapshot. Name it 01-CLEAN-INSTALL. This is your time machine. I have seen students skip this, run a destructive exploit they do not understand, corrupt their only working environment, and spend three days rebuilding instead of learning. The snapshot is thirty seconds now versus three hours later.

Our snapshot strategy for Wintermute has three gates:

Pre-engagement: Clean install, all updates applied, tools verified.
Pre-exploit: Immediately before running any attack code against a target.
Post-cleanup: After documenting results, before moving to a new attack category.

Full rollback means restoring to 01-CLEAN-INSTALL and walking forward, or restoring to 02-PRE-EXPLOIT before each new technique. I keep a spreadsheet of snapshot names and what I was testing — memory is fallible at 2 AM.

Metasploitable2: The Deliberately Vulnerable Target

Metasploitable 2 is an intentionally vulnerable Ubuntu Linux VM designed for testing common vulnerabilities. It ships with more vulnerabilities than the original Metasploitable image. Download locations include Rapid7's information page and SourceForge; the compressed file is about 800 MB. Verify your download — the sources do not provide specific checksums, so check the download page for whatever verification mechanism the current release offers.

Metasploitable 2 is compatible with VMware, VirtualBox, and other common virtualization platforms. Import the .vmdk into a new VirtualBox VM: create a Linux/Ubuntu VM, attach the existing disk image, and place it on Wintermute-Isolated.

⚠️ Authorized, defensive use only. Metasploitable 2 should never be exposed to a hostile network. This VM exists to be broken; exposing it to the internet or your university network is negligence, not education.

Boot Metasploitable2. At the login prompt, the default credentials are msfadmin / msfadmin. You will see the prompt msfadmin@metasploitable:~$. Check the network configuration:

ifconfig
# illustrative output — verify on your target: look for eth0 with an IP in your NAT Network range

Metasploitable 2's network interfaces are bound to NAT and Host-only network adapters by default in some distributions of the image. If ifconfig shows an unexpected address, adjust in VirtualBox's network settings. We want this VM on Wintermute-Isolated with a static address in our documentation range. The sources do not establish specific IP addresses for Metasploitable2, so configure what matches your plan — I use 192.0.2.20 in my labs for consistency with the running scenario.

Install the packages needed for certain exercises:

sudo apt-get update
sudo apt-get install rpcbind nfs-common

Snapshot this VM as 01-METASPLOITABLE-CLEAN. You will corrupt this machine intentionally; the snapshot lets you do it repeatedly.

DVWA: The Web Application Target

DVWA (Damn Vulnerable Web Application) is a public GitHub repository by digininja. Its goals include helping security professionals test skills legally, aiding web developers in securing applications, and assisting with education around web application security — though the source confidence on these goals is low, the educational value is well-established in practice.

Create a third VM on Wintermute-Isolated. Install a lightweight Linux distribution — Debian or Ubuntu Server — and configure Apache, PHP, and MySQL. Clone the DVWA repository into your web root. The specific installation steps vary by release; follow the current README. Set the security level to low initially for learning, understanding that this is deliberately insecure.

In plain terms: DVWA is a broken web application you are allowed to break. It has buttons that do SQL injection on purpose. Your job is not to surprise the developer — there is no developer to surprise — but to see how the breakage happens so you recognize it in real code later.

Place DVWA on your isolated network. I use 192.0.2.30 in my labs. Snapshot as 01-DVWA-CLEAN.

External Platforms: TryHackMe and Hack The Box

Lab Wintermute is your local, fully controlled environment. Complement it with external platforms that provide their own authorization models. TryHackMe and Hack The Box offer browser-accessible or VPN-connected labs where the legal authorization is handled by the platform — you attack machines they own and explicitly permit you to test. These are not substitutes for understanding your own lab construction, but they extend your practice when you need variety beyond our three-VM setup.

The operational specifics of these platforms change regularly; check their current documentation for access methods. The key principle: never confuse their authorized targets with systems you do not own.

Verifying Isolation: The Critical Check

Before any exercise from later pages, confirm your lab cannot reach outside. From Kali (192.0.2.10):

ip route
# illustrative output — verify on your target: look for default gateway via 192.0.2.1, no other routes ping -c 3 8.8.8.8
# illustrative output — verify on your target: should fail — no route to external networks ping -c 3 google.com
# illustrative output — verify on your target: should fail — DNS resolution may also fail depending on NAT Network config

If these pings succeed, your isolation is broken. Check VirtualBox network settings: is the adapter attached to Wintermute-Isolated or to something else? Is there a second adapter enabled? Fix before proceeding.

From Metasploitable2, similarly verify it cannot reach your host's physical network or the internet. A vulnerable machine that can phone home is a machine that can be recruited into someone else's botnet.

Troubleshooting Common VirtualBox Network Issues

Symptom: VMs on the same NAT Network cannot ping each other. Cause: VirtualBox NAT Network requires explicit port forwarding for inbound connections; VM-to-VM traffic should work but sometimes needs the "cable connected" box checked in adapter settings. Fix: Shut down VMs, open VirtualBox network preferences, verify Wintermute-Isolated exists and is active. Check each VM's adapter is attached to this named network, not "NAT" (unqualified) or "Bridged."

Symptom: Kali gets no IP address. Cause: DHCP server disabled in NAT Network settings, or Guest Additions not providing proper interface support. Fix: Enable DHCP in the NAT Network, or configure static IP manually. Verify ip link show reports the interface as UP.

Symptom: Metasploitable2 boots but network unreachable. Cause: Imported .vmdk retains VMware network settings that do not map to VirtualBox adapters. Fix: Remove all network adapters in VirtualBox settings, re-add one attached to Wintermute-Isolated, boot and check ifconfig for eth0 presence.

Lab Wintermute: Ready State Checklist

Component	Address	Snapshot Name	Verified
Kali attacker workstation	192.0.2.10	01-CLEAN-INSTALL	☐
Metasploitable2 target	192.0.2.20	01-METASPLOITABLE-CLEAN	☐
DVWA web target	192.0.2.30	01-DVWA-CLEAN	☐
Isolation verified (no external route)	—	—	☐
Host-to-VM ping works	—	—	☐
VM-to-VM ping works	—	—	☐

Complete this checklist before turning to Page 5. An incomplete lab will waste your time with network mysteries instead of security concepts. I have watched students spend entire lab sessions debugging DHCP when they should have been learning port scanning. The discipline of verification is itself a security skill — production systems do not come with a "trust me" button.

Your environment is built. Your snapshots are frozen. The next page begins the actual work: reconnaissance and network mapping, understanding what an attacker sees when they look at a target they are authorized to assess.