20 June 2026 · 2 min read
Hardening backup infrastructure against ransomware: lessons from a Zero Trust lab
Ransomware · Zero Trust · Proxmox · Blue Team
Modern ransomware operators don't start by encrypting your production data. They start by finding your backups — because a victim who can restore in an hour doesn't pay. MITRE ATT&CK catalogues this as T1490, Inhibit System Recovery, and it is now standard tradecraft: delete volume shadow copies, wipe backup repositories, then encrypt.
For my master's thesis I built the defence and the attack. This note summarises the architecture decisions that survived contact with a simulated adversary, and the ones that didn't.
The lab
The environment is bare-metal, deliberately small, and fully reproducible:
- Proxmox VE as the virtualisation layer for production workloads
- Proxmox Backup Server (PBS) as a dedicated, physically separate backup target
- pfSense enforcing micro-segmented networks between the two
- A scripted attacker that executes destructive, wiper-mode ransomware behaviour against reachable backup surfaces
The point of building the attacker myself was honesty: a defence you have never tested against a concrete, well-understood attack is a hypothesis, not a control.
What actually mattered
1. Immutability beats permissions. Access controls failed in interesting ways; immutable datastores did not. If the storage layer physically refuses deletion inside the retention window, a compromised credential stops being a catastrophe.
2. The backup server must not trust the hypervisor. In the naive design, PBS credentials lived on the PVE host — so owning production meant owning recovery. Inverting the trust relationship (scoped API tokens, pull-based where possible, no shared administrative credentials) closed the single most damaging path.
3. Micro-segmentation limits the search space. With pfSense rules reduced to exactly the flows PBS needs, the attacker's lateral options shrank to a handful of ports — all instrumented. Detection becomes easier when the allowed graph is small enough to reason about.
4. RBAC only helps if roles are boring. Broad "backup admin" roles recreated the problem they were meant to solve. The final design uses narrow, single-purpose roles whose union — not any single one — is required to destroy data.
5. Recovery time is a security property. I measured restore paths under attack conditions until the recovery time objective was both optimal and boringly repeatable. An untested RTO is marketing.
The uncomfortable lesson
The most effective simulated attack didn't touch a single vulnerability. It used legitimate credentials, legitimate APIs and legitimate deletion endpoints — exactly as real operators do. The controls that stopped it were architectural (immutability, trust inversion, segmentation), not signature- or patch-based. Hardening guides that end at "update your systems" miss where this fight actually happens.
The full operational hardening guide from the thesis is being prepared for open-source release. If you want to discuss the details before then, write to me.