Build your own lab
← the lab mapThree tracks, easiest first. Start where you are. Each step says what to do, why, and what not to do, and links to the official docs.
Easy: start on the laptop you already own
No new hardware. Learn the habits (isolate, snapshot, log) that every bigger lab depends on.
Budget: $0. Any laptop with 16 GB of RAM.
-
Install a hypervisor on your PC
Install VirtualBox (or any desktop hypervisor) and create one Linux VM.
Why: A VM is a safe, disposable computer. Break it, delete it, make another.
-
Isolate the lab network
Put VMs on an Internal or Host-only network so they cannot reach your home network.
Why: Targets are vulnerable on purpose. They must never be able to touch your real devices.
Avoid: Never bridge a vulnerable VM onto your home network.
-
Make snapshots a habit
Snapshot a VM when it is clean, and again before anything risky.
Why: Rolling back in seconds is what lets you experiment without fear.
-
Add an attacker and a target
Run Kali as the attacker and OWASP Juice Shop (or another deliberately vulnerable app) as the target.
Why: Offence teaches defence. Start with something designed to be broken.
-
Turn on logging
Install Sysmon on a Windows VM and look at what your attacks leave behind.
Why: Seeing the evidence is the bridge from hacking to detecting.
-
Practise somewhere guided
Work through structured rooms and labs alongside your own.
Why: Guided practice fills gaps you do not know you have.
Intermediate: a mini PC and real network design
Move from one laptop to an always-on lab with a firewall, VLANs and remote access that does not open a single port.
Budget: Roughly a mini PC or an old desktop plus a managed switch. 16 to 64 GB of RAM.
-
Install Proxmox on bare metal
Put Proxmox VE on a spare machine and move your VMs onto it.
Why: Always-on, snapshot-friendly, and containers (LXC) cost almost nothing.
-
Put a real firewall at the edge
Run OPNsense (as a VM or on its own box). The WAN plugs into it and nothing else.
Why: One choke point to write default-deny rules for everything behind it.
Avoid: Never plug the WAN into a switch port that carries a LAN VLAN, and never put a lab machine directly on the WAN.
-
Split the network into VLANs
Buy a managed switch. Create VLANs for management, trusted devices, DMZ and each lab.
Why: A compromise in one zone cannot walk into another unless the firewall allows it.
Avoid: Do not leave management (Proxmox, switch, iDRAC) on the same VLAN as the lab.
-
Get in with WireGuard or Tailscale
Publish one VPN port, or none at all with Tailscale, and administer everything through it.
Why: Anything exposed to the internet gets scanned within minutes. A VPN shrinks that to a single hardened door.
Avoid: Do not port-forward Proxmox, SSH, RDP or Git to the internet.
-
Build your first Active Directory range
Stand up a small domain with a domain controller and a couple of workstations. Microsoft publishes evaluation ISOs, or automate it with GOAD.
Why: Most real intrusions happen in AD. A throwaway domain lets you attack and defend it.
-
See everything: logging and hunting
Deploy Wazuh or Security Onion, and Velociraptor for endpoint hunting.
Why: You cannot defend what you cannot see. Attack it, then find yourself in the logs.
-
Self-host your own Git
Run Gitea behind the VPN and keep your notes, scripts and detections in it.
Why: Your research should not live only on your laptop.
Expert: a server-class lab (this one)
Many isolated ranges on one box, an air-gapped malware zoo, detections as code and AI agents. This is what the battle maps show.
Budget: A used enterprise server (mine: Dell R620, 32 cores, 250 GB DDR3, 10 TB) plus a mini PC and a spare laptop.
-
Be honest about the hardware
Old enterprise servers are cheap, powerful and loud. DDR3 ECC RAM is inexpensive, but expect high idle power draw and fan noise. Keep the iDRAC management port off every routable network and update the firmware.
Why: A lot of cores and RAM for very little money is what makes 20 containers and several ranges possible.
Avoid: Never expose the iDRAC/BMC to the internet.
-
One virtual network per range
Use Proxmox SDN or separate bridges so each range is its own island, and automate rebuilds with Ansible or Terraform.
Why: Rebuilding a range from code takes minutes, so you can run it, wreck it and reset it without effort.
-
An air-gapped malware zoo
LXC containers on an isolated VLAN with no default gateway, a fake internet (INetSim), packet capture, and golden snapshots to revert to.
Why: Run a sample, watch everything, learn from the capture, then wipe it.
Avoid: Containers share the host kernel. Keep Windows samples in full VMs, never route the zoo anywhere, and treat the host as a target.
-
Detections as code
Write Sigma rules, keep them in Git, test them against Atomic Red Team simulations, and ship them to your SIEM from CI.
Why: Detections need version control and tests just like software.
-
A DFIR pipeline
Hunt with Velociraptor, collect triage packages, and keep an evidence store apart from the systems you investigate.
Why: Cases need chain of custody and a place to work that cannot be tampered with.
-
A mobile and macOS bench
Android emulators and real devices, iOS research hardware, docker-OSX for macOS, and mitmproxy + Frida in the middle.
Why: App research needs resettable devices and full visibility of their traffic.
Avoid: Never sign test devices into personal accounts.
-
AI agents that help the analyst
Use LangChain and LangGraph to build agents that enrich alerts, pull related logs and write investigation summaries.
Why: Analysts should start from a briefing, not a raw alert. A human still makes the call.
Avoid: Log every prompt and tool call, and never let an agent take destructive action unattended.
-
Run a Tor relay safely
Run a middle relay on dedicated hardware in a DMZ, never an exit node at home.
Why: Relays help people stay private. Exit nodes carry legal and abuse risk you do not want at your front door.
Avoid: Do not run a relay on your trusted LAN or on the same box as the lab.
The never-do-this list
Never put the WAN on the LAN
The WAN cable goes to the firewall's WAN port. A WAN plugged into a LAN switch exposes everything on it.
Never port-forward admin services
Proxmox, SSH, RDP and Git belong behind a VPN.
Never give malware a route out
No default gateway. Fake the internet instead.
Never run a lab on your trusted network
Vulnerable by design means isolated by design.
Never skip snapshots and backups
Test a restore before you need one.
Never expose the BMC / iDRAC / management
Management interfaces are high-value, often outdated targets.
Want to test your own design? Open the range builder. It grades your network live and lets you attack it.