How to build a safe home security lab

The safest useful first build is a Kali VM and OWASP Juice Shop on a host-only network. And wait to buy a mini PC until you know the exercise those two machines will run.

Most home labs fail before the first scan because the owner bought hardware instead of choosing a question. A modest host with one isolated target can teach more than an expensive rack of VMs you spend the weekend repairing.

This guide takes you through that first weekend. Start by choosing the skill. Size the host, isolate the network, and verify the lab. Then extend it toward offensive, defensive, or malware-analysis work.

In this article

• Choose the skill before you choose the machine
• The smallest host that will not make you hate virtualization
• Build the network so a mistake stays inside the lab
• Build Kali and one target over your first weekend
• Snapshots, permissions, and notes are part of the lab
• Add monitoring when you want to learn detection alongside exploitation
• Malware analysis is a different lab, not the next target VM
• Move to Proxmox only when the current setup is the constraint

Choose the skill before you choose the machine

A home security lab can serve four different jobs:

• Offensive practice uses Kali or Parrot, reconnaissance tools, web proxies, and vulnerable targets.
• Blue-team practice needs logs, generated attack traffic, endpoint visibility, and network telemetry.
• Malware analysis requires a dedicated detonation environment and much stricter containment.
• General security research may focus on DNS, VPNs, hardening, network controls, or infrastructure experiments.

Lance Grover’s home lab guide makes the sensible argument that almost nobody should build all four simultaneously. Pick one question first.

For this guide, ask yourself: can you discover and document a web vulnerability safely? The worked build uses Kali and OWASP Juice Shop. You’ll finish by discovering and documenting one service, preserving the evidence, restoring the baseline, and writing a remediation note.

Your certification sets the emphasis. For OSCP, spend the weekend on enumeration, exploitation, and reporting. For CEH v13, focus on web testing and vulnerability discovery. For SOC work, keep the attacker and target, then add telemetry later.

The Ethical Hacking Institute describes a lab as a place to practise the full path from reconnaissance to reporting. That is the right mental model. Kali booting is the beginning, not the achievement.

The smallest host that will not make you hate virtualization

For this build, prioritize RAM: 16GB is workable, and 32GB is comfortable. Eight gigabytes is a bootable minimum, not a recommendation I’d give a beginner.

Grover’s hardware ranges put a repurposed business desktop at roughly $60–150, a mini PC at $250–400, and a dedicated hypervisor host at $500 or more. Those figures cover the host, not every part of the lab.

Host level	RAM target	Best use	Approximate host cost
Cheapest credible start	16GB	Kali plus one light target	$60–150
Comfortable starter host	32GB	Kali, Windows, several targets, or occasional monitoring	$250–400
Dedicated lab host	64GB+	Several always-on roles and repeatable infrastructure	$500+

A used OptiPlex or EliteDesk is often enough for the first tier. A mini PC is a compact alternative. For storage, 256GB can hold a minimal lab; 512GB gives a more comfortable working margin, while a larger drive becomes useful when you keep several Windows images, snapshots, or monitoring data.

The koushikos lab guide lists 8GB RAM and a 256GB SSD as minimum hardware, with 16GB or more and a 512GB NVMe drive in its recommended configuration. The Ethical Hacking Institute similarly puts 16GB at the minimum for two or three concurrent VMs and recommends 32GB or more.

Those figures describe different workloads. Sixteen gigabytes is reasonable for Kali and one light target. Add Windows, Ghidra, or a monitoring VM and memory pressure arrives quickly. Grover describes running Windows, Kali, and Ghidra on 16GB before the system failed under load. His advice is simple: “buy the RAM you think you’ll need, then buy more.”

No one can give you a guaranteed VM count from RAM alone; hypervisor overhead, host OS, target images, and monitoring workload decide that. Measure memory pressure on your machine before buying more hardware.

If you already have a 16GB computer and free hypervisor software, the incremental cost can be zero. Buying a used 16GB business desktop puts the realistic hardware spend around $60–150. The $520–790 figures in the koushikos guide describe a fuller setup than the minimum first-weekend build.

Build the network so a mistake stays inside the lab

“Use a VLAN” is lazy advice for a first weekend; a host-only network is easier to verify. Install vulnerable systems only after checking every virtual adapter.

The starter topology is:

Host machine connects to an isolated virtual network with the Kali attacker VM and Juice Shop target

Host-only networking connects the host and participating VMs without giving them a normal internet path. Internal networking connects the VMs to one another while excluding the host. NAT gives a VM a route to the internet; use it only for controlled updates and remove it from vulnerable targets afterward.

A bridged adapter puts the VM directly on the same physical network as your household devices. Do not bridge vulnerable VMs to your home LAN. One accidental bridged adapter can put the lab on your home network.

Avoid overlapping the lab subnet with the home network. Identical private ranges make routing confusing precisely when you need to know where traffic is going.

Grover’s smart-TV and thermostat examples make another useful point: DNS filtering is not isolation. His smart TV bypassed Pi-hole with hardcoded 8.8.8.8, and his thermostat made outbound connections to 23 external IP addresses. Controls that depend on a device cooperating are weaker than a network boundary.

Docker needs the same caution. Containers share the host kernel, so containerised targets deserve strict isolation from the host and home network. For this first build, a target VM is easier to reason about and easier to restore.

Build Kali and one target over your first weekend

Use this Friday-to-Sunday plan as an approximate schedule. The timing depends on your downloads, host hardware, and target installation method.

Install and isolate the lab on Friday

VirtualBox is an approachable desktop default. VMware Workstation or Player offers another mature desktop experience, and Hyper-V fits naturally on Windows hosts. Proxmox can wait.

Install your chosen hypervisor. In VirtualBox, open Tools, then Network Manager, then Host-only Networks. Create one host-only network and leave DHCP enabled unless you have a reason to manage addresses manually. Other hypervisors use different labels. You need a private virtual network with no bridged connection.

If the hypervisor reports that VT-x or AMD-V is unavailable, check BIOS or UEFI before troubleshooting the VMs.

Create two machines:

• Kali: one host-only adapter; add NAT only while updating.
• Juice Shop: one host-only adapter.
• Host: access to the host-only network for administration.

Do not give every VM every adapter.

Build the attacker and target on Saturday

Install Kali Linux as the attacker VM. Allocate 4–8GB of RAM if the host can spare it, while leaving enough for the host operating system. Parrot is a reasonable alternative, but this worked example uses Kali.

For Juice Shop, use a prebuilt VM image if one is available from the target’s distribution source. Otherwise run Juice Shop inside a small Linux VM whose only network adapter is host-only. Do not run the target directly on your household network. If you use a container, keep the container and its host inside the same isolated lab boundary.

A different target changes the exercise. DVWA and WebGoat suit web testing. Metasploitable 2 covers broader introductory exploitation. VulnHub images offer other deliberately vulnerable systems. These targets are not interchangeable.

Use NAT temporarily for updates, then disconnect it from Juice Shop.

Verify, test, and report on Sunday

Inspect every VM’s adapter mode in the hypervisor. You have a passing setup when:

• Kali can ping or connect to the target service over the lab network.
• The target has one adapter, a lab-range address, and no default route.
• The host LAN cannot reach the target address.
• No VM has a bridged adapter.

From Kali, inspect the address and route table:

ip addr
ip route
ping -c 3 <target-ip>

Identify the host-only network from the address shown by ip addr and the route shown by ip route. For example, if Kali has 192.168.56.10/24, the isolated lab range is 192.168.56.0/24. Use your actual range, and scan only that isolated range:

nmap -sn 192.168.56.0/24
nmap -sV -p- <target-ip>

The first scan should find the lab machines. The second identifies services on the target. Verify the target’s adapter and default route in the VM itself or through the hypervisor; an address check alone does not prove isolation.

Open Juice Shop in a browser and choose Burp Suite or OWASP ZAP. Choose one intercepting proxy. Map the application and identify one vulnerability. Save the request, response, affected feature, and screenshots or terminal output that support the finding.

Keep all testing inside Juice Shop’s documented scope. Do not pivot from the lab into the host or household network.

Finish with a short report containing:

• Scope and date
• Lab topology
• Target address and version
• Steps to reproduce
• Evidence
• Security impact
• Remediation

A booting Kali VM proves almost nothing. The report is where the exercise becomes useful.

Snapshots, permissions, and notes are part of the lab

Take a clean snapshot after the network boundary passes its tests:

juice-shop-baseline-YYYY-MM-DD

Before exploitation or a major configuration change, take another snapshot. Restore the baseline deliberately and verify that Kali and Juice Shop still communicate. Snapshots belong in the testing workflow. Use them as restore points for the lab.

As ITU Online puts it, “Good labs are boring to maintain.” That is the point. Boring infrastructure leaves time for the exercise.

Record:

• VM names and roles
• Allocated memory and CPU
• Network adapters
• Lab subnet and addresses
• Target version
• Commands run
• Findings and evidence
• Snapshot names
• Cleanup steps

If you use Git, keep credentials, private samples, and sensitive data out of the repository. Scripts, notes, and write-ups can become useful portfolio material when they show what you tested and how you reached the result.

Test systems you own; for third-party systems, obtain explicit written permission before testing. Avoid cracked tools or software. A lab you own and isolate keeps the practice inside a boundary you control.

Before calling the weekend complete, record the goal. Confirm the adapter modes, restore the baseline snapshot, save the evidence, and write the remediation.

Add monitoring when you want to learn detection alongside exploitation

A blue-team lab begins with traffic and a question. An empty SIEM dashboard is another maintenance task.

Keep Kali and a target, then add a monitoring role. Generate controlled attack traffic and investigate the resulting endpoint logs and network telemetry. Shield Operations and the Ethical Hacking Institute map Wazuh toward endpoint visibility and Zeek or Suricata toward network-focused detection. Elastic can centralize and search events, but it also adds resource and maintenance demands.

Use this progression:

1. Start with logs from the target and attacker.
2. Add Wazuh when you need endpoint visibility.
3. Add Zeek or Suricata when you need network detection.
4. Consider Elastic after you have an investigation workflow.

The VM-allocation table in the koushikos guide gives an indicative SIEM allocation of 4–8 vCPUs and 8–16GB of RAM. Use that as a planning figure rather than a universal minimum. Your chosen tool and event volume decide the result.

Have Kali perform discovery against a target, then ask what evidence a defender should find. That question turns an exploit into detection practice.

Malware analysis is a different lab, not the next target VM

Malware analysis needs a stricter boundary than ordinary web testing. Plan for a dedicated detonation environment, stringent network controls, snapshots, and tools such as Cuckoo or CAPEv2. Keep it separate from the home network and from the everyday offensive lab wherever possible.

A sterile Windows VM may behave differently from a real endpoint. Grover describes malware identifying a sandbox and refusing to detonate. Making a VM look lived-in to defeat that behaviour is outside this guide and is not a safe beginner step.

Use controlled networking and preserve a clean restore point before analysis. Keep personal data and real credentials out of the environment. The point is containment: define what may leave the lab before you introduce a sample.

The first-weekend Kali-and-Juice-Shop lab is the wrong environment for malware execution. If you cannot explain how a sample is prevented from reaching your home network, stop there.

Move to Proxmox only when the current setup is the constraint

Proxmox is a useful graduation step when your current setup becomes the constraint. Move when several always-on VMs, repeatable virtual networks, or resource contention make the desktop hypervisor the bottleneck.

A sensible upgrade order is:

1. Add RAM.
2. Increase SSD or NVMe capacity.
3. Reserve resources for monitoring.
4. Move to dedicated hypervisor and network hardware when persistent services require it.
5. For a host holding credentials, notes, or samples, add full-disk encryption and a BIOS password; these protect the machine itself if it is lost or accessed physically.

Before each exercise, use the same preflight:

• Record the goal and scope.
• Check every adapter mode.
• Confirm the baseline snapshot.
• Write the stopping condition.

Then run the exercise, save the evidence, and write the remediation. Expand only when the next question requires another machine.