Setting Up An Isolated Malware Analysis Lab

---
name: setting-up-an-isolated-malware-analysis-lab
description: 'Builds a safe, isolated environment for detonating and analyzing malware
  using virtualization, host-only or simulated networking, and snapshotting. Activates
  for requests about creating a malware lab, sandbox VM, isolated analysis environment,
  or safe detonation setup.'
domain: cybersecurity
subdomain: lab-foundations
tags:
  - malware
  - lab-setup
  - virtualization
  - isolation
  - inetsim
  - flare-vm
version: 1.0.0
author: analyst-ai-pack
license: Apache-2.0
mitre_attack:
  - T1564
  - T1497
d3fend:
  - D3-DA
  - D3-EAL
references:
  - 'INetSim documentation — https://www.inetsim.org/documentation.html'
  - 'FLARE-VM — https://github.com/mandiant/flare-vm'
  - 'REMnux documentation — https://docs.remnux.org/'
---

# 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:

```text
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:

```bash
# 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:

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

### Step 4: Snapshot, detonate, observe, revert

```text
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.

```bash
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`](references/api-reference.md) for the config-check tool
  and full source list.
- INetSim, FLARE-VM, and REMnux documentation (linked in frontmatter).