Build an Isolated Attack Range: Kali + a Target VM, Walled Off
0 / 7 steps
The goal
Build a small network of two machines — an attacker (Kali) and a target — that can reach each other and nothing else, so you can practise real offensive tools with nothing of yours in range. You will make a walled-off network, stand up both VMs on it, prove the walls hold by failing to reach the internet on purpose, snapshot everything clean, and finish with your first authorised scan of your own target. This is the range every attack lab on StashGrid runs inside.
This range is the safe place — keep everything inside it. The whole build is about isolation: VMs that talk to each other and to nothing else. Only ever point tools at the target you built here. Pointing them at a machine, site or network you do not own is not practice — it is illegal, whatever your intent. If you want a legal target beyond this range, use one that publishes permission to be scanned, like the ones in Lab 01.
Steps
01Pick your virtualiser
You need software that runs whole machines inside your machine. Either of these is free and fine:
- VirtualBox (Oracle, free, Windows/Mac/Linux) — the no-cost default, and what the commands below assume.
- VMware Workstation (now free for personal use) — smoother on Windows, slightly nicer networking UI. Everything here maps across; the menu names differ.
Install one and reboot if it asks. On Windows you may have to turn off conflicting features or enable virtualisation in the BIOS — the installer will tell you which.
This is the boring lab. It is also the one that means every lab after it can go wrong safely. Do it once, properly, and never think about it again. — Nyx
02Make a walled-off network
The whole point is a network your VMs can use to reach each other and nothing else — not your home LAN, not the internet. In VirtualBox that is a Host-Only network (or, for total isolation, Internal). Create one:
$ VBoxManage hostonlyif create $ VBoxManage list hostonlyifs
Note the interface name it prints (for example vboxnet0) and the subnet it uses, usually 192.168.56.0/24. Both VMs will attach only to this. In VMware the equivalent is a custom Host-only VMnet in the Virtual Network Editor.
Why this matters. Host-only lets the VMs talk to each other and to your host, but gives them no route out. “Internal” is stricter still — not even the host. Either way, anything noisy you do later stays in the box. The isolation is the safety rail for everything else on this site.
03Build the attacker VM (Kali)
Kali is a Linux build that ships with the common security tools already installed, so you are not chasing packages. Download the official VirtualBox/VMware image from kali.org/get-kali (take the prebuilt VM, not the installer ISO — it is faster), import it, and before first boot set its network adapter to the host-only network from step 2.
Boot it, log in, and confirm it landed on the isolated subnet:
$ ip -4 addr show | grep inet
You want an address on your host-only range, for example 192.168.56.10. If it instead shows a 10.x or your home 192.168.1.x address, the adapter is still on NAT or bridged — fix it in the VM’s network settings before going on.
Verify the Kali image against the checksum on kali.org before you import it. You are about to trust this box with your attacks; start by trusting the download. — Nyx
04Add a target to practise against
An attacker VM with nothing to attack is half a range. Add a machine that is meant to be broken into, on the same host-only network:
- Metasploitable 2 — a deliberately vulnerable Linux VM, the classic first target. Import it, set its adapter to host-only.
- or a small vulnerable web app in Docker (OWASP Juice Shop, DVWA) if you would rather keep the target light — see the Juice Shop lab.
Boot the target and find its address the same way (ip addr, or check its login banner). Write it down — that is the only thing you are allowed to point tools at.
Why this matters. A fixed, known, isolated target is what makes practice honest. You always know what you are hitting, nothing real is in range, and if you break the target you restore a snapshot instead of rebuilding a machine.
05Prove the walls hold
Before you trust the range, test both directions from the Kali VM. First, confirm it cannot reach the internet:
$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. --- 8.8.8.8 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2031ms
100% packet loss is the result you want. No route out means nothing you do can leak onto the real internet or your home network. Now confirm it can reach the target (swap in your target’s address):
$ ping -c 3 192.168.56.20
That one should reply. Reaches the target, cannot reach the world — that is a range.
06Snapshot everything
Take a snapshot of each VM now, while it is clean. A snapshot is a saved state you can roll back to in seconds.
$ VBoxManage snapshot "Kali" take clean-base --description "fresh, isolated" $ VBoxManage snapshot "Metasploitable2" take clean-base
(In the GUI: the VM’s Snapshots view → Take.) Now when a lab leaves the target wrecked, or you install something that breaks Kali, you restore clean-base and you are back to this exact moment.
The snapshot is what turns “I bricked my lab” into a thirty-second reset. Take one before every messy lab, not just this once. — Nyx
07Your first authorised scan
The range is live, so take the first real action: from Kali, scan your own target to see what it exposes. This is the opening move of almost every engagement, and here you have standing permission because you own both ends.
$ nmap -sV 192.168.56.20
You will get a list of open ports and the service on each — the target’s attack surface, which is where every later lab starts. If nmap is missing, sudo apt install nmap. Read the output against the Common Ports cheat sheet.
Why this matters. Everything offensive you do from here — the OverTheWire labs, the web-app and AI-agent labs, the MCP series — happens on exactly this footing: a target you own, on a network with no way out, that you can reset with a snapshot. Build the range once; it is the ground every attack lab stands on.
Isolation checklist. Before you run any offensive lab in this range, tick all seven:
- Every VM’s network adapter says Host-only (or Internal), not NAT or Bridged.
- Kali has an address on the host-only range, for example 192.168.56.10.
- ping -c 3 8.8.8.8 from Kali shows 100% packet loss.
- The same ping from the target also fails, so the target can’t call home either.
- Kali can ping the target’s address and gets replies.
- Each VM has a clean-base snapshot you can restore.
- Shared folders, shared clipboard and drag-and-drop are switched off on the target.
If any line fails, fix it before you go on. The range is only safe while all seven hold.
What you learned
- The difference between NAT, bridged, host-only and internal networking — and why host-only is the safe one
- How to stand up an attacker VM (Kali) and a deliberately vulnerable target on one isolated network
- How to prove isolation: a ping to the internet that is supposed to fail (100% loss)
- Snapshots turn “I broke my lab” into a thirty-second reset
- The footing every offensive lab needs: a target you own, no route out, a clean snapshot to roll back to
Put it on your resume. Built an isolated two-VM attack range (Kali plus a target) with no internet route, verified the isolation, and ran an authorised scan. Change it to match what you actually did.
Tried it? Tell us
Nova built this lab from Steven’s ideas, and most StashGrid labs haven’t had a full run yet. If a step broke, behaved differently for you, or you know a better way, tell us. Ideas for the next lab are welcome too — no promises on timing.
Go deeper
- Lab 00 — Set up your lab — the longer first-time Kali walkthrough
- Lab 01 — Your first scan — nmap in depth, against a host that invites it
- Juice Shop Docker lab — a lightweight vulnerable web target for the range
- Common Ports cheat sheet — reading what your first scan returns
Original walkthrough. The networking model (host-only vs internal vs NAT vs bridged), the VirtualBox VBoxManage commands, and the isolation test were checked against Oracle’s VirtualBox manual and Kali’s own install docs on 16 October 2026, and the host-only subnet shown (192.168.56.0/24) is VirtualBox’s default. The ping-with-100%-loss output is the expected result of an isolated adapter, shown as the target state to confirm rather than a capture from your machine, since addresses vary. Kali and Metasploitable 2 are named as the common choices; download and verify each from its official source. If a step differs on your setup, tell me and I will fix it.