Setting up an isolated malware analysis lab

Setting Up an Isolated Malware Analysis Lab

When to Use

• You need to run unknown or known-malicious binaries to observe behavior without risk to production systems or the internet.
• You are standing up a repeatable analysis environment for static and dynamic work.
• You want a reverting, snapshot-based workflow so each sample starts from a clean state.

Do not use this as guidance for detonating samples on a host OS or a cloud VM with live egress; that risks self-spreading malware escaping. Use a dedicated, network-isolated hypervisor instead.

Prerequisites

• A host with a type-2 hypervisor (VMware Workstation/Fusion or VirtualBox) or a dedicated type-1 host. At least 16 GB RAM and 200 GB disk for two guests.
• A victim guest (Windows 10/11) for detonation — e.g. built with FLARE-VM tooling.
• An analysis services guest (REMnux, Linux) to simulate internet services and capture traffic.
• Host networking able to provide a host-only / internal network with no NAT or bridged adapter on the victim.

Safety & Handling

• The victim VM must have no bridged or NAT adapter — host-only/internal only. All "internet" is simulated by the REMnux guest running INetSim.
• Disable shared folders, drag-and-drop, and clipboard sharing on the victim before detonation; these are escape and contamination paths.
• Take a clean base snapshot before any sample touches the VM and revert to it after every run.
• Store samples in password-protected archives (infected) and only extract them inside the victim VM.

Workflow

Step 1: Create and harden the victim VM

Install Windows in a new VM, apply analysis tooling, then strip escape paths:

VM settings (victim):
  Network adapter   -> Host-only (vmnet1) or Internal network
  Shared folders    -> Disabled
  Clipboard/DnD     -> Disabled
  USB controller    -> Disabled
  Snapshots         -> enabled

Step 2: Stand up simulated internet on REMnux

On the REMnux guest (same host-only network), give it a static IP and run INetSim so the victim's DNS/HTTP/SMTP requests are answered locally:

# REMnux guest, e.g. 10.0.0.2 on the host-only network
sudo nano /etc/inetsim/inetsim.conf   # set service_bind_address and dns_default_ip
sudo systemctl start inetsim

Point the victim's DNS and default gateway at the REMnux IP so all resolution and traffic flow to the simulator.

Step 3: Start packet capture

Capture from the REMnux side so the victim never sees a sniffer:

sudo tcpdump -i eth0 -w /cases/<sample-sha256>.pcap

Step 4: Snapshot, detonate, observe, revert

1. Snapshot victim as "clean-base"
2. Transfer the sample into the victim (read-only ISO or one-way copy)
3. Run procmon / process monitoring, then execute the sample
4. Observe for 3-10 minutes; collect artifacts (pcap, procmon log, dropped files)
5. Revert victim to "clean-base"

Use the helper script to verify a victim VM's adapters are isolated before you detonate.

python scripts/analyst.py --check-config vmx/victim.vmx

Validation

• From the victim, nslookup example.com resolves to the REMnux IP (proves DNS is simulated, not real).
• A browser request from the victim returns INetSim's default page, not live content.
• tcpdump on REMnux shows the victim's traffic; nothing reaches a real upstream gateway.
• Reverting the snapshot returns the victim to the exact clean state (no dropped files persist).

Pitfalls

• Leaving a NAT/bridged adapter "just to download a tool" — malware will use it. Install all tooling before isolating, then remove the adapter.
• Forgetting to disable VMware Tools / guest additions clipboard, which some samples abuse.
• Detonating before snapshotting, so you cannot cleanly revert.
• Some samples detect INetSim's generic responses; if behavior stalls, consider FakeNet-NG or tailored service responses.

References

• See references/api-reference.md for the config-check tool and full source list.
• INetSim, FLARE-VM, and REMnux documentation (linked in frontmatter).