~/joshua-eom
Esc

    ← All projects

    Security Home Lab

    A walkthrough of the design behind my Proxmox-based Active Directory attack-and-defense lab: hardware, network, resource planning, and what I'm adding next.

    Oct 2026in progress
    • homelab
    • llm
    • docker
    • active-directory
    • detection-engineering
    • soc
    On this page
    1. Why build a home lab?
    2. The Hardware
    3. The Hypervisor: Proxmox VE
    4. The Architecture
    5. Isolation
    6. What runs where, and why
    7. Why Windows Server 2022?
    8. Budgeting the resources
    9. Network design
    10. Wazuh and Ollama on one host
    11. What’s next
    12. Proxmox WebUI
    13. pfSense Firewall
    14. Windows Server 2022
    15. Windows 11 Host
    16. Ubuntu Host
    17. Kali Host

    Why build a home lab?

    My goal for this lab was to build a realistic enterprise-style network that I can break, revert, and rebuild, all on one small machine. This would also be a place where I can simulate modern threats that target enterprise environments and have a hub for security research. Through this, I hope to build a repertoire of knowledge associated to these topics:

    • Active Directory Security
    • DevOps/DevSecOps
    • Network Security
    • LLM/AI Security
    • Enterprise Security (SIEM/SOAR/Vuln+Patch Management/etc)

    This is not meant to be an exhaustive list but to be what my initial focus was. But I’m sure that as the lab grows, so will my breadth of knowledge/understanding and more specialized learning

    The Hardware

    The whole lab runs on a single KAMRUI Hyper H2 Mini PC I bought off Facebook marketplace for a couple hundred dollars:

    • CPU: Intel i5-14450HX, 10 cores / 16 threads (6P + 4E), up to 4.8 GHz
    • RAM: 32 GB
    • Storage: 1 TB NVMe

    The Hypervisor: Proxmox VE

    I’m running Proxmox VE 9.2 (the free edition) on bare metal. It’s a hypervisor-focused OS built on KVM, with snapshots, templates, and a web UI, which makes it ideal for a lab where you constantly want to build/stop instances.

    The Architecture

    Isolation

    Everything inside the lab lives on vmbr1, a virtual switch with no physical NIC. The only way in or out is through pfSense, which handles routing, NAT, and DHCP, and acts as a firewall that blocks unwanted traffic into the lab. That’s important when the whole point is to run attacks.

    What runs where, and why

    Component Deployment Why
    pfSense Standalone VM FreeBSD-based; needs dedicated virtual NICs
    Windows Server 2022 DC Standalone VM Needs the Windows kernel for AD, DNS, and Kerberos
    Windows 11 targets Standalone VMs Authentic endpoint behavior for attack testing
    Kali Linux Standalone VM GUI, raw sockets, and the usual tooling
    Wazuh (SIEM) Docker Compose in an Ubuntu VM Microservices are simpler to update and isolate as containers
    Ollama (local LLM) Docker container, same Ubuntu VM Lightweight API; sharing a host saves about 1.5 GB of RAM
    Action1 Cloud + agent No local server needed; the agent just calls out over 443

    Why Windows Server 2022?

    I chose 2022 for its backward compatibility with legacy software, and because it closely resembles what many enterprises still run. Its mainstream support ended on October 13, 2026, and features like Credential Guard aren’t on by default, which makes it a great target for practicing real-world AD attacks.

    Budgeting the resources

    The trick with a single-box lab is not overcommitting. Here’s the plan:

    VM vCPUs RAM
    pfSense 1 4 GB
    Domain Controller 2 4 GB
    Windows Target 1 2 4 GB
    Windows Target 2 2 4 GB
    Kali Linux 2 4 GB
    Security Services (Wazuh + Ollama) 4 8 GB
    Proxmox overhead — ~2 GB
    Total 13 of 16 threads 30 of 32 GB

    That leaves 3 threads and 2 GB of headroom.

    Network design

    I use a numbering convention so I can tell what a machine is just by looking at its IP or VM ID:

    • 100s: network boundary (firewall, proxies)
    • 200s: always-on shared infrastructure (DC, SIEM, DNS)
    • 300s: targets I can hack, break, and destroy
    • 400s: attacker systems
    • 9000s: templates and gold images
    Machine IP
    pfSense LAN gateway 10.10.10.1
    Domain Controller 10.10.10.10
    Windows 11 target 1 10.10.10.20
    Windows 11 target 2 10.10.10.21
    Kali Linux 10.10.10.50
    Ubuntu host 10.10.10.100

    The upstream/management network is kept separate from the lab, so my daily-use PC never shares a subnet with the machines I’m attacking.

    Wazuh and Ollama on one host

    The Ubuntu host runs Wazuh’s manager, indexer, and dashboard alongside an Ollama container serving a small local LLM. The idea is to use the model for log triage and de-obfuscating suspicious scripts, without sending any lab data to a third party.

    What’s next

    The base infrastructure is mostly planned; the fun part is layering on tooling:

    • A Open Source LLM model, connected to LibreChat through Ollama’s API
    • TailScale to remotely connect to hosts on LAN
    • Active Directory Setup
    • Wazuh for host-based detection and logging
    • Zeek for network-based detection and logging
    • Action1 for remote patch management
    • Shuffle for SOAR automation
    • TheHive for case management
    • Atomic Red Team to replicate adversary techniques, and BadBlood to populate Active Directory with realistic users and objects

    Screenshots of work

    Proxmox WebUI

    pfSense Firewall

    Windows Server 2022

    Windows 11 Host

    Ubuntu Host

    Kali Host

    Wrap-up

    A single mini PC, a free hypervisor, and a bit of planning is enough to build a lab that mirrors a small enterprise network. This lab is still a work in progress and I’m looking forward to seeing what I can learn and build from this experience. You can follow along through my blog or medium page!