Building a Cybersecurity Home Lab: Safe Defensive Set-ups

A home lab is the fastest way to learn defence, but a badly built one exposes vulnerable machines to your home network or the internet, leaks real credentials, or runs up a cloud bill. This guide explains how to design a lab that is isolated, legal and cheap to rebuild: virtualisation and network modes, snapshot discipline, hardware options in general terms, a defensive build with a Windows domain, Linux hosts and centralised logging, intentionally vulnerable training applications, and cloud free-tier labs with budget alerts. It is written for learners, career changers and practitioners who want a safe place to practise detection, hardening and investigation. It covers defensive use only: never test systems you do not own or have written permission to test.

Key takeaways

Isolation comes first. Put lab machines on an internal or host-only virtual network with no route to your home LAN or the internet, and add a controlled gateway only when you need updates.
Snapshots are your rollback plan. Take a clean snapshot after each build stage so any experiment can be undone in seconds.
Build for telemetry, not just targets. A Windows domain, a Linux host, Sysmon, a network sensor and a SIEM such as Wazuh or Security Onion teach more than a pile of vulnerable machines.
Vulnerable applications stay inside the lab. Use well-known official training projects such as OWASP Juice Shop or WebGoat, bound to the isolated network, never exposed.
Cloud labs need guard rails. Budget alerts do not stop spending, so add MFA, no real data, short-lived resources and a teardown routine.

Legal and safety ground rules

Only touch what you own or are authorised to test: in the UK, section 1 of the Computer Misuse Act 1990 makes it an offence to cause a computer to perform a function intending to secure access that you know is unauthorised. Most countries have comparable laws. Scanning a neighbour's router, a former employer's VPN or a random cloud IP is not "practice".
Treat intentionally vulnerable software as hazardous: the OWASP WebGoat project warns that while it runs your machine will be extremely vulnerable to attack, and advises disconnecting from the internet while using it. Apply the same rule to every deliberately insecure image.
No real data: no employer data, customer data, production credentials or personal documents in the lab. Use generated test data.
Download from official sources and verify: take ISOs and images from the project or vendor site and check the published checksum (Security Onion's documentation, for example, tells you to always verify the ISO).
Respect licences: evaluation editions, open source licences and tool licence terms still apply in a lab.

Designing the lab: virtualisation and network isolation

A type 2 hypervisor on a workstation (VirtualBox, VMware Workstation, Hyper-V on Windows, KVM with virt-manager on Linux) is enough for most learners. A dedicated type 1 host (Proxmox VE, Hyper-V Server role, ESXi where licensed) suits larger labs that run continuously. The isolation decision is in the virtual network mode, and the names differ by product.

Mode (VirtualBox name / Hyper-V switch)	Reaches other VMs	Reaches host	Reaches LAN and internet	Lab use
Internal network / Private switch	Yes	No	No	Default for vulnerable targets and attack simulation
Host-only / Internal switch	Yes	Yes	No	Management access from the host to the SIEM web interface
NAT	No (VirtualBox NAT)	Yes	Outbound only; inbound needs port forwarding	Temporary updates for a single clean VM
NAT Network	Yes	Yes	Outbound only; inbound needs port forwarding	Updates for a group of clean VMs, then disconnect
Bridged / External switch	Yes	Yes	Yes, appears on your LAN	Avoid for lab targets; never for vulnerable images

Recommended pattern: an internal lab network for all lab machines, plus a virtual firewall or router VM (pfSense or OPNsense, for example) with one leg on the lab network and one on NAT. Keep the firewall's lab-to-outside rule disabled by default and enable it only while patching.
Separate the management path: give the SIEM a second adapter on host-only networking so you can reach its web console from the host without giving targets a route out.
Shared folders and clipboard: turn off shared folders, drag and drop and clipboard sharing on target VMs; they are a path from a compromised guest to your host.
Host hygiene: keep the host patched, use a standard (non-admin) account for daily work, and do not run the lab on the same machine you use for banking or work if you can avoid it.

Snapshot discipline

Install and patch the operating system, then snapshot as "clean base".
Install agents and logging configuration, then snapshot as "instrumented".
Before any attack simulation or malware-related exercise, snapshot as "pre-test" with the date.
After the exercise, export the evidence you need (logs, timelines) to the SIEM or a notes folder, then revert to "pre-test" or "instrumented".
Rebuild from "clean base" monthly, so expired evaluation licences and drift do not accumulate. Snapshots are not backups: keep exported configurations and notes elsewhere.

Hardware options

Hardware sets how many VMs run at once. The SIEM is usually the hungriest component.

Option	Suits	Trade-offs
Existing laptop or desktop	Stage 1 and 2 learners, two or three small VMs	Memory runs out quickly once a SIEM is added; lab and personal use share one machine
Second-hand small form factor PC or mini PC with extra RAM	A continuous lab with a domain, two endpoints and a SIEM	Low power and quiet; check CPU virtualisation support and maximum RAM before buying
Refurbished server or workstation	Large labs, network sensors, several SIEMs side by side	Noise, power draw and space
Cloud free tier or credits	Cloud security practice, short-lived exercises	Costs if resources are left running; needs the guard rails below

Sizing anchors from vendor documentation: Security Onion's first-time user guidance lists a minimum of 4 GB RAM, 2 CPU cores and 200 GB storage on x86-64 for an IMPORT installation, and notes the host needs more than that for itself and other VMs. Wazuh's quickstart sizing for 1 to 25 agents is 4 vCPU, 8 GiB RAM and 50 GB storage for 90 days of data. Plan memory first, then fast SSD storage.
Architecture: Security Onion supports x86-64 only, so ARM-based laptops need a different SIEM choice or a separate x86 host.

Building a defensive lab

A useful defensive lab reproduces a small organisation: a directory, a couple of endpoints, a server and the telemetry a SOC would collect.

Component	Suggested build	What it teaches	Guide
Domain controller	Windows Server evaluation edition with Active Directory Domain Services, DNS and a few Group Policy Objects	Kerberos, Group Policy, security event logging (4624, 4625, 4688, 4768, 4769)	Windows Server Hardening Guide
Windows endpoint	Windows client evaluation edition joined to the domain, with Microsoft security baselines applied	Hardening, local admin control, endpoint telemetry	Windows Endpoint Hardening Guide
Endpoint telemetry	Sysmon with a community or self-written configuration, installed with `sysmon -accepteula -i config.xml`	Process creation (event ID 1), network connections (3), process access (10), DNS queries (22)	Sysmon Guide
Linux host	A current Ubuntu or Debian server running SSH and a web service, with auditd	Linux authentication logs, auditd rules, service hardening	Linux Logging and auditd for Defenders Guide
Host query	osquery on Windows and Linux hosts	Asking endpoints questions in SQL: listening ports, autostarts, users	osquery Guide
SIEM and XDR	Wazuh all-in-one, or Security Onion in IMPORT or standalone mode	Collection, decoding, rules, alert triage, dashboards	Wazuh Guide, Security Onion Guide
Network sensor	Zeek and Suricata on a sensor interface that sees lab traffic (Security Onion bundles both)	Connection, DNS, HTTP and TLS logs; signature alerts in EVE JSON	Zeek Network Monitoring Guide, Suricata IDS Guide
Detection content	Sigma rules converted for your SIEM	Writing, testing and tuning detections	Sigma Rules Guide
Investigation tools	Sysinternals Suite on the Windows endpoint	Autoruns, Process Explorer, Process Monitor, Sigcheck for triage	Sysinternals for Incident Responders Guide

Build order

Network first: create the internal lab network and the firewall VM, and confirm from a test VM that nothing outside the lab is reachable (try your home router's address and a public address; both should fail).
SIEM second: install Wazuh or Security Onion on the lab network with a host-only management adapter. Security Onion's documentation recommends IMPORT for first-time users, where you upload a PCAP or EVTX file from the Grid page and pivot to alerts and dashboards; move to a standalone installation once comfortable.
Directory third: build the domain controller, create test users and a service account, and enable the advanced audit policy for logon, account management and process creation.
Endpoints and agents: join the Windows client, install Sysmon and the SIEM agent, add the Linux host with auditd and its agent. Check every host is reporting before going further.
Network sensor: add Zeek and Suricata on an interface that sees lab traffic (a promiscuous-mode adapter on the lab network, or a sensor VM placed inline behind the firewall).
Snapshot everything as "instrumented" and record the build in a notes file.

Exercises that build defensive skill

Logon failures and spraying: generate failed logons against your own test accounts and find them as event ID 4625 and in the SIEM. Map it to Password Spraying (T1110.003).
PowerShell visibility: enable script block logging and run benign scripts; find them in the PowerShell Operational log and Sysmon event ID 1 (T1059.001).
Persistence: create a scheduled task yourself and find it with Autoruns, Sysmon and Security event 4698 (T1053.005).
Credential access: watch for Sysmon event ID 10 process access against lsass.exe, the telemetry behind LSASS Memory detection (T1003.001). Use detection test frameworks only inside the lab, and never with real credentials.
Lateral movement: connect between lab hosts over SMB admin shares and observe 4624 logon type 3 plus Zeek SMB logs (T1021.002).
Secrets in files: plant a fake credential in a script on a share and write a detection or hunting query for it (T1552.001).

Intentionally vulnerable training applications

For application security practice, use well-known official projects and run them only on the isolated lab network. For courses and practice platforms to pair with these, see our free cybersecurity learning resources guide.

OWASP Juice Shop: an intentionally insecure web application built with Node.js, Express and Angular, MIT licensed, runnable with Node.js, Docker or Vagrant. Its challenges, tracked on a score board, span categories drawn from the OWASP Top Ten and other references, including injection, broken access control, cross-site scripting and vulnerable components, plus coding challenges where you find and fix the flawed code. It resets its data on every start.
OWASP WebGoat: a deliberately insecure Java application designed as an interactive teaching environment. It binds to localhost by default; keep it that way or bind it only to the lab network.
Container hygiene: when running these in Docker on a lab VM, publish ports to the lab interface only, never to 0.0.0.0 on a machine that also has a bridged or public interface.
Defensive angle: put the web application behind your network sensor and SIEM, then practise detecting your own test requests in web and Suricata logs. See the OWASP Top 10 Guide.

Cloud free-tier labs

Cloud practice teaches IAM, logging and posture management that a local lab cannot. The main risks are cost, leaked keys and accidentally public resources.

Provider	Budget feature	What the documentation says it does	Gap to cover
AWS	AWS Budgets	Cost and usage budgets with alerts on actual or forecasted spend, by email or Amazon SNS; budget actions can apply an IAM policy that denies provisioning; data updates up to three times a day	Charges can exceed the threshold before the alert arrives
Microsoft Azure	Cost Management budgets	Up to five thresholds and five email addresses per budget, actual or forecasted; action groups can run automation; evaluated every 24 hours	Budgets do not stop resources or consumption
Google Cloud	Cloud Billing budgets	Default alerts at 50%, 90% and 100%; email or Pub/Sub notifications that can drive automation	An alerts-only budget does not cap usage; set the budget below your real limit to allow for reporting delay

Separate account: use a dedicated lab account or subscription, never a work tenant. Protect the root or owner account with phishing-resistant MFA and do not use it day to day.
Budget alerts on day one: set a low budget with forecasted and actual alerts before creating any resource.
Tag and tear down: tag every lab resource, build with infrastructure as code so teardown is one command, and check for orphaned disks, IP addresses and snapshots after each session.
No public exposure: restrict security groups to your own IP, keep storage private, and never deploy intentionally vulnerable images to a public address.
Turn on logging: CloudTrail, the Azure Activity Log or Cloud Audit Logs are the learning material for cloud detection, so enable them and read them.

Test environments are attacked like production. The Microsoft Midnight Blizzard breach began with a password spray against a legacy, non-production test tenant account that had no MFA. A personal cloud lab with a weak password and no MFA is a smaller version of the same mistake. See the Cloud Security Guide.

Secrets hygiene in the lab

Labs are full of non-human identities: domain service accounts, SIEM agent enrolment keys, API keys for cloud labs and tokens for Git hosting. Practise handling them properly, because habits formed in the lab carry into work.

Keep lab secrets out of Git: lab write-ups and infrastructure code are often published. Use a .gitignore for environment files, enable secret scanning or a pre-commit hook, and review history before making a repository public. The Uber 2016 breach started with an AWS access key stored in a GitHub repository. See the Git Secret Scanning Guide.
Short-lived cloud credentials: prefer single sign-on or temporary role credentials over long-lived access keys on your laptop; if you must create a key, scope it to the lab and delete it after the session.
Unique lab passwords: never reuse a real password in the lab, and store installer-generated credentials (Wazuh writes them to a passwords file in its install archive) in a password manager, then delete the file.
Practise rotation: rotate the lab service account password and agent keys and watch what breaks. See the Secrets Management Guide.

Measuring whether the lab is working

Coverage: percentage of lab hosts reporting to the SIEM in the last 24 hours (target 100%).
Detection yield: number of exercises in which the expected event appeared in the SIEM, out of exercises run.
Rebuild time: minutes to revert or rebuild the lab to "instrumented"; short times mean you will experiment more.
Isolation tests: monthly confirmation that lab targets cannot reach your LAN or the internet.
Cloud spend: monthly cost against budget, and number of resources left running after a session (target zero).

Framework mapping

A home lab is also a model of good practice for test environments at work. These are the controls it exercises.

Lab practice	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Isolated lab network, firewall VM	SC-7 Boundary Protection, CM-4(1) Separate Test Environments	PR.IR-01
Clean base images and baselines	CM-2 Baseline Configuration, CM-7 Least Functionality	PR.PS-01
Sysmon, auditd and SIEM collection	AU-2 Event Logging, AU-6 Audit Record Review, Analysis, and Reporting	PR.PS-04
Network sensor and endpoint monitoring	SI-4 System Monitoring	DE.CM-01, DE.CM-09
Snapshots and exported configuration	CP-9 System Backup	PR.DS-11
Separate pre-production environment	SA-3(1) Manage Preproduction Environment	PR.PS-01

Common failure patterns

Bridged vulnerable machines: a vulnerable image on bridged networking sits on your home LAN beside family devices. Use internal networking.
Port forwarding "just to test from my phone": forwarding a lab service through the home router exposes it to the internet. Do not forward lab ports.
A SIEM nobody reads: building the stack, then never running exercises. Plan one exercise per week and write it up.
Forgotten cloud resources: a VM or managed database left running after a weekend lab, with alerts arriving hours later. Use infrastructure as code teardown and forecasted budget alerts.
Published secrets: lab repositories pushed to public Git hosting with keys or passwords in history, as in the Uber case above.
Testing outside the lab: pointing scanners or tools at systems you do not own. Keep every target inside the lab or on a platform that gives you explicit permission.

Practitioner checklist

Create an internal-only lab network and confirm targets cannot reach your LAN or the internet.
Add a firewall VM with outbound access disabled except during patching.
Disable shared folders, clipboard and drag and drop on target VMs.
Download images from official sources and verify checksums.
Take "clean base", "instrumented" and "pre-test" snapshots and revert after every exercise.
Build a domain controller, a Windows endpoint and a Linux host with Sysmon, auditd and a SIEM agent.
Add Zeek and Suricata, or Security Onion, so you have network telemetry.
Run vulnerable training applications such as OWASP Juice Shop only on the lab network.
For cloud labs, use a separate account with MFA, budget alerts before any resource, tags and scripted teardown.
Keep lab secrets out of Git, use unique passwords and practise rotation.

Building a Cybersecurity Home Lab Guide: Safe Set-ups for Learning Defence