The problem with lab screenshots
Most security portfolios show a tool running. That proves you can install a tool. What it does not prove is that you understand where that tool sits, what it can reach, what it cannot, and what happens when the thing it is watching goes wrong.
So I built the whole environment instead — the switch config, the trunk, the firewall rules, the domain, the SIEM, the vulnerable targets, and the documentation someone else would need to run it. Then I attacked it and checked whether my own monitoring noticed.
Architecture
Three Proxmox nodes form a cluster on a managed switch. The range lives on its own VLAN that rides tagged over each node's existing uplink — a deliberate design change from the original plan, which called for dedicated trunk cabling I did not have ports for.
The important detail is what the switch does not have: the range VLAN has no switch virtual interface. Without an SVI, the switch has no address on that VLAN and therefore no ability to route into or out of it, regardless of what any access list says. The only path in or out is the firewall.
The segments
- Management — the Proxmox nodes, the switch, backups. Untagged.
- The range — tagged VLAN, gatewayed exclusively by OPNsense running default-deny.
- Cluster mesh — a private subnet on direct node-to-node cabling, carrying a second Corosync ring.
- Detonation — the Hades malware network, physically separate and reachable from nothing.
Quorum should not depend on the switch. I ran a full mesh of direct cables between all three nodes and gave Corosync a second ring on it, weighted as the preferred link with the management network as fallback. If the switch dies, the cluster does not lose quorum with it.
The Active Directory lab
A Windows Server domain controller promoted to a new forest, plus an enterprise certificate authority. The OS install itself was fully unattended — an answer file on a second virtual CD, so the install needed no console interaction at all.
Then I broke it on purpose, in five specific ways, each mapping to a real attack path a red teamer would actually walk:
- Kerberoastable service accounts at three difficulty tiers — a trivially cracked password, a plausible seasonal one, and a longer one that needs real effort.
- An AS-REP roastable user with Kerberos pre-authentication disabled.
- Unconstrained delegation on one of the service accounts.
- An ACL abuse path — a help desk group holding GenericAll over Domain Admins.
- An ESC1 certificate template — enrollee-supplies-subject, no manager approval, client authentication EKU, and Domain Users able to enroll.
Each one was verified by reading the live object's flags back after publishing rather than trusting that the command had done what I meant. The domain password policy is also deliberately weakened — which is itself a realistic finding worth leaving in place.
A vulnerability you placed yourself is one you can explain end to end: why it exists in real environments, how it is exploited, what it looks like in the logs, and how you would remediate it. That is a very different conversation from "I ran this exploit once."
The detection layer
A Wazuh manager sits inside the range with agents on the Windows and Linux victim machines, and Sysmon feeding richer process and network telemetry from the Windows endpoints. Atomic Red Team provides the technique coverage.
The loop that matters is: run a known technique, check whether an alert fired, and when it did not, write the rule that would have caught it. A SIEM that only detects what it shipped with is not a detection capability, it is a log collector.
The hardware, and what it cost
Two of the cluster machines came from a university surplus sale at $80 each, and they share a single enclosure — two complete, independent computers inside one case I 3D-printed, adapted from an existing design to fit both boards, with about $26 of added cooling to make that volume thermally survivable. They are still two separate machines holding two separate votes in the cluster; they just occupy one box. The firewall node was about $100 with $40 of added memory. Storage and several memory sticks were repurposed from parts I already owned. The managed switch was a patient $60 find years earlier.
Roughly $820 all in, for hardware that would cost somewhere between $2,800 and $3,000 to assemble new today. That gap is not a trick — it is surplus sourcing, repurposing, and being willing to wait for the right listing. It is also the most directly transferable thing in this project, because every budget-constrained team on earth has the same problem.
Three things that went wrong
A blank field that broke the network for days
A Windows client on the range could not talk to anything, intermittently, in a way that looked like a Windows firewall problem and was investigated as one for a long time. It was not. The firewall's DHCP configuration had an empty subnet mask field, so clients were being handed a netmask of /16 or /0 instead of /24 — leases looked perfectly healthy, and the routing was quietly nonsense.
The same root cause explained an older, separate mystery: an ancient Linux target that completed DHCP successfully but never populated an ARP entry, which I had previously written off as a quirk of a 2008-era DHCP client. It was the same missing netmask the whole time.
"DHCP succeeded" and "DHCP handed out a usable configuration" are different claims. I now read the lease the client actually installed, not the server log saying it sent one.
An hour lost to a broken build pipeline
Building a well-known vulnerable target from its official source failed because an external dependency's package CDN had started returning a licensing error for anonymous downloads of every version. I worked around it through a package manager, then hit a wall of incompatible language runtime versions, then hit another. Dead end.
The fix took minutes once I stopped: a pre-built image of the same target was still published on a different distribution channel with no license wall, and the image format imported directly into the hypervisor. Check whether the artifact already exists before you fight the pipeline that produces it.
Installing Windows Server with no console
There was no working browser path to the hypervisor console in my tooling environment, so the entire post-install configuration — static addressing, promoting the forest, seeding the misconfigurations — was driven through the hypervisor's low-level monitor: screen dumps for sight, synthetic keystrokes for input.
Long keystroke bursts corrupted intermittently. Mouse positioning was unreliable even with correctly scaled absolute coordinates. The reliable pattern turned out to be keyboard-only navigation with input chunked into small groups, and for anything longer than a few words, writing the script to a file, building an ISO from it, hot-attaching it as a CD-ROM, and running it with one short command.
What came out of it
- A technical reference — full network and systems documentation with schematics, verified live against every system rather than written from memory.
- Two field guidebooks — fourteen structured exercises with exact commands, from web application fundamentals through a full domain compromise chain.
- A capstone report and presentation that scored 100/100, with the reflection section called the strongest part.
Those documents contain live credentials and host detail, so they are not published here. Ask me and I will walk you through them.
I can design a segmented network and verify the segmentation actually holds; stand up and deliberately weaken an Active Directory environment while understanding every weakness; instrument it well enough to detect the attacks against it; work through hardware, driver, and tooling failures without a console; and document all of it well enough for someone else to pick up.