Building a Practice Lab

By now you have heard the rule enough times that it should feel automatic: you may only attack systems you own or have explicit, written permission to test. Running a port scanner, an exploit, or a password cracker against a machine you do not control is not "practice" — in most places it is a crime, and good intentions are not a defense.

That rule sounds like it leaves you nowhere to learn. It does not. The answer is to build a lab: a small, self-contained environment of virtual machines running on your own computer, where you own every host on the network. Inside that boundary you can scan, exploit, escalate, pivot, and crack to your heart's content, because the only systems involved are yours. The lab turns "you may only attack what you own" from a restriction into a workshop.

A practice lab is just a handful of virtual machines on an isolated virtual network, all running on a single physical computer. Four pieces make up the whole thing:

• A hypervisor — the software that runs virtual machines on your host. VirtualBox is free, open-source, and cross-platform, which makes it the usual starting point. VMware Workstation (Windows/Linux) and VMware Fusion (macOS) are popular commercial options, and most operating systems also ship a built-in option — Hyper-V on Windows, KVM on Linux. Any of them will do; pick one and stick with it.
• An attacker VM — the machine you launch attacks from. Kali Linux and Parrot OS are security-focused distributions that come preloaded with the scanning, exploitation, and password tools that later phases assume you already have. Starting from one of these saves you from installing dozens of tools by hand.
• One or more target VMs — the machines you attack. These are deliberately vulnerable systems, purpose-built to be broken into so you have something safe to practice on (covered in section 03).
• An isolated virtual network — the wiring that lets your attacker VM reach your targets and nothing else. This is the single most important safety control in the whole lab, and it gets its own section next.

A lab full of intentionally broken machines is useful precisely because those machines are insecure — which is also exactly why you must keep them sealed off. These are the rules that stop your lab from becoming a liability:

• Use a host-only or internal network. Hypervisors let you choose how a VM connects. A host-only network lets your attacker VM and targets talk to each other (and to your host), but gives them no route to the internet or your home/work LAN. An internal network is even tighter, isolating the VMs from everything including the host. Either one keeps the lab in a sealed bubble.
• Never bridge a vulnerable VM to a real network. A bridged adapter puts a VM directly on your physical network as if it were another device on the LAN. Doing that to a deliberately vulnerable machine exposes a known-broken host to your real network — and to anything that can reach it. Do not do this with target VMs.
• Snapshot before every session. A snapshot freezes a VM's exact state so you can roll back to it instantly. Take one before you start, and you can revert a target the moment you have rooted it, corrupted it, or otherwise broken it — back to a clean slate in seconds, ready to try the attack again.
• Treat vulnerable VMs as hostile. An intentionally vulnerable machine is, by design, an insecure machine. Assume it could be compromised by something other than you. Keep it isolated, do not store anything sensitive on it, and never reuse it for real work.

You do not have to build vulnerable machines yourself — an entire ecosystem exists to give you safe things to attack. Some are VMs you download and run inside your own lab; others are hosted online ranges that are legal to attack by design, because the owners built them expressly for you to break into. The key idea is the same across all of them: these are explicitly authorized targets, and that authorization is exactly what makes practicing on them safe.

Notice the two categories. Downloadable targets — Metasploitable, DVWA, Juice Shop, WebGoat, VulnHub — run inside the isolated lab you built in the last two sections, so isolation rules apply. Hosted ranges — TryHackMe, Hack The Box, PortSwigger, OverTheWire — you connect to over the internet, and they are safe to attack only because the platform authorizes it. Both categories share the one principle that runs through this entire track: practice only against targets you own or have been explicitly given permission to attack.

You do not need the whole ecosystem to start — you need one attacker and one target on an isolated network. Here is the shortest path from nothing to a working lab:

• 1. Install a hypervisor. VirtualBox is the easy free choice; download it and install it on your host.
• 2. Import Kali. Grab the prebuilt Kali Linux VM image and import it into the hypervisor. This is your attacker.
• 3. Add Metasploitable on a host-only network. Download Metasploitable 2, add it as a second VM, and put both machines on the same host-only (or internal) network — not bridged, not NAT to the internet.
• 4. Snapshot both VMs. Take a clean snapshot of each so you can revert after any session.
• 5. Confirm the wiring. From Kali, verify you can reach the Metasploitable target (a quick ping or a port scan) and that you cannot reach the internet. If Kali can ping the target but not the outside world, your isolation is correct.

From here, the rest of the Offensive Security track unfolds against the lab you just built. The next phase begins where every engagement begins: reconnaissance — learning everything you can about a target before you ever send it a packet. Spin up the lab, and let's get started.