Having a virtualized cyber lab is a cornerstone project for any entry-level cybersecurity professional. It provides a safe environment for both offensive and defensive security testing, while also serving as an excellent hands-on exercise in network setup and administration.
For my lab, I’ve placed a particular emphasis on legacy systems and services. While my setup is constantly evolving, I think it’s worthwhile to document its current state and my thought process behind its design.
At its core, my lab is an isolated network, separated from the internet by a pfSense firewall. The firewall’s main role is to prevent malicious traffic from leaving the network while still allowing controlled internet access. This setup follows best practices and, in theory, ensures that I can test various security scenarios without disrupting my home network or upsetting owners of whatever other network I might decide to use it on. The diagram below illustrates my current lab setup:
Each device in the network serves a specific role. A Windows Server 2008 (Metasploitable 3) is configured with Active Directory (AD), providing both a legacy system and pre-existing vulnerabilities for testing. A Debian server, placed in a screened subnet (DMZ) at 10.10.1.10, is accessible from the WAN, simulating a public-facing system that would typically host services such as a web server or SSH access. Unlike the other machines in the network, it does not interact with the Active Directory domain, yet is still accessable from the LAN.
The LAN network (192.168.20.0/24) hosts internal systems, including a Windows 10 client and an Ubuntu client, with the Windows client configured to function within the AD domain. These machines provide a controlled internal environment for testing authentication, user policies, and workstation security. Also within the LAN is a Kali Linux machine, which serves as the attacker system used for penetration testing and network forensics. With both a publicly accessible server in the DMZ and internal AD-connected systems, the lab offers a realistic attack surface for testing security defenses, monitoring network traffic, and exploring vulnerabilities in both external and internal infrastructure.
For security purposes, all LAN devices remain isolated from the internet, ensuring that testing does not interfere with external networks. The pfSense firewall provides network segmentation, controls access between the LAN and DMZ, and prevents unintended data leakage while allowing for realistic network traffic analysis.
One thing that sets my lab apart from many others I've seen is its use of a legacy Active Directory server. Previously, I even ran a Windows 2000 Server, pushing the concept further.
Why? Because outdated, end-of-life systems are everywhere. Not just in fringe applications either, they can be apart of critical infrastructure for some networks.
In the real world, companies often rely on legacy software due to: Deprecated dependencies that newer systems can’t support, Manpower shortages that prevent proper updates, and Critical applications that weren’t designed for modern environments. A common cybersecurity sentiment is: "If you can’t keep up with updates, you’re inviting hackers in." While that’s generally true, sometimes upgrading just isn’t an option. Instead of accepting a guaranteed security failure, security professionals should ask: "What compensating controls can we implement?"
That’s the question I’m forcing myself to answer by including legacy systems in my lab. It’s a way to challenge myself while tackling a real-world problem that countless organizations face daily.
Since this lab is always evolving, I have two major improvements in mind—one small and one significant.
Adding a Windows 2000 Client – This would introduce another legacy system, creating more opportunities to harden outdated infrastructure and test various authentication scenarios.
Migrating from VirtualBox to VMware Workstation or Hyper-V – My current setup is limited to host-only adapters and internal networks, which is fine for simple networks but lacks the flexibility for more advanced architectures like virtual switches which enable VLANS. Moving to a more sophisticated hypervisor would provide a noticable upgrade in networking capabilities, though it would require rebuilding the entire environment from scratch. Theoretically this would also enable me to seperate VMs such as the proposed Windows 200 client into seperate VLANs.