This repository documents my VirtualBox-based security lab, built to simulate a small enterprise network for hands-on learning in both offensive and defensive security.
The lab is intentionally segmented, monitored, and attackable. It allows me to practice realistic workflows such as domain enumeration, Active Directory attacks (kerberoasting), and detection using SIEM and NIDS tooling, without exposing my home network.
The overall architecture and learning approach are inspired by Ben Heater (0xBen) and his security lab guide: https://benheater.com/building-a-security-lab-in-virtualbox/
The goals of this lab are to:
- Gain hands-on experience with enterprise-style network segmentation
- Practice penetration testing against intentionally vulnerable systems (ctf's)
- Experimenting with tools such as Wireshark, BurpSuite to intercept https packets, proxy tools (FoxyProxy), nmap, searchsploit, etc.
- Get familiar with ARP spoofing/poisoning as a basic Layer 2 attack and understand how it can lead to man‑in‑the‑middle situations on a local network.
- Explore common Active Directory attack paths
- Understand Kerberos authentication, and how protocols like LDAP and SMB are used to query or retrieve information
- Understand how attacks generate detectable telemetry
- Build familiarity with SIEM and NIDS tooling
- Document repeatable attack, detection, and response workflows
This is a learning environment and will evolve over time as new techniques and tools are introduced.
The lab is built around a central pfSense firewall that routes and filters traffic between multiple internal networks configuered in VirtualBox. Each network serves a specific purpose and is isolated by default.
All systems run on private IP address space (RFC 1918). Internet access is tightly controlled and only permitted where explicitly required.
A detailed architecture diagram is available in:
/diagrams/lab-architecture.png
pfSense acts as the default gateway and enforcement point for all lab traffic. Each network segment is mapped to a dedicated pfSense interface(vtnet0-5)
- Purpose: Internet access via home network (Downloading tools, updates, etc.)
- Adapter: Bridged
- Notes:
- pfSense receives a private RFC1918 address
- “Block private networks (RFC1918)” is disabled because the WAN resides inside a private home network
- Outbound NAT is performed by pfSense for internal lab subnets
- Home router performs standard edge NAT to the public internet
- Subnet:
10.0.0.0/24 - Gateway:
10.0.0.1(pfSense)
| Host | IP Address | Role |
|---|---|---|
| Kali Linux | 10.0.0.2 |
Attacker and management jump host |
| Wazuh (Mgmt) | 10.0.0.3 |
SIEM management interface for SSH and SIEM login |
This network is used to:
- Launch attacks
- Access management interfaces (pfSense, Wazuh)
- Administer the lab environment
- Subnet:
10.6.6.0/24 - Gateway:
10.6.6.1(pfSense)
| Host | IP Address | Role |
|---|---|---|
| VulnHub VM | 10.6.6.13 |
Vulnerable target |
| Metasploitable2 | 10.6.6.22 |
Intentionally vulnerable Linux VM |
Security Characteristics:
- No outbound internet (blocked by pfSense firewall)
- No lateral access to AD_LAB segment
- Reachable only from approved internal segments
- Segmentation enforced at Layer 3 via pfSense firewall rules
- Subnet:
10.80.80.0/24 - Gateway:
10.80.80.1(pfSense vtnet3)
| Host | IP Address | Role |
|---|---|---|
| Domain Controller | 10.80.80.2 |
AD DS, DNS, DHCP |
| Windows Client 1 | 10.80.80.32 |
Domain-joined workstation |
| Windows Client 2 | 10.80.80.43 |
Domain-joined workstation |
Simulated corporate Active Directory environment for attack and detection testing.
Note: The DHCP service on pfSense is disabled on AD Lab interface, we want the domain controller to act as the DHCP server.
Characteristics: Security Model:
- Inter-segment access controlled via pfSense firewall rules
- Supports LDAP (TCP 389), LDAPS (636), SMB (445), Kerberos (88)
- Designed for controlled exploitation (enumeration/attacks) and detection practice
Purpose: Dedicated network for intentionally vulnerable machines that require outbound internet access for testing egress filtering, malware simulation, and outbound detection scenarios.
- Subnet:
10.10.10.0/24 - Gateway:
10.10.10.1(pfSense)
| Host | IP Address | Role |
|---|---|---|
| VulnHub VM | 10.10.10.11 |
Vulnerable target |
| VulnHub VM | 10.10.10.12 |
Vulnerable target |
Security Characteristics:
- Outbound internet access permitted via pfSense NAT
- No inbound access from WAN
- Inter-segment access restricted via firewall rules
- Used to study outbound traffic patterns and egress controls
(In progress...)
The lab includes a SOC-style monitoring architecture designed to simulate enterprise network visibility and alerting.
-
Wazuh
- Central SIEM platform
- Aggregates logs from endpoints and infrastructure
- Performs rule-based correlation and alerting
-
Suricata
- Network Intrusion Detection System (NIDS)
- Receives mirrored traffic from pfSense
- Performs signature and protocol-based inspection
-
pfSense
- Routes traffic between internal network segments
- Enforces firewall policy at Layer 3/4
- Mirrors traffic to a dedicated SPAN interface for IDS analysis
- All inter-segment traffic traverses pfSense.
- pfSense mirrors selected interface traffic via SPAN.
- Suricata performs passive IDS inspection.
- Alerts are forwarded to Wazuh for centralized analysis.
- Endpoint telemetry supplements network-level visibility.
- Monitoring interface: Receives mirrored traffic (passive)
- Management interface:
10.0.0.3, accessed from Kali
This setup allows attacks launched from Kali to be observed, analyzed, and correlated within the SIEM.
├── README.md
├── .gitignore
├── diagrams/
├── notes/
│ ├── index.md
│ ├── networking/
| ├── firewall/
│ ├── active-directory/
| ├── attacks/
│ ├── detection/
│ └── images/
├── playbooks/
│ ├── attack/
│ ├── detection/
│ └── response/
- Vulnerable systems are segmented from the home network
- Internet access is blocked where unsafe
- All testing is performed only against lab-owned systems
No production or external systems are targeted.
This project is actively in progress. Notes, playbooks, and diagrams are added as new attack paths and detection scenarios are explored.
-
Ben Heater - Building a Security Lab in VirtualBox
https://benheater.com/building-a-security-lab-in-virtualbox/ -
RFC 1918 - Address Allocation for Private Internets
https://www.rfc-editor.org/rfc/rfc1918.html
The following below documents were introduced later to allow private hosts to reach the internet. Home Router NAT to the internet was not assumed at the time of RFC1918's writing.
-
RFC 3022 - Traditional NAT https://www.rfc-editor.org/rfc/rfc3022
-
RFC 2663 - NAT Terminology https://www.rfc-editor.org/rfc/rfc2663.html
Final Thoughts: Building this fully virtualized lab has been a great and affordable way to take the concepts I’ve learned from classes and certifications and apply them in a realistic setting. That said, there are definite limitations to a purely virtual environment. Working with VirtualBox NIC mappings, pfSense interface assignments, and manually defining subnets is effective for learning, but it doesn’t always translate cleanly to how real infrastructure behaves. In an on‑prem environment, VLANs, trunk ports, L2 switches, and dedicated hardware add a layer of structure that makes the concepts much more intuitive once you see it physically laid out.
As a beginner, thinking in terms of “virtual NICs mapped to pfSense interfaces” can be surprisingly confusing compared to how a real switch handles VLAN tagging, access ports, and trunk links. Hardware like a mini‑PC running pfSense, A server to run ProxMox, and a managed switch with VLAN capabilities would make the architecture feel more concrete. While virtualization is incredibly powerful, there are gaps of knowledge created depending on the specific hardware and networking gear that is used in production environments vs virtual labs.
Still, the process of building this lab has been a valuable challenge, and it’s helped me understand network segmentation, routing, AD administration, and defensive tooling in a more practical way. As I continue learning and saving :) , I’m looking forward to investing in actual hardware to fill in some of the gaps missing from my learning. This will open a few sections of the lab I'd like to implement anyways - such as a NAS for PLEX, NVR for cameras, or a DNS Sinkhole/Pi-Hole. Bitwarden’s self‑hosting option is another component I’m considering as I expand and evolve the home lab.