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 network enumeration, Active Directory attacks, 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
- Explore common Active Directory attack paths
- 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-3)
- 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
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://datatracker.ietf.org/doc/html/rfc1918