DRACARYS

By

Brian Johnson

DRACARYS is an awesome pentest training challenge.

Add the Windows 2025 and Ubuntu 24.04 template to Ludus

The install instructions walk you through this, but if you don't do this step, your DRACARYS install will fail:

ludus source add ludus-source-bsl --templates win2025-server-x64-tpm-template,ubuntu-24.04-x64-server-template

Install

For the basic install you can follow our GOAD install guide to get the nuts and bolts of the lab installed, just use set_lab DRACARYS instead of setting the lab to GOAD before install.

Snapshot the environment (optional)

I like to create a snapshot called level0 before I actually start hackin' stuff, so I use a command like this:

ludus --user XXX snapshots create <snapshot-name>

However, what I found with DRACARYS is that the snapshotting of the DC and app server failed. This is due to the TPM config on these VMs. So I did this:

qm stop 108 && qm stop 109
sleep 10
qm set 108 --delete tpmstate0
qm set 109 --delete tpmstate0

This allowed me to take a full snapshot of the range.

Advanced networking

By default, nothing in a Ludus range can see your real network. If you need a lab VM to pull a DHCP lease from your actual LAN — a Kali box that needs to reach a physical target, or a VM you want to hit from your laptop without going through a router VM — you can bridge the host's physical NIC into Proxmox and attach VMs to it directly.

This is a manual Proxmox change. Bridging a physical NIC into a range isn't a Ludus feature yet (open request).

Do this from IPMI/iDRAC or a physical console, not over SSH. If the NIC you're converting is your only wired uplink, a typo will lock you out of the box.

The examples below use placeholder values — swap in your own:

Why the stock Ludus bridges won't work

• vmbr1000 — the Ludus NAT bridge (192.0.2.254/24). MASQUERADEs lab traffic out to the internet.
• vmbr1001, vmbr1002, ... — per-user bridges, routed through each user's router VM (192.0.2.10X).

None of these share an L2 segment with your physical LAN, so VMs on them will never see your LAN's DHCP server. You need a new bridge that has the physical NIC as a member port.

Create vmbr0 with the physical NIC as a bridge port

Back up the current config first:

cp /etc/network/interfaces /etc/network/interfaces.gold

Then edit /etc/network/interfaces. The NIC goes from holding the IP directly to being a bridge port, and the host IP moves onto the new bridge:

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.20/24
        gateway 192.168.1.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Put this above the # LUDUS MANAGED markers so Ludus doesn't clobber it on the next config run.

Apply it with ifreload -a (ifupdown2 — no reboot needed). The host stays reachable at the same IP, since the address just moved onto the bridge.

If your switch port is a VLAN trunk rather than an access port, add bridge-vlan-aware yes and bridge-vids to the vmbr0 stanza and tag the VM NICs instead.

Gotcha #1: the lab loses internet after the bridge change

The Ludus NAT rule is pinned to whatever interface was doing the routing when Ludus was installed:

-A POSTROUTING -s 192.0.2.0/24 -o eno1 -j MASQUERADE

Once eno1 is a bridge port, internet-bound traffic egresses via vmbr0 instead, the rule stops matching, and lab VMs leave un-masqueraded and go dark.

Point the MASQUERADE at the bridge. Both lines in the vmbr1000 stanza:

post-up   iptables -t nat -A POSTROUTING -s '192.0.2.254/24' -o vmbr0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.0.2.254/24' -o vmbr0 -j MASQUERADE

Gotcha #2: duplicate MASQUERADE rules

That post-up appends a rule on every ifup / ifreload, so a few rounds of testing will leave you with stacked duplicates pointing at the old interface. If POSTROUTING contains nothing else, flush and re-add:

iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o vmbr0 -j MASQUERADE

Make sure the on-disk config matches so it survives a reboot:

sed -i 's/-o eno1 -j MASQUERADE/-o vmbr0 -j MASQUERADE/g' /etc/network/interfaces
grep MASQUERADE /etc/network/interfaces   # both lines should say -o vmbr0

Verify

ip a                              # host IP on vmbr0; the NIC shows "master vmbr0" and no IP
ip r                              # default route via your gateway, dev vmbr0
iptables -t nat -S POSTROUTING    # exactly ONE MASQUERADE rule, -o vmbr0

Then from any lab guest, ping 1.1.1.1 to confirm routing and NAT, followed by ping google.com to confirm DNS.

Attaching a VM to the LAN

• Plain Proxmox VM: Hardware → Network Device → Bridge = vmbr0, VLAN Tag empty. It'll DHCP from your LAN gateway.

• Ludus range VM: add the vmbr0 NIC by hand in the Proxmox UI after the range deploys. It will not survive a range destroy/redeploy — treat it as a per-deploy manual step.

Rollback

cp /etc/network/interfaces.gold /etc/network/interfaces && ifreload -a

Security note

This is an offensive lab, and the Ludus NAT is doing real work keeping that traffic off your production network. Hanging a single throwaway VM off vmbr0 because it needs a real lease is one thing. Putting the whole range on it is another — don't.