Hacking Labo's target machines run in VirtualBox on your own computer, and you attack them from there. This guide walks you, step by step, through connecting an attacker Kali Linux VM and a target machine over a host-only network (192.168.56.0/24), so you can follow along hands-on while reading the write-ups on the site. It is written for beginner-to-intermediate security learners. No prior VirtualBox or Vagrant experience is required. Follow it top to bottom and you'll end up ready to fire nmap at your first target (Levi = 192.168.56.50).
The target machines are intentionally vulnerable. Always run them on the host-only network only. If you expose them to the internet via bridged networking or port forwarding, your target becomes an attack surface for others. Read the final "Safety Notes" section before you begin.
The big picture — you build two VMs #
You are building just two virtual machines.
Your PC (Windows / macOS / Linux)
┌──────────────────────────────────────────────────────────────────┐
│ │
│ ┌───────────────────┐ host-only ┌─────────────┐ │
│ │ Kali Linux VM │ 192.168.56.0/24 │ Target VM │ │
│ │ (attacker) │◀─────────────────────────▶│ (vulnerable) │ │
│ │ 192.168.56.10 │ isolated VBox network │ 192.168.56.5X│ │
│ └───────────────────┘ (no route to internet) └─────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────┘
your workstation ─ nmap / metasploit / etc ─▶ the target- Kali VM (attacker): the machine you actually drive. It ships with
nmap,metasploit,gobuster, and more. - Target VM (vulnerable): a deliberately flawed server brought up with
vagrant up. You attack it to capture the flags. - Host-only network (192.168.56.0/24): an isolated virtual LAN that only these two VMs can talk on. It is cut off from your real home LAN and from the internet.
Targets get fixed IP addresses — they always come up on the same IP when you vagrant up.
| slug | Name | Difficulty | IP | Attack path (foothold → privesc) |
|---|---|---|---|---|
levi | Levi | easy | 192.168.56.50 | SNMP + PostgreSQL RCE → sudo systemctl (GTFOBins) |
box-01-lazyadmin | LazyAdmin | easy | 192.168.56.51 | Web command injection → SUID PATH hijack |
box-02-keyholder | KeyHolder | easy | 192.168.56.52 | SSH brute force → sudo tar (GTFOBins) |
box-03-dropzone | DropZone | easy | 192.168.56.53 | Unrestricted upload webshell → capabilities (cap_setuid) |
In the command examples below the target IP is written as 192.168.56.5X. Substitute the IP of the machine you're attacking.
What you need #
| Item | Purpose | Where to get it |
|---|---|---|
| VirtualBox 7.x | The hypervisor that runs the VMs | virtualbox.org |
| Vagrant | Brings up a target with one command | developer.hashicorp.com/vagrant |
| Kali Linux (VirtualBox image) | Your attacker box | kali.org/get-kali |
| A target machine folder | machines/<slug>/, from the factory | The machine factory repo |
The Extension Pack is NOT required. This lab uses only the host-only network, so you don't need the VirtualBox Extension Pack (separately licensed) that adds USB 3.0, RDP, PXE, etc.
Host (your PC) prerequisites:
- Memory: each target uses about 1 GB and Kali wants 2–4 GB. Since you run both at once, 4 GB free is recommended (8 GB is comfortable).
- Enable CPU virtualization (VT-x / AMD-V) in the BIOS/UEFI. Without it, VMs won't start or will be painfully slow. Intel: VT-x. AMD: AMD-V (SVM Mode). On Windows, check Task Manager → Performance → CPU → "Virtualization: Enabled." Hyper-V / WSL2 / Memory Integrity (Core Isolation) can conflict (see below).
- Disk: roughly 40 GB free for Kali plus a few targets is a safe margin.
After installing, verify the versions first.
VBoxManage --version
vagrant --versionOn Windows, if VBoxManage is "not found," it just isn't on your PATH yet (see Troubleshooting).
Preparing the Kali VM #
You need a Kali box for the attacker side. Importing the official VirtualBox image is fastest.
- Option A (recommended): download the Kali VirtualBox image (
.7zor.ova), extract it, then double-click the.vboxfile (or use File → Import Appliance in VirtualBox). Default login iskali/kali(change the password after your first login). - Option B: build a new VM from the Kali ISO and install it. It takes longer but teaches you the internals.
Either way, the crucial part is adding the host-only adapter below. If Kali is not on the same host-only network as the targets, they simply can't talk.
VBoxManage list hostonlyifs to check; if none, VBoxManage hostonlyif create. In practice the first vagrant up auto-creates it, so if you bring up the target first you can leave this to Vagrant.VirtualBox Host-Only Ethernet Adapter the targets use. Leave Adapter 1 on NAT so Kali can reach the internet to update tools.ip a | grep 192.168.56. DHCP should hand it a 192.168.56.x. To pin it: sudo ip addr add 192.168.56.10/24 dev eth1 (don't collide with targets at .50–.53).The VirtualBox 7.x host-only allowed-range trap #
Starting with 6.1.28 / 7.x, VirtualBox tightened security by restricting the IPs you may assign to a host-only network to 192.168.56.0/21 by default. If you try to put a host-only IP outside that range, vagrant up fails with:
The IP address configured for the host-only network is not within the allowed ranges.This lab's targets live at 192.168.56.50+, which falls inside the default 192.168.56.0/21 (192.168.56.0–192.168.63.255), so it normally works with no extra configuration. You only need the allowed-range file for a custom machine that uses an out-of-range IP (e.g. 10.0.0.x).
Only in that case, add the following single line to the allowed-ranges file (Windows: %PROGRAMDATA%\VirtualBox\networks.conf / Linux & macOS: /etc/vbox/networks.conf; create it if it doesn't exist). Restart VirtualBox afterward, then re-run vagrant up.
* 192.168.56.0/21Starting a target machine #
Each target folder machines/<slug>/ from the factory contains a Vagrantfile. Just run vagrant up inside that folder and the target comes up on the host-only network.
cd machines/levi # into the folder of the machine you want to attack
vagrant up # the first run downloads the base box (bento/ubuntu-22.04)On Windows (PowerShell), if you'd rather not cd into the folder, point Vagrant at it with $env:VAGRANT_CWD. The first run downloads the bento/ubuntu-22.04 base box and is slow; later runs use the cache and are fast. Once it's up, the target listens on the fixed IP from its Vagrantfile (Levi = 192.168.56.50).
Check state, and stop / reset / destroy:
| Goal | Command | Notes |
|---|---|---|
| Check state | vagrant status | up / poweroff / not created |
| Stop (resume later) | vagrant halt | vagrant up resumes it |
| Reset to pristine | vagrant destroy -f && vagrant up | Throw away flags/dirty state and rebuild cleanly |
| Destroy completely | vagrant destroy -f | Deletes the VM (the base box stays) |
If you break the machine mid-attack, vagrant destroy -f && vagrant up gives you a brand-new one every time. Flags are generated randomly per boot (unless you pass a token), so rebuilding changes their values.
Starting the attack #
The core loop is: scan the target from Kali, then follow along with the write-up on the site.
export TARGET=192.168.56.50 # stashing the IP reduces misfires
nmap -sV "$TARGET" # service/version scan (TCP)
sudo nmap -sU -p 161 "$TARGET" # some targets center on UDP (e.g. Levi's SNMP)
Once you have recon results, open the machine's write-up on this site (machines/<slug>) and work through foothold (initial access) → privesc (privilege escalation) in order. For Levi, the chain is "identify services via SNMP → PostgreSQL default credentials → RCE via COPY FROM PROGRAM → abuse sudo systemctl using the GTFOBins technique to get root." The goal is capturing both flags: user.txt (a normal user) and root.txt (root).
Every machine ships with solve.sh (an automated reproduction of the attack) as its "proof it's solvable." Use it to check your answer when you're truly stuck, but try to solve it yourself first while reading the write-up.
Troubleshooting #
| Symptom | Cause and fix |
|---|---|
| Target won't ping / scans return nothing | Most common: Kali's host-only adapter not set up. If ip a | grep 192.168.56 is empty, the second NIC isn't host-only or it got no DHCP lease. Verify Kali and the target use the same host-only adapter. A target's OS firewall may drop ICMP — even if ping fails, you can attack if nmap shows open ports. |
| VMs won't start / VT-x disabled | Enable virtualization in BIOS/UEFI. On Windows, if Hyper-V / WSL2 / Memory Integrity is on, VirtualBox can't grab VT-x. From an admin PowerShell: bcdedit /set hypervisorlaunchtype off, then reboot (revert with auto). |
vagrant up can't find VBoxManage | VirtualBox just isn't on PATH. For the current session: $env:PATH += ";C:\Program Files\Oracle\VirtualBox". To make it permanent, add it to the Windows Path variable. |
| Stops with an IP-range error | Add * 192.168.56.0/21 to networks.conf (Section 04) and restart VirtualBox. With this lab's default IPs (.50–.53) you shouldn't need it. |
| Base box download is slow / fails | The first run fetches bento/ubuntu-22.04. A flaky connection can interrupt it. Clean up with vagrant destroy -f, then re-run on a better connection. |
Safety notes (most important) #
- Use the host-only network only. Do not expose target VMs to the internet or your home LAN via bridged networking, NAT port forwarding, a DMZ, or similar. Opening a vulnerable server to the outside can get your lab taken over by a third party and used as a staging point. The target's NIC is pinned to host-only in the Vagrantfile — do not edit the config to expose it externally.
- Keep attacks inside your own lab. Do not use the techniques you learn here (scanning, exploits, brute force, etc.) against any third-party system, network, or service you don't have permission to test. Unauthorized access is a crime in most countries.
- Kali should only attack the targets at 192.168.56.5X. Double-check the destination IP in nmap and exploits every time so you don't accidentally fire at your own home LAN, router, or a cloud host. Stashing the IP in an environment variable reduces misfires.
- Clean up when done.
vagrant halttargets you're not using, andvagrant destroy -fthe ones you no longer need. Not leaving vulnerable VMs running unattended is part of staying safe.
This lab exists so you can develop an attacker's mindset inside a safe sandbox. As long as you stay inside the sandbox, experiment and learn all you want — have fun, and be responsible.
