Project Case Study

Proxmox Pentesting Lab – Isolated Attack & Target Network

I built an isolated penetration testing lab on my Proxmox server for authorized cybersecurity coursework. The goal was to import a set of VMware-based lab machines, separate them from my home network and Wazuh SOC lab, and create a controlled environment where Kali can communicate with vulnerable Linux, web application, and Windows targets.

Back to Projects

Objective

Build a safe, repeatable pentesting environment that supports intrusion testing coursework without exposing vulnerable systems to my home network. The lab needed to run beside my existing SOC lab, while remaining separated enough that scans, exploits, and vulnerable services stay contained inside a dedicated virtual network.

Core stack

  • Proxmox VE on a dedicated custom-built server
  • Kali Linux attacker workstation
  • OWASP Broken Web Apps vulnerable web target
  • Ubuntu / Metasploitable vulnerable Linux target
  • Windows Server 2012 R2 target machine
  • Windows 10 target workstation
  • vmbr2 as the isolated pentesting bridge

What I built

  • Created a dedicated Proxmox Linux bridge for the pentesting lab so it stays separate from management and SOC traffic.
  • Imported VMware .vmdk virtual disks into Proxmox using qm importdisk.
  • Configured each VM with the correct CPU, RAM, network adapter, boot mode, and storage settings.
  • Assigned static IP addresses to each machine on the isolated 192.168.56.0/24 subnet.
  • Verified connectivity from Kali to each target machine.
  • Created clean initial snapshots so each VM can be restored after lab exercises.

Network design

I kept the lab intentionally segmented. vmbr0 is used for Proxmox management and normal network access, vmbr1 is reserved for my Wazuh SOC lab, and vmbr2 is used for the pentesting course lab. Target machines do not need a default gateway because they only need to communicate inside the lab subnet. 

vmbr0: Proxmox management / home network

vmbr1: Wazuh SOC lab

vmbr2: Pentesting lab network

Kali:              192.168.56.10

Ubuntu:            192.168.56.20

Windows 10:        192.168.56.30

Windows Server:    192.168.56.40

OWASP BWA:         192.168.56.50

Issues I had to solve

This setup required more than importing a few VMs. I had to troubleshoot networking, storage, boot modes, and firewall behaviour across Linux and Windows machines.

  • Recovered Proxmox access after an ISP/router change by switching the management bridge to DHCP and finding the new web UI address.
  • Resolved failed ARP/gateway access when the old static IP no longer matched the new network layout.
  • Worked around storage pressure by deleting already-imported source archives and extracted VMware folders.
  • Imported split VMware disks by selecting the main descriptor .vmdk file instead of the numbered disk chunks.
  • Configured persistent static IPs for Kali, Ubuntu, OWASP BWA, Windows Server, and Windows 10.
  • Enabled ICMP echo requests on Windows Server so Kali could verify connectivity with ping.
  • Fixed the Windows 10 boot loop by changing the VM from SeaBIOS to OVMF/UEFI and adding an EFI disk.

Why this project matters

This project shows that I can build and troubleshoot a realistic virtual cybersecurity lab rather than relying only on preconfigured desktop tools. It demonstrates virtualization, network segmentation, VM migration, Windows/Linux networking, and safe handling of vulnerable machines. It also creates a foundation for connecting offensive testing activity with defensive monitoring in my SOC lab later.

Build Breakdown

Version 1 architecture and process

The lab was built around a simple rule: vulnerable machines stay on the pentesting bridge, while Proxmox management and SOC infrastructure remain on their own networks.

Step 1

Dedicated lab bridge

Created vmbr2 as a separate virtual switch for the pentesting lab, keeping it away from both Proxmox management traffic and the Wazuh SOC lab bridge.

Step 2

VMware disk imports

Extracted course VM archives, identified the main VMware .vmdk descriptor files, and imported the disks into Proxmox using qm importdisk.

Step 3

Static lab addressing

Assigned each lab machine a stable IP address on 192.168.56.0/24 so exercises can reference the same targets reliably.

Step 4

Connectivity and snapshots

Tested connectivity from Kali to each target, fixed firewall and boot issues, then created clean initial snapshots before lab work.

Lab Inventory

Virtual machines and roles

Each VM has a defined role in the lab and a predictable static IP address.

Kali Linux

Attacker workstation for authorized scanning, enumeration, web testing, and exploitation exercises.

192.168.56.10

Ubuntu / Metasploitable

Vulnerable Linux target used for service discovery, exploitation practice, and post-exploitation exercises.

192.168.56.20

Windows 10

Windows workstation target used for Windows-based testing and client-side lab scenarios.

192.168.56.30

Windows Server 2012 R2

Windows server target used for server-side enumeration, firewall testing, and Windows network practice.

192.168.56.40

OWASP Broken Web Apps

Vulnerable web application target used for web security testing inside the isolated lab network.

192.168.56.50

Evidence

Proof snapshots

Add screenshots here showing the Proxmox bridge setup, VM hardware summaries, ping tests from Kali, Windows firewall rule, and successful boot/login screens. Avoid posting passwords, course download links, or any private school materials.

Proxmox network page showing the vmbr2 isolated pentesting bridge
Dedicated vmbr2 bridge for isolated pentesting lab traffic.
Kali terminal showing successful ping tests to lab target machines
Kali successfully reaching target VMs on the isolated lab subnet.
Proxmox Windows 10 VM hardware settings showing OVMF UEFI configuration
Windows 10 boot issue resolved by switching the imported VM to OVMF/UEFI.
Proxmox snapshots page showing clean initial state snapshots for pentesting lab VMs
Clean initial snapshots created before beginning course testing.

Next Stage

What comes next

Course labs

Use the environment for authorized intrusion testing assignments and document the workflow clearly.

SOC integration

Explore controlled monitoring scenarios where selected lab activity can be observed by the Wazuh SOC environment.

Detection notes

Turn lab activity into short incident-style notes showing what happened, what was detected, and what the response would be.