Malware Analysis in an Isolated Lab: Safe Setup with FlareVM and REMnux

You pulled a suspicious sample from a real phishing campaign, unzipped it on your desktop, and realized too late that Defender already shipped the hash off to MAPS. Congratulations: you just burned an indicator, polluted telemetry, and possibly tipped off the adversary. Before you touch any binary with a .exe, .iso, or .lnk extension, you need an isolated, reproducible, disposable lab. The pairing of FlareVM for Windows analysis and REMnux for Linux network and defensive tooling has been the de facto standard since 2020. This guide builds it from scratch on VirtualBox with versioned snapshots and a host-only network that routes nowhere real, then walks the full detonation workflow that turns an opaque blob into named capabilities and shareable indicators.

Why isolation is non-negotiable

Malware is code written to do something to a host, and the moment it runs on a machine that can reach your files, your network, or the internet, you have handed it exactly what it wants. Analysts get burned in three ways: the sample calls home and alerts its operator that it detonated, it spreads laterally across a bridged network into real assets, or a cloud antivirus silently uploads it and destroys the confidentiality of the investigation. The lab exists to break all three. Everything happens inside virtual machines with no shared folders, no clipboard, no drag and drop, no USB passthrough, and a network that terminates at a fake-services box rather than a gateway. If a sample cannot tell it is being watched and cannot escape, you own the encounter.

Hypervisor and network layout

VirtualBox 7.1 or VMware Workstation 17 both work; avoid raw KVM unless you already own libvirt and VLANs, because misconfiguring a bridge and exposing the sample to your home LAN is a real and common mistake. Create two virtual machines: a Windows 10 22H2 box (not 11, since some implants fingerprint the build) with four vCPUs, 8 GB of RAM, and an 80 GB dynamic disk that becomes FlareVM, and an Ubuntu box that becomes REMnux. Disable every host integration. Use a host-only network without DHCP and assign 10.66.66.10 to Windows and 10.66.66.20 to REMnux by hand. There is no default route to the internet; the only thing Windows can talk to is the Linux box pretending to be the whole world.

Building the FlareVM analysis box

FlareVM installation demands a fresh Windows install, not domain joined, with no pending updates, and Defender temporarily disabled through local policy so the installer is not fighting real-time protection. Mandiant's install.ps1 from the FLARE-VM repository pulls dozens of Chocolatey packages: x64dbg, IDA Free, Ghidra, dnSpy, PE-bear, Detect It Easy, FLOSS, CAPA, and pestudio. Budget roughly two hours and 30 GB of download. When it finishes, take a snapshot named Clean-FlareVM-Base before you ever run a sample. That snapshot is your sacred rollback: every detonated sample reverts to it, guaranteeing that experiment two starts from the same state as experiment one. Record each tool version in a versioned file, because CAPA 7.x and 8.x produce incompatible outputs and reproducibility depends on knowing exactly what ran.

REMnux and INetSim: faking the internet

REMnux serves as the passive tap and the fake-services server. Instead of installing from scratch, grab the official OVA appliance from Lenny Zeltser, import it, and on first boot run remnux update then remnux upgrade. Configure INetSim in /etc/inetsim/inetsim.conf to bind on 10.66.66.20 with HTTP, HTTPS, DNS, SMTP, IRC, and FTP enabled. On the FlareVM side, point the default gateway and DNS at that address. The net result is that any command-and-control server the malware tries to reach lands in INetSim, which answers with fake binaries and logs every byte. You get the same visibility a web proxy gives you, but at the raw packet level, and the sample believes it reached its operator when it only ever spoke to your trap.

Traffic capture is the second pillar

Run Wireshark on REMnux in promiscuous mode on the host-only adapter, and run tcpdump in parallel writing 100 MB rotated PCAPs so nothing is lost if the GUI stalls. Layer Suricata as an IDS with the ET Open ruleset, adding Emerging Threats Pro if you hold a research license, so known families light up by signature. For samples that speak TLS, stand up mitmproxy with a root certificate pushed into the Windows trust store. Yes, that breaks certificate pinning, but most commodity stealers such as Redline, Vidar, and Lumma never implement it, so you read their beacons in cleartext. Heavier gear like Cobalt Strike beacons or Sliver implants may require unhooking and more deliberate handling, which is a separate discipline from triage.

Static analysis before you run anything

Copy the sample with shared folders disabled; use scp from REMnux to FlareVM over a temporary SSH service and then kill that service. Compute the SHA-256 with Get-FileHash and log it alongside source, date, and your initial hypothesis. Run FLOSS to extract obfuscated and stack strings, CAPA to map capabilities to MITRE ATT&CK techniques, and Detect It Easy to fingerprint the packer and compiler. PE-bear reveals the section table, imports, and entropy: a text section with entropy above 7.0 screams packing. pestudio flags suspicious imports like VirtualAllocEx and WriteProcessMemory that hint at process injection. None of this executes the code, and a surprising amount of the verdict is already visible before the first instruction runs.

Dynamic analysis: the detonation workflow

Now start the monitors and detonate. Launch Procmon with a filter on the sample's process tree and Process Hacker to watch handles, threads, and injected memory in real time, then run the binary. Watch for the file-system and registry indicators as they appear: a copy into %APPDATA%, a Run key for persistence, a scheduled task, a mutex that prevents double execution. Correlate that with the network trace in INetSim to see the callback pattern. If the sample is packed, static analysis stalls at the unpacking stub; a UPX-packed binary yields to upx -d, while a custom packer needs x64dbg with ScyllaHide to defeat anti-debugging, a breakpoint at the original entry point, and a memory dump at that moment. When you finish, revert to the clean snapshot and verify the box is pristine before the next run.

Operational security separates the pro from patient zero

Hygiene is what keeps you from becoming the victim. Never connect the analysis VM to your real LAN, never log into a personal account inside it, and treat every hash as potentially tied to an actor capable of retaliation. VirusTotal submissions are public, so assume a sophisticated adversary monitors their own hashes and learns the moment you upload; use it only when the sample is already widely known. Collect from Malware Bazaar, triage on Any.Run for public detonation when your rules of engagement allow it, and keep samples encrypted in offline VeraCrypt containers so a stray double-click never runs live malware against your own workstation.

Pitfalls and a reproducibility checklist

The classic mistakes are predictable: leaving shared folders on so the sample escapes to the host, forgetting to snapshot so the second run is contaminated by the first, trusting a single tool's verdict, and running samples with internet access because INetSim felt like too much setup. Before you call the lab ready, confirm that host integrations are all off, that Clean-FlareVM-Base exists, that INetSim answers on every configured protocol, that Wireshark and tcpdump both capture, and that a known sample from Malware Bazaar tagged Emotet or AgentTesla behaves identically across two consecutive detonate-and-revert cycles. If you cannot reproduce the same result twice, the lab is not ready and any real investigation you run on it is already suspect.

From triage to memory forensics

Behavioral triage tells you what a sample does; memory forensics tells you what it hid. Many modern loaders never write their real payload to disk, decrypting it directly into a freshly allocated region and running it there, so a snapshot of RAM is the only place the unpacked code exists. Capture it at the peak of infection with a tool such as WinPMEM or DumpIt, then analyze the raw image with Volatility 3. The workhorse plugins are windows.pslist and windows.pstree for the process hierarchy, windows.malfind to surface injected and executable-but-unbacked memory, windows.netscan to recover the C2 sockets INetSim already logged, and windows.dlllist to spot suspicious module loads. Because you took the capture inside a snapshotted VM, you can re-run the detonation and grab a second image at a different stage, then diff the two to watch persistence and injection unfold. Memory analysis closes the loop that static and dynamic triage leave open, and it is where fileless threats finally become visible.

FAQ

Can malware detect that it is running in a VM and refuse to detonate? Yes; many families check for VirtualBox artifacts, low core counts, small disks, or short uptime and go dormant. Counter it by using a realistic hardware profile, hiding hypervisor strings, warming the machine before detonation, and, for stubborn samples, moving to a bare-metal analysis host that you reimage between runs.

Do I still need a lab if I can just upload to a sandbox service? Public sandboxes are great for triage but they are public, they may miss environment-specific triggers, and they take the confidentiality decision out of your hands. A local lab gives you full packet visibility, private handling, and the ability to interact with the sample, which automated sandboxes cannot.

Practical takeaway: spend your first weekend building the lab and beating known samples from Malware Bazaar, because the Emotet and AgentTesla tags are excellent training wheels. Run three cycles of detonate, revert, and verify that INetSim captured the traffic exactly as expected before you ever touch a real client sample. Reproducibility beats speed every single time, and a lab you can trust twice is worth more than a fast answer you cannot defend.