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.
Contents
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:
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.
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.
vmbr1 acts as the management bridge for the detection lab and supporting services.vmbr2 is 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.
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.
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.
Both VMs run Windows 11 Pro with the following hardening applied before cloning:
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.
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.
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.
The detection engineering side of the lab predates the reversing environment and runs alongside it on the management network.
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.
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 snapshot discipline is what keeps the reversing environment trustworthy over time. The workflow must be followed without exception:
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.
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:
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.