Avatar
Part time CTF Player learn every day!!
🌠 I Love Hoshimachi Suisei!! 🌠
🌠 I Love Hoshimachi Suisei!! 🌠

Build a Home Cybersecurity Lab with VirtualBox/VMware

Build a Home Cybersecurity Lab with VirtualBox/VMware

Halloo, another time another post it’s me lovely SuiiKawaii again — this time we’re building your home cybersecurity lab. A virtual lab lets you learn hacking legally and safely: you practice on machines you own, isolated from your real network and data. In this guide, you’ll set up an attacker VM (Kali or Parrot), add a few intentionally vulnerable targets, wire them with the right virtual network modes, and learn a clean snapshot workflow so you can break things and roll back in seconds.

Suiw

Internal reads: If you’re new to Linux, skim my post Mastering Linux for Cybersecurity first. And when you’re ready to practice fundamentals, jump into OverTheWire Bandit Index.


Table of Contents


1) Why build a home lab

  • Safety: Break things without risking your real OS or data.
  • Reproducibility: Roll back with snapshots; document what works.
  • Focus: Curated targets teach specific skills (web vulns, services, creds).
  • Portability: Your entire lab fits on a laptop + external SSD.

Further references:

↑ Back to top


  • Only attack systems you own or have explicit written permission to test.
  • Keep your lab isolated (Host-only networks for targets).
  • If you demo or publish writeups, scrub sensitive material (keys, tokens, real data).

Further references:

↑ Back to top


3) What we’ll build (topologies)

Start simple, then scale:

(Attacker)
Kali / Parrot / BlackArch / BackBox  ──┐
                                       ├── Host-Only Network  ← isolated playground
Target #1                             ──┤
Target #2                             ──┘

Attacker                              ── NAT ── Internet (for updates/tools)
  • Phase 1: One attacker VM + one target on a Host-only network.
  • Phase 2: Add more targets (e.g., a web vuln box + a Linux service box).
  • Phase 3 (optional): A tiny “enterprise”: 1 DNS, 1 web, 1 DB target.

Rule of thumb: Host-only for lateral play; give the attacker a second NIC (NAT) for updates. Targets normally don’t need Internet.

Further references:

↑ Back to top


4) Requirements & downloads

Host machine suggested minimum: 4 cores, 16 GB RAM, SSD, and virtualization enabled in BIOS/UEFI (Intel VT-x / AMD-V).

4.1) Install the hypervisor (video walkthroughs)

Further references:

↑ Back to top


5) VirtualBox vs VMware (quick compare)

Feature VirtualBox VMware Workstation/Fusion
Cost Free Player (free personal), Pro (paid)
Ease Beginner-friendly Polished UI, strong device support
Snapshots Yes Yes (Player lacks snapshot tree mgmt)
Shared folders Yes Yes
3D/Graphics Basic Often better integration
Cross-platform Win/macOS/Linux Win/Linux (Workstation), macOS (Fusion)

Pick one and stick with it; the concepts here apply to both.

Further references:

↑ Back to top


6) Network modes explained

  • NAT (Attacker only): VM gets Internet through the host; outside cannot reach the VM directly. Perfect for updates.
  • NAT Network (VirtualBox): Like NAT but VMs can see each other on the same NAT segment.
  • Host-only: VMs talk to each other and to the host, no Internet by default. Ideal for targets.
  • Bridged: VM appears as a device on your physical LAN. Avoid for targets (leak risk); use only if you know what you’re doing.

Recommended baseline:

  • Attacker VM: Adapter 1 = Host-only, Adapter 2 = NAT
  • Each target VM: Adapter 1 = Host-only (same network as the attacker’s Host-only)

Further references:

↑ Back to top


7) Create your attacker VM (Kali/Parrot)

This is your “offensive workstation.” Before we install anything, here’s how to choose the OS wisely.

7.1) Attacker OS choices & comparison

Short take: If you’re new, choose Kali or Parrot. They’re friendly, well-documented, and come with a curated toolset that “just works”.

Distro Base & Package Manager Preinstalled Tools Update Style Community / Docs Footprint Best For Notes
Kali Linux Debian; apt Extensive (pentest, forensics) Rolling Huge community, lots of tutorials Medium Beginners → Pro “Industry standard” for pentest labs; great device support.
Parrot Security OS Debian; apt Extensive (pentest + privacy) Rolling Strong community Light/Medium Beginners → Pro Privacy-leaning feel; often lighter than Kali.
BlackArch Arch; pacman + AUR Massive (thousands) Rolling (bleeding) Niche but passionate Light Advanced DIY maintenance; excellent if you like Arch workflows.
BackBox Ubuntu LTS; apt Curated (leaner) Regular LTS Moderate Light Beginner/Intermediate Stable Ubuntu base; add only what you need.

Decision criteria (pick what matters to you):

  • Experience level: New? Kali/Parrot. Comfortable with Arch? BlackArch. Want Ubuntu LTS stability? BackBox.
  • Philosophy: Everything preinstalled (Kali/Parrot) vs curated/lean (BackBox) vs huge repo/DIY (BlackArch).
  • Community & docs: Kali/Parrot have the most tutorials and troubleshooting guides.
  • Update cadence: Rolling is convenient but can break occasionally — snapshot first.
  • Hardware & drivers: Kali/Parrot are generally smooth in VMs and on laptops.

Further references:

7.1.1) OS selection flow (decision tree)

Quick checklist (text version)

1) Brand-new to Linux?

  • Yes → Pick Kali (largest preinstalled toolset, huge community) or Parrot (lighter feel, privacy-leaning).
  • No → Go to 2.
    2) Already comfortable with Arch (pacman/AUR, rolling, DIY)?
  • Yes → BlackArch.
  • No → Go to 3.
    3) Prefer Ubuntu LTS stability with a lean, curated toolkit?
  • Yes → BackBox.
  • No → Go to 4.
    4) Tighter hardware (≤ 8 GB RAM / older CPU) and want a smoother VM?
  • Prefer Parrot or BackBox; Kali is still fine (medium footprint).
    5) Need the broadest out-of-the-box suite and tutorials everywhere?Kali.
    6) Want a privacy-friendly flavor that still ships offensive tools and feels snappy?Parrot.
    7) Still unsure? Start with Kali/Parrot for 3–6 months. Snapshot often. Then try BlackArch/BackBox.

TL;DR mapping:
Beginner, want everything ready → KaliBeginner, lighter/privacy → ParrotAdvanced+Arch → BlackArchUbuntu LTS lean → BackBox

flowchart TD
    A[Start] --> B{New to Linux?}
    B -- Yes --> C{Prefer biggest preinstalled\ntoolset & community?}
    C -- Yes --> K[Kali Linux]
    C -- No / prefer lighter & privacy --> P[Parrot Security]
    B -- No --> D{Comfortable with Arch (pacman/AUR)?}
    D -- Yes --> BA[BlackArch]
    D -- No --> E{Prefer Ubuntu LTS with\nlean curated tools?}
    E -- Yes --> BB[BackBox]
    E -- No --> F{Need largest OOTB suite\n& docs everywhere?}
    F -- Yes --> K
    F -- Prefer lighter/privacy --> P
    G[Low RAM / older CPU] --> P
    G --> BB

7.2) Quick install & first snapshot

Allocate 2–4 vCPUs, 4–8 GB RAM, 40+ GB disk. Enable EFI if your ISO needs it.

  • Kali post-install quick steps:

    sudo apt update && sudo apt -y upgrade
    sudo apt install -y git curl neovim
    
  • Optional: install VMware/VirtualBox guest tools (clipboard, drag & drop, display).

Tip: Name this VM attacker-kali-base (or parrot-base) and take a snapshot right after updates: clean-base.

↑ Back to top


8) Add safe target VMs

Pick one to start:

  • Metasploitable2: vulnerable services (FTP/Telnet/DB). Great for service enumeration.
  • OWASP Juice Shop: intentionally vulnerable modern web app (XSS, auth flows).
  • DVWA: classic web vuln exercises (SQLi/XSS/CSRF/File upload).

Resource hint: 1–2 GB RAM per target is often enough.

Keep targets on Host-only; they don’t need Internet. If a target needs updates during setup, temporarily add a NAT adapter, update, then remove it.

Optional: prefer containers for some web apps:

Further references:

8.1) Hosted practice labs (no VM required)

If you don’t want to build targets right away, these platforms provide ready-made environments with guided scenarios:

  • TryHackMe — room-based labs with beginner paths; connect via OpenVPN/WireGuard from your attacker VM.
  • Hack The Box — many boxes by difficulty; “Starting Point” is great for beginners; also uses VPN.
  • PortSwigger Web Security Academy — hundreds of web labs hosted safely and legally.
  • OverTheWire — SSH-based wargames to sharpen your CLI.
  • picoCTF — beginner-friendly CTFs across web/forensics/crypto.

VPN note: When connecting THM/HTB VPN inside your attacker VM, keep your local targets on Host-only. Don’t enable Bridged unless you fully understand the scope and risks.

↑ Back to top


9) Wire the network (isolation-first)

VirtualBox example (recommended):

  • Create a Host-only network (e.g., vboxnet0) with DHCP range 192.168.56.0/24.
  • Attacker:

    • Adapter 1: Host-only (vboxnet0)
    • Adapter 2: NAT
  • Targets:

    • Adapter 1: Host-only (vboxnet0)

Now the attacker sees targets at 192.168.56.x, and can still apt update over NAT — while targets remain isolated.

Quick checks from attacker:

ip a             # verify Host-only IP, e.g., 192.168.56.101
ip r             # default route should point at the NAT adapter
ping -c1 192.168.56.102   # a target

If DHCP is off in Host-only, set static IPs on each VM within the same subnet.

↑ Back to top


10) Snapshots & workflow

  • Baseline: After a clean install + updates, take clean-base.
  • Per lab: Before you start a challenge, take pre-lab-<date>.
  • After success: If you want to keep the state, snapshot post-lab-<topic>.
  • Reset often: Don’t be shy about reverting; that’s the point.

Naming tip: YYMMDD-context, e.g., 250814-pre-lab-enum-ftp.

↑ Back to top


11) Quality-of-life settings

  • Shared folders for notes/tooling (~/lab on host ↔ /mnt/lab on VM).
  • Clipboard/Drag-and-drop (bidirectional) for quick copy/paste (disable during captures if needed).
  • Time sync (helps with logs/certs).
  • Auto-resize display via Guest Additions / VMware Tools.

Optional: tiny helper to print your VM’s IPs:

#!/usr/bin/env bash
ip -4 -o a | awk '{print $2,$4}'

↑ Back to top


12) Security hygiene in your lab

  • No Bridged for targets unless required.
  • Separate user on attacker VM; no browser logins to personal accounts inside Kali.
  • Rotate snapshots (delete stale states to save disk).
  • Label disks and keep backups off-machine (external SSD).
  • Document: keep a lab journal (~/lab/notes/).

↑ Back to top


13) Practice ideas (first week)

  1. Service discovery: ip a, ip r, ping, nc, nmap -sV -O 192.168.56.0/24 (legal: within your lab).
  2. Web recon: curl -I, directory discovery (against Juice Shop/DVWA in your lab).
  3. Logs & creds: review /var/log/auth.log on a target you control; change the SSH banner.
  4. Write notes: one insight/day.
  5. Bonus: Parallel your CLI learning with OverTheWire Bandit.

↑ Back to top


14) Troubleshooting

  • No virtualization options: Enable Intel VT-x / AMD-V in BIOS/UEFI. On Windows, ensure Hyper-V isn’t hijacking VT-x (you may need to disable it).
  • No network in VM: Check adapter type (e.g., Intel PRO/1000), cable connected, DHCP on Host-only or set static IP.
  • Screen too small: Install Guest Additions / VMware Tools, then toggle auto-resize.
  • DNS fails but ping works: Verify /etc/resolv.conf; try resolvectl status (or systemd-resolve --status).
  • Snapshots take huge space: Power off VMs; consolidate/delete older snapshots you don’t need.

FAQ

Should targets ever use Bridged? Generally no. Bridged exposes targets to your real LAN. Stick to Host-only unless you have a specific, controlled reason.

Can I store targets as templates? Yes. Keep a powered-off “template” VM (clean state) and clone before labs. It saves disk compared to dozens of snapshots.

VirtualBox or VMware — which is faster? It depends on host hardware/OS and guest additions. For learning, both are fine — pick one and focus on your workflow.

What about Docker containers as targets? Great idea for web apps like Juice Shop. Just ensure containers are attached to isolated networks (e.g., user-defined bridge) and not exposed to your LAN.

↑ Back to top


Appendix A — Quick sizing matrix

VM role vCPU RAM Disk Notes
Attacker (Kali/Parrot) 2–4 4–8 GB 40–80 GB Add 2 NICs (Host-only + NAT)
Web target (DVWA/Juice) 1–2 1–2 GB 10–20 GB Host-only
Service target (Metasploitable2) 1–2 1–2 GB 10–20 GB Host-only

Appendix B — Clean reset workflow

  1. Before lab: snapshot pre-lab-<date>.
  2. During lab: take small checkpoints if needed.
  3. After lab:

    • Export notes/logs to the host.
    • Either revert to pre-lab-<date> or power off and restore the clean template.
  4. Housekeeping: delete stale snapshots monthly to free space.

↑ Back to top


Appendix C — Safe scan baseline (lab only)

Only run these inside your isolated lab.

# Discover live hosts on Host-only network
ip -4 -o a | awk '/vboxnet|host-only|enp/ {print $4}'      # confirm your subnet
nmap -sn 192.168.56.0/24

# Service/version detection against a target
nmap -sV -O 192.168.56.102

# Quick web check
curl -I http://192.168.56.102/

↑ Back to top


Appendix D — Mini glossary

Host-only: virtual network connecting VMs + host only, no Internet. NAT: VMs reach the Internet through the host; inbound blocked by default. Snapshot: point-in-time save of VM disk/memory to restore later. Clone: a copy of a VM (linked or full). Guest tools: integration package (clipboard, graphics, filesystem sync).

↑ Back to top


Resource Library (Articles & Videos)

Articles/guides:

Videos/playlists:


Final notes

You now have a safe playground to learn. Keep the attacker on Host-only + NAT, keep targets Host-only only, snapshot early/often, and journal what you try. Pair this with your Linux study from Mastering Linux for Cybersecurity and steady hands-on work via OverTheWire Bandit — you’ll level up fast.


Thanks for reading!

Until next time — Otsumachi!! 💖☄️✨

Cinema

all tags

dash theme for Jekyll by bitbrain made with