Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
A home lab is the single highest-leverage investment for anyone learning offensive or defensive security: it is a fully isolated environment where you own every host, so there is no authorization question and no consequence to breaking something. Reading about Kerberoasting, a Sigma rule, or a Linux privilege-escalation path is a different kind of learning than running the attack against a domain controller you built yourself, watching the resulting Event ID 4769 land in your own SIEM, and then tuning a detection rule against it. The lab is where offensive and defensive skill actually compound, because you control both sides of the engagement.
This article covers the practical build: choosing a hypervisor, laying out a segmented network so the lab can’t leak onto your home network or the internet, standing up a small Active Directory environment plus intentionally vulnerable machines, and wiring in the logging stack (Sysmon, a SIEM) that turns the lab from a pure attack range into a detection-engineering range as well. Prebuilt projects like GOAD (Game of Active Directory) and DetectionLab are named specifically because they encode a lot of this design work already and are the fastest path to a realistic environment.
Attack Prerequisites
Before provisioning anything, a few decisions and resources need to be in place, because retrofitting isolation or licensing after the fact is painful:
- Hardware headroom — a full AD lab (DC + 2-3 workstations + a vulnerable box) comfortably needs 32GB+ RAM and 200GB+ SSD on a single hypervisor host; smaller subsets run fine on 16GB.
- A hypervisor decision — type-1 (bare-metal) like Proxmox VE or ESXi for a dedicated always-on box, or type-2 (hosted) like VirtualBox or VMware Workstation for a lab that lives on a daily-driver laptop.
- Legally obtainable OS images — Windows Server evaluation ISOs (180-day eval, renewable) for the AD side; Debian/Ubuntu/Kali for Linux and the attacker side.
- A network isolation plan decided up front — internal-only virtual switches with no bridge to the home LAN before anything intentionally vulnerable is powered on.
- A snapshot/rollback strategy — take a snapshot immediately after each VM reaches a clean baseline state.
How It Works
The core idea is virtualization: one physical host running a hypervisor can present many isolated virtual machines, each with its own virtual NIC attached to a virtual switch you define. Proxmox VE is a free, Debian-based type-1 hypervisor that runs well on a dedicated mini-PC or old workstation and manages VMs/containers through a web UI plus a real API, making it the most common choice for a persistent home lab server. VirtualBox and VMware Workstation/Fusion are type-2 hypervisors that install on top of an existing OS and are the easiest entry point for a lab that lives on a laptop rather than dedicated hardware. All three let you create host-only or internal networks with no path to a physical NIC, which is the mechanism that provides isolation.
On top of the hypervisor, an Active Directory lab needs at minimum one domain controller (Windows Server, promoted with Install-ADDSForest), one or more domain-joined workstations, and ideally a second server hosting a role with intentionally misconfigured ACLs (unquoted service paths, GenericAll rights on a low-priv group, unconstrained delegation) — this is what turns “an AD exists” into “an AD has a realistic attack path.” Building that by hand is slow and easy to get subtly wrong, which is why community projects exist: GOAD (Game of Active Directory) is a scripted Vagrant/Ansible-driven multi-forest AD environment with deliberately vulnerable topology (ACL abuse, delegation misconfigurations, GPO abuse), and DetectionLab does the mirror-image job for the blue side — a small Windows/AD environment with Sysmon, Windows Event Forwarding, and an ELK/Splunk stack pre-wired via Packer/Vagrant/Ansible so telemetry flows from the moment the lab is up.
For non-Windows targets, purpose-built vulnerable VMs — VulnHub images or Metasploitable2/3 — provide Linux and web-app targets with documented vulnerability chains, useful for practicing enumeration and privilege escalation (find, sudo -l, GTFOBins-style binary abuse, SUID hunting) independent of the AD side. Running the attacker box as Kali Linux keeps offensive tooling (nmap, impacket, BloodHound, netexec) in one maintained image.
Practical Example / Configuration
Network segmentation is the part of the build that most tutorials skim past, and it’s the part that actually matters for safety. A workable layout uses a hypervisor-internal network with no uplink to the physical LAN, plus a single jump/attacker box that optionally gets a second NIC on your home network purely for convenience (RDP/SSH in from your daily driver), never the victim or domain hosts:
Physical host (Proxmox)
vmbr0 <- bridged to physical NIC, home LAN (management only)
vmbr1 <- internal-only virtual switch, NO physical uplink ("LAB-NET")
kali-attacker : vmbr0 (mgmt, SSH in) + vmbr1 (10.10.10.10/24)
dc01.lab.local : vmbr1 only (10.10.10.1/24)
ws01.lab.local : vmbr1 only (10.10.10.21/24)
ws02.lab.local : vmbr1 only (10.10.10.22/24)
vulnbox (metasploitable): vmbr1 only (10.10.10.50/24)
Only kali-attacker has a second interface off LAB-NET, and only for
management access -- egress from vmbr1 to the internet is not routed.
A Proxmox firewall rule set enforced at the vmbr1 bridge level backstops the topology above in case a VM is later given a second NIC by mistake:
# On the Proxmox host, restrict the internal bridge from reaching the internet
# /etc/pve/firewall/cluster.fw (excerpt)
[OPTIONS]
enable: 1
[RULES]
IN DROP -source 10.10.10.0/24 -dest 0.0.0.0/0 -p tcp -dport 1:65535 # default-deny egress
IN ACCEPT -source 10.10.10.0/24 -dest 10.10.10.0/24 # allow intra-lab traffic
Walkthrough / Exploitation
A repeatable build sequence, from bare hypervisor to a working detection-and-attack range:
1. Install hypervisor (Proxmox VE on dedicated hardware, or VirtualBox/VMware
Workstation on a laptop with 16-32GB+ RAM available to VMs).
2. Create the internal-only virtual switch/network first, before any VM exists.
3. Deploy the attacker box: Kali Linux, update, install the offensive toolset
(impacket, BloodHound, netexec, Rubeus via a Windows jump host if needed).
4. Deploy DetectionLab (blue side): 'git clone https://github.com/clong/DetectionLab
&& cd DetectionLab/Vagrant && vagrant up' -- brings up a DC, WEF forwarding,
Sysmon, and an ELK/Splunk stack.
5. Deploy GOAD (red side attack paths) into the same/paired internal network:
'git clone https://github.com/Orange-Cyberdefense/GOAD && cd GOAD/ansible &&
ansible-playbook -i inventory/ goad.yml -e "ansible_provider=vagrant"'
6. Snapshot every VM once it reaches a clean, fully-provisioned baseline.
7. Run an attack path from Kali against the GOAD forest ('netexec smb
10.10.10.0/24 -u guest -p "" --shares', then 'bloodhound-python -u student1
-p Password123! -d lab.local -ns 10.10.10.1 -c All'), then pivot to the
DetectionLab Kibana/Splunk instance to confirm the corresponding Sysmon and
Kerberos (Event ID 4769) telemetry actually landed.
8. Revert to the clean snapshot before the next exercise.
Note: Renew Windows evaluation licenses before they expire (180 days, renewable up to a few times via
slmgr /rearm) rather than letting a lab host silently start shutting down every hour, which is the classic symptom of an expired eval and wastes hours of confused troubleshooting.
Opsec: Even in an isolated lab, disable or firewall off any component that could accidentally relay to the real internet (a misconfigured NAT network in VirtualBox is the most common leak vector). Never reuse lab credentials, certificates, or SSH keys anywhere outside the lab, and treat any vulnerable VM image downloaded from the internet (VulnHub, community GOAD forks) as untrusted code until it’s running fully inside the isolated network.
Detection and Defense
Running the lab safely and getting detection value out of it both come down to the same disciplines:
- Hard network isolation — internal-only virtual switches with no bridge to a physical NIC for anything except a single management interface on the attacker box; verify with a simple
ping 8.8.8.8from a victim VM that egress is actually blocked. - Sysmon on every Windows host — deploy a maintained baseline config (e.g. the community ‘SwiftOnSecurity’ or Olaf Hartong config) rather than defaults, so process creation, network connection, and image-load events are captured with useful filtering from day one.
- Centralized logging — Windows Event Forwarding or Sysmon-to-Elastic/Splunk shipping so you’re not tailing individual event logs per host; this is what DetectionLab automates.
- Snapshot discipline — snapshot before every exercise and after every clean rebuild, so a broken or compromised-by-design VM can be reverted in seconds instead of rebuilt.
- Credential and secret hygiene — treat the lab’s domain admin password, KRBTGT hash, and any generated certificates as toxic; never copy them into a password manager or repo used for anything real.
The highest-value habit is pairing every offensive technique practiced with the corresponding blue-team check in the same session — run the attack, then go confirm which Sysmon/Windows event IDs it generated and whether a Sigma rule would have caught it. That loop is what a home lab is for.
Real-World Impact
GOAD and DetectionLab are both widely used in OSCP/CRTP-style certification prep and internal enterprise security training because they encode realistic AD misconfiguration and logging patterns without needing a live enterprise environment. Security teams also run scaled-down versions of the same architecture — an isolated AD forest plus a logging pipeline — as internal purple-team ranges to validate detection content before it ships to production.
Conclusion
A home lab’s value comes entirely from two disciplines: real isolation, so nothing vulnerable-by-design can reach anything that matters, and paired offense/defense practice, so every attack technique is tied back to the telemetry that should have caught it. Proxmox or VirtualBox for the hypervisor, GOAD for a realistic AD attack surface, DetectionLab for the logging and SIEM side, and a disciplined snapshot habit turn a spare machine into the fastest way to build both red and blue skill at once.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments