Building a Malware Reversing Lab on Proxmox
A walkthrough of the full architecture for a dual-purpose home lab: a Windows-based reversing environment for static and dynamic malware analysis, running alongside a detection engineering stack on the same bare-metal server and feeding telemetry into Elastic SIEM.
This lab is built around a simple goal: move from malware behavior to validated defensive logic. It combines a controlled reverse engineering environment with a detection engineering workflow so that every detonation can produce telemetry, hypotheses, and immediately testable detections.
Why this matters
Reverse engineering is more valuable when it improves coverage, tuning, and confidence in real detection logic.
Research fit
This mirrors how I approach security work: rigorous technical analysis tied directly to practical operational outcomes.
Core loop
Detonate, observe, collect telemetry, validate detections, revert, and repeat from a known baseline.
- Isolated malware execution with a constrained blast radius.
- One-way telemetry into Elastic for live rule validation.
- Repeatable snapshot-based analysis sessions.
- A workflow that aligns malware reverse engineering with threat detection engineering.
Contents
1. Design Principles
Before allocating a single VM, it helps to define what the lab is actually trying to accomplish, because that shapes every architectural decision that follows.
The core goal here is a closed-loop pipeline: analyze a malware sample, observe its behavior, and immediately validate whether your detection rules in Elastic would have caught it. This requires two capabilities to coexist on the same infrastructure, a reversing environment and a detection engineering stack, while remaining strictly isolated at the network layer.
Three principles govern the architecture:
- Hard network isolation. Malware executes in a segment with no direct path to the public internet or the rest of the lab.
- One-way telemetry. Logs flow out of the reversing environment into the SIEM. Nothing flows back in.
- Snapshot-driven analysis. Every detonation begins from a known-clean baseline and ends with a revert.
This lab is intentionally described in terms of workflow and security boundaries rather than hardware inventory. The value is in the method, not the exposed infrastructure details.
2. Network Architecture
Proxmox manages isolation through Linux bridges. The setup uses one management network for the detection stack and one internal-only network for controlled malware execution.
vmbr1acts as the management bridge for the detection lab and supporting services.vmbr2is an internal-only bridge with no physical uplink. Malware executes here.
Creating the isolated bridge in Proxmox requires adding a bridge without a port assignment
in /etc/network/interfaces:
# Add below existing vmbr1 config in /etc/network/interfaces
auto vmbr2
iface vmbr2 inet static
address 10.10.20.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
The absence of bridge-ports is what makes it internal-only. Traffic can flow between
VMs on vmbr2, but it never touches a physical NIC.
The Windows Dynamic VM gets two NICs: one on vmbr2 for execution and one on
vmbr1 for outbound telemetry. The management-facing NIC has no default gateway and
exists purely to move logs into Elastic.
3. The Reversing VMs
The reversing environment follows a two-VM model: a Static VM and a Dynamic VM that are full clones of each other, differentiated by which additional tools are installed and by desktop color, black for Static and green for Dynamic. The visual split sounds minor, but it reduces operator error during an active session.
Why two VMs instead of one?
Static analysis, examining PE headers, strings, imports, and disassembly, should never happen in the same environment where samples execute. Once a Dynamic VM has run malware, its registry, filesystem, and network state are potentially dirty. A Static VM that never executes anything preserves a clean context for analysis.
Base VM configuration
Both VMs run Windows 11 Pro with the following hardening applied before cloning:
- UAC disabled via the settings slider (set to Never notify).
- Windows Defender disabled through Group Policy, registry edits, and scheduled task cleanup.
- Windows Update constrained by marking the interface as metered.
- File extensions shown in Explorer.
- OneDrive and telemetry-heavy inbox applications removed.
- Local account only, with no Microsoft account association.
Disabling Defender requires policy-level persistence, not just the Settings UI toggle. If the protection stack comes back after reboot, the baseline is no longer trustworthy.
The Dynamic VM is provisioned more generously because it carries a heavier concurrent workload: debugger activity, file and registry monitoring, packet capture, protocol interception, and Elastic telemetry forwarding at the same time.
4. Tooling Breakdown
All tools live under C:\Tools\, with C:\Tools\bin\ on the system
PATH for CLI tooling. That keeps the environment predictable and removes friction during active analysis.
Static analysis tools (both VMs)
Dynamic analysis tools (Dynamic VM only)
Elastic Agent is the one addition beyond the standard malware analysis toolchain. It captures process, network, file, and registry activity and forwards it into Fleet in near real time as a sample executes.
5. The Detection Engineering Lab
The detection engineering side of the lab predates the reversing environment and runs alongside it on the management network.
- elastic-stack receives telemetry, hosts Fleet, and serves as the detection engineering workspace.
- supporting Windows systems provide victim and validation endpoints for controlled testing.
- supporting Linux systems provide operator and infrastructure support for the wider lab.
This side of the environment follows the same philosophy as my broader work: use disciplined, observable systems to produce useful defensive outcomes rather than isolated technical artifacts.
6. The Telemetry Bridge
This is the part of the design that makes the lab more than two parallel environments.
When malware executes on the Dynamic VM, Elastic Agent captures events in near real time. Within seconds of a sample spawning a child process, writing persistence keys, or attempting a network connection, those events are queryable in Kibana. You can run KQL detections against the live stream and see immediately whether the logic fires, misses, or over-alerts.
That feedback loop is difficult to reproduce with synthetic datasets. Real malware produces real telemetry, along with the timing artifacts and edge cases that simulations often smooth over. Repeatedly testing against that reality builds stronger, more durable detection logic.
This is the strongest alignment point with my own background: not just understanding behavior, but converting that understanding into measurable defensive improvement.
A few implementation details worth noting:
- The management-facing NIC on the Dynamic VM has no default gateway; it exists purely for telemetry transport.
- Fleet enrollment uses a policy centered on Windows telemetry collection and detection validation.
- The Static VM intentionally has no Elastic Agent because it should never produce execution telemetry.
7. Snapshot Workflow
The snapshot discipline is what keeps the reversing environment trustworthy over time. The workflow must be followed without exception:
- Revert the Dynamic VM to the Dynamic Baseline snapshot before every session.
- Take a Regshot first snapshot before executing anything.
- Start Process Monitor and Wireshark captures.
- Launch FakeNet-NG with administrator privileges.
- Execute the sample.
- Observe behavior and allow Elastic Agent time to forward events to the SIEM.
- Take a Regshot second snapshot and compare the diff.
- Save the PCAP, ProcMon log, and any memory dumps.
- Review which KQL detection rules fired in Kibana.
- Revert to Dynamic Baseline.
In Proxmox, snapshot creation and revert are both straightforward from the CLI:
# Create the named baseline snapshot
qm snapshot <vmid> "Dynamic Baseline" \
--description "Clean state, all tools installed, Defender off, Agent enrolled"
# Revert before every analysis session
qm rollback <vmid> "Dynamic Baseline"Rolling back a snapshot resets the VM state, including the local event buffer. That is expected. The useful telemetry has already been forwarded, and the baseline restores the environment to a trustworthy starting point.
8. Closing Thoughts
The most valuable part of this architecture is the feedback loop between the reversing environment and the detection stack. Reverse engineering in isolation explains what a sample does. Watching your SIEM respond in real time shows whether your detections would actually catch it in practice.
A few things worth improving next:
- Add faster storage for analysis-heavy workloads.
- Extend the fake network layer for more complex protocol emulation.
- Archive PCAPs and artifacts in a way that supports cross-sample correlation over time.
Follow-up posts will cover network segmentation in more detail, writing Elastic detections from malware telemetry, and extending the lab for evasion analysis. If you run a similar setup or want to compare approaches, feel free to reach out.
This environment supports the kind of work I want to keep doing: reverse engineering, telemetry-driven validation, and secure systems thinking that can hold up under real operational constraints.