hacking track
week 11 · day 2

Building a Professional Lab

VMs, snapshots, isolated networks, and a workflow you trust

Easy 90 min 180 xp
After this you can
  • Explain why a hacker never practices without a lab, and what 'isolated' really means
  • Stand up an attacker VM and a victim VM on a private network
  • Use snapshots so a broken box is a 10-second reset, not a lost afternoon
  • Confirm, with your own eyes, that your lab cannot reach the internet

Why the lab comes first

Every skill in this track is practiced by *breaking things*: overflowing buffers, injecting payloads, escalating to root. You cannot do that safely on your daily laptop, and you must never do it on someone else's machine. So before any hacking, you build a place designed to be attacked — a set of virtual machines that talk to each other and to nothing else.

Think of it as a sealed room. Inside, you can be as aggressive as you like: the most destructive exploit in the world can only touch the walls you built. That sealing is the single most important thing in this lesson. Get it wrong and a "harmless test" leaks onto your real network; get it right and you can make every mistake fearlessly.

Key idea
A lab is defined by two properties: it is disposable (any machine can be reset to a known-good state instantly) and isolated (its traffic physically cannot leave the sandbox). Disposable makes you brave. Isolated makes you safe. Everything else is detail.

The pieces

A minimal professional lab has three parts:

  • A hypervisor — software that runs virtual machines on your real computer. VirtualBox (free, cross-platform) or VMware Workstation/Fusion. Either is fine; examples below use VirtualBox terms.
  • An attacker VM — a Linux distro loaded with offensive tooling. Kali Linux or Parrot OS. It comes with nmap, Burp Suite, gdb, Wireshark, Metasploit, and hundreds more, so you don't assemble a toolkit by hand.
  • One or more victim VMs — intentionally vulnerable machines you attack. Downloadable images from VulnHub, retired HackTheBox boxes, or Metasploitable.

They all sit on one private virtual network that the hypervisor creates. Your real laptop is the landlord; the VMs are tenants who can only talk to each other.

The network is the whole game

Hypervisors offer several networking modes, and choosing the wrong one is how people accidentally scan their neighbour's router. Know these three:

ModeWhat it connectsUse it for
NATVM → internet (through your host), but VMs can't easily reach each otherDownloading updates/tools onto a VM
Host-onlyVMs ↔ each other and ↔ your host, but NOT the internetThe attack network — this is the safe one
BridgedVM directly onto your real LAN, like a physical deviceAlmost never in a lab — this is the dangerous one
Careful
Never put a victim VM on Bridged. Bridged mode places the machine directly on your home/office network with its own address, reachable by (and reaching) every real device around you — and a deliberately-vulnerable box on your real LAN is an open door for anyone. The attack network is Host-only. Use NAT only, temporarily, to install tools, then switch back.

Standing it up

The exact clicks vary by hypervisor, but the shape is always: create a host-only network, then attach both VMs to it. In VirtualBox you can do it from the GUI (File → Host Network Manager) or the CLI:

create an isolated network and attach VMs (VirtualBox CLI)sh
1# create a host-only network (gives you something like 192.168.56.0/24)
2VBoxManage hostonlyif create
3
4# point each VM's first adapter at that host-only network
5VBoxManage modifyvm "Kali" --nic1 hostonly --hostonlyadapter1 vboxnet0
6VBoxManage modifyvm "Metasploitable" --nic1 hostonly --hostonlyadapter1 vboxnet0
7
8# start them
9VBoxManage startvm "Kali"
10VBoxManage startvm "Metasploitable" --type headless

Reading that

`hostonlyif create` makes a new virtual switch that only the host and its guests can see. It hands out a private subnet — commonly 192.168.56.0/24 — meaning addresses 192.168.56.1 through .254, none of which route to the internet.

`modifyvm ... --nic1 hostonly --hostonlyadapter1 vboxnet0` takes network card #1 of the VM and plugs it into that switch (vboxnet0). Do this for *every* machine in the lab and they share one sealed segment.

Now the most important habit in the whole lesson: prove the seal. Don't assume it — check it.

inside the attacker VM: confirm isolationsh
1ip addr show # find your address on the lab net, e.g. 192.168.56.101
2ping -c1 192.168.56.102 # the victim should answer -> isolation OK, they can see each other
3ping -c1 8.8.8.8 # the internet should NOT answer on a host-only net
4 # 100% packet loss here is the RESULT YOU WANT
If the victim answers and 8.8.8.8 times out, your room is sealed. That "100% packet loss" to the internet is not a failure — it is the proof that anything you do next stays inside. Screenshot it, so future-you doesn't second-guess the setup.

Snapshots: your undo button

You will destroy these machines constantly — a bad exploit corrupts the target, a privesc trick bricks a service, you delete the wrong file. Without snapshots that means rebuilding from an ISO. With them it means a ten-second rollback.

A snapshot freezes a VM's entire disk and memory at a moment in time. Take one the instant a machine is installed, clean, and updated ("baseline"). Take another before you try something risky. Roll back whenever you want the old state.

snapshot workflowsh
1VBoxManage snapshot "Metasploitable" take "baseline-clean" # right after setup
2# ... you attack, escalate, break everything ...
3VBoxManage snapshot "Metasploitable" restore "baseline-clean" # back to pristine in seconds
4VBoxManage snapshot "Metasploitable" list # see what you've saved

Adopt one rule and it will save you dozens of hours: snapshot the target before every engagement, restore it after. A clean starting state means your results are repeatable and your failures cost nothing.

That is the entire foundation. From here on, every lesson assumes you have a sealed room, an armed attacker box, at least one victim, and the reflex to snapshot before you strike.

finished reading?
Your task, you write the code

Seal the room

Build the lab. Install a hypervisor, import a Kali (or Parrot) attacker VM and one victim VM (Metasploitable 2 is the easiest first target). Put both on a host-only network. Then do the part that matters: from Kali, prove the victim is reachable and the internet is not, and take a 'baseline-clean' snapshot of the victim. Keep a lab.md noting each VM's IP, the network name, and the two ping results.

deliverable: lab.md (VM addresses, network, and your isolation proof)
build & run
$ ip addr show # your lab IP on the host-only net
$ ping -c1 <victim-ip> # expect replies
$ ping -c1 8.8.8.8 # expect 100% packet loss
$ VBoxManage snapshot "<victim>" take baseline-clean
self-review before running
  • Both VMs are on host-only, not bridged
  • Kali can ping the victim; neither can reach 8.8.8.8
  • A 'baseline-clean' snapshot of the victim exists and you know how to restore it
  • lab.md records the IPs so you never have to rediscover them
stretchAdd a second victim (a retired HackTheBox box or a VulnHub image) to the same network. Confirm all three machines see each other but none reach the internet — you now have a small network to pivot through later in the track.

Self-check

01Which networking mode is correct for the attack network between your VMs?
02You ping 8.8.8.8 from a lab VM and get 100% packet loss. This means:
03What problem do snapshots solve?
04The two defining properties of a good lab are that it is:
0/4 correct · 0/4 checked