Building a Safe Analysis Lab

Static analysis only reads a file, so in principle it is safe anywhere. The moment you run a sample, though — or open it in a tool with a parser bug, or double-click the wrong window — you are executing someone else's hostile code. A lab is the set of walls that make that acceptable: when the sample does its worst, it does it to a disposable machine that talks to nothing real.

This lesson builds the environment every later lab on this path assumes. It takes an afternoon once, and a few seconds of checking before each session.

The threat model

Before choosing tools, be clear about what you are protecting against. A sample running in your lab may try to:

The last row is not a safety risk, but it shapes your lab. Malware that detects a virtual machine may simply do nothing. The techniques catalog documents many such checks, from the CPUID hypervisor bit to the VMware backdoor I/O port. You will learn to recognise and bypass them; you should never "fix" detection by running samples on bare metal connected to a real network.

Warning: Virtual machine escapes exist, but they are rare and valuable exploits that commodity malware almost never carries. The realistic ways samples leave a lab are boring: a shared folder left enabled, a bridged network adapter, or an analyst copying a file out without thinking. Most of this lesson is about closing those doors.

Architecture

The recommended layout is two virtual machines on a private virtual network, with no adapter connected to anything real:

  ┌──────────────────────── Host machine ────────────────────────┐
  │                                                               │
  │   ┌──────────────────┐   internal network   ┌──────────────┐  │
  │   │  Windows analysis │   "malnet"          │   REMnux      │  │
  │   │  VM (FLARE-VM)    │◄───────────────────►│   INetSim     │  │
  │   │  10.0.0.10        │   10.0.0.0/24        │   10.0.0.1    │  │
  │   │  gw/DNS=10.0.0.1  │                      │   fake DNS,   │  │
  │   └──────────────────┘                      │   HTTP, SMTP  │  │
  │                                              └──────────────┘  │
  │          no NAT · no bridge · no shared folders · no clipboard │
  └───────────────────────────────────────────────────────────────┘
                    ✕ no path to the real LAN / internet

• The Windows analysis VM is where samples run. Most malware you will meet targets Windows, so this is your main workstation.
• The REMnux VM is a Linux helper. It impersonates the internet — answering DNS queries, serving fake HTTP responses, accepting SMTP — and captures traffic. It also hosts Linux-side tools for static analysis of documents, scripts and ELF files.

An alternative for quick sessions is to run FakeNet-NG directly inside the Windows VM. It intercepts outgoing traffic locally and answers it with fake services, so a single VM with no network adapter at all can still show you what a sample tries to contact.

Choosing the network mode

Hypervisors name their modes differently. What matters is where packets can go:

Prefer an internal network. Host-only is acceptable but leaves your host's virtual interface reachable from the sample, which exposes any service the host listens on.

Building the Windows analysis VM

1. Install Windows 10 or 11 in a new VM from official Microsoft media. Give it at least 4 CPU cores, 8 GB of RAM and 80 GB of disk; heavy tools like Ghidra and IDA appreciate it, and small VMs are also a classic sandbox tell.
2. Keep it on NAT for now. The install needs internet access. This is the only time the analysis VM is allowed online.
3. Disable protections that will fight you. FLARE-VM's installer requires Windows Defender real-time and tamper protection to be off, and Windows Update to be paused. This VM is meant to be hostile territory; do this inside the VM only, never on your host.
4. Install FLARE-VM by following the instructions in its repository: download the installer script, run it from an elevated PowerShell prompt, and let it pull its package set. It installs debuggers (x64dbg), disassemblers (Ghidra), PE tools (PE-bear, Detect It Easy), Sysinternals, FakeNet-NG and much more.
5. Harden the VM's integration with the host. Disable shared folders, shared clipboard, drag-and-drop, and remove any mapped USB devices. Guest additions or VMware Tools are convenient for screen resizing, but they are also a detection artefact; many analysts keep them installed and accept that trade-off.
6. Switch the adapter to the internal network and set a static IP (10.0.0.10/24) with gateway and DNS both pointing to the REMnux VM (10.0.0.1).

Building the REMnux helper

1. Import the REMnux virtual appliance (an OVA file available from the REMnux documentation site), or install it on top of an Ubuntu VM with the official installer.

2. Update it while it still has NAT access, then move its adapter to the same internal network and give it the static address 10.0.0.1/24.

3. Configure INetSim in /etc/inetsim/inetsim.conf so its services listen on the internal interface and its fake DNS answers every name with REMnux's own address:

   service_bind_address   10.0.0.1
   dns_default_ip         10.0.0.1

4. Start it with inetsim. To capture traffic for later review, run a packet capture alongside it:

   sudo tcpdump -i any -w /tmp/session.pcap

Tip: INetSim and FakeNet-NG answer any request, so the sample believes its C2 is alive. That makes it reveal more behaviour — the next URL it requests, the data it tries to send — which becomes network IOCs.

Snapshots: your undo button

A snapshot captures the VM's disk and optionally its memory. It is the single most important safety and productivity feature of the lab.

• Take a "clean" snapshot once all tools are installed, the network is isolated and nothing has run. Name it with a date.
• Revert to clean before every new sample. Never analyse two samples in the same VM state; artefacts from the first will contaminate conclusions about the second.
• Take working snapshots mid-analysis — for example right after the sample has unpacked itself — so you can return to that point without re-running everything.
• Periodically rebuild the clean snapshot with tool updates, reconnecting to NAT only from a clean state and never after a sample has run.

Handling samples

Samples travel between machines — from a ticket, a repository or a colleague — and each transfer is a chance for an accident.

Password-protected archives

The industry convention is a ZIP (or 7z) archive protected with the password infected. The password is not secret; its purpose is to stop email gateways, antivirus engines and your own desktop from scanning, quarantining or accidentally opening the file. Repositories such as MalwareBazaar distribute samples this way, and you should share them the same way.

# Package a sample for transfer (7-Zip, AES-256, encrypted file names)
7z a -tzip -pinfected -mem=AES256 sample.zip sample.bin

Unpack archives only inside the analysis VM.

Renaming extensions

Store executables with a neutralised extension: invoice.exe becomes invoice.exe_ or invoice.bin. Windows then will not launch it on a stray double-click. Rename it back deliberately when you are ready to run it. Identify samples by hash rather than by their original file name, which attackers choose to look innocent.

Defanging indicators

When you write indicators in reports, tickets or chat, defang them so nothing becomes a live, clickable link:

Defanging protects colleagues from accidental clicks and keeps chat tools from fetching link previews — which would contact attacker infrastructure from your corporate network and tip off the operator.

If something escapes

Assume that one day a mistake will happen. Decide the response now, not in the moment:

1. Disconnect the affected machine from the network immediately. For a VM, disconnect its virtual adapter; for a host, pull the cable or disable Wi-Fi.
2. Do not keep using it and do not try to "clean" it by hand.
3. Tell your security team. If this is a work environment, the incident response process exists precisely for this. Early notice is always better than a quiet fix.
4. Preserve evidence — the sample hash, what you ran, and when — so responders can scope the problem.
5. Rebuild from known-good media. Reverting a VM snapshot is sufficient only if nothing left the VM.

Legal and ethical notes

• Get authorisation. Analysing malware as part of your job is normal; doing it on employer equipment or networks without approval is not. Follow your organisation's policy.
• Do not redistribute live samples outside trusted channels, and never to people you cannot vouch for.
• Do not interact with attacker infrastructure from a real network — no "just checking if the C2 is up" from your laptop. Doing so can alert the operator, violate law or policy, and compromise investigations.
• Respect data. Samples collected during incidents may contain victim data such as credentials or documents. Treat them as confidential.

Lab: build the lab and prove it is isolated

This lab uses no malware at all. Its goal is a clean, verified environment.

1. Build both VMs as described above. Confirm neither has shared folders, shared clipboard or drag-and-drop enabled, and that each has exactly one network adapter, attached to the internal network.

2. Record the clean state. On the Windows VM, open PowerShell:

   Get-NetAdapter | Format-Table Name, Status, MacAddress
   Get-NetIPConfiguration

   Confirm the only IPv4 address is 10.0.0.10 and the DNS server is 10.0.0.1.

3. Prove the real internet is unreachable. With INetSim stopped and FakeNet-NG not running:

   ping -n 2 1.1.1.1
   Test-NetConnection 1.1.1.1 -Port 443

   Both must fail. Then ping 10.0.0.1 should succeed (REMnux is the only neighbour). If a public address answers, stop and fix the adapter configuration before going further.

4. Prove the simulated internet works. Start inetsim on REMnux, then on the Windows VM:

   Resolve-DnsName update.example.com
   Invoke-WebRequest http://update.example.com/ -UseBasicParsing

   The name should resolve to 10.0.0.1, and the web request should return INetSim's default fake page. Check INetSim's log on REMnux (/var/log/inetsim/service.log) to see both requests recorded.

5. Try the single-VM alternative. Stop INetSim, start FakeNet-NG on the Windows VM from an elevated prompt, and repeat step 4. Watch FakeNet-NG's console: it logs the DNS query and the HTTP request, and replies with its own fake data.

6. Take the snapshot. Stop FakeNet-NG, shut down both VMs cleanly and take a snapshot of each named clean-2026-09-29.

Questions to answer: Which network mode did you choose, and what could a sample reach if you had chosen host-only instead? If a sample tried to contact a hard-coded IP address rather than a domain name, would INetSim alone still catch it? What would FakeNet-NG do differently?

Key takeaways

• A lab is a set of controls against specific risks: internet access, lateral movement, host integration and persistence.
• Use an internal virtual network, disable all host integration features, and simulate the internet with INetSim or FakeNet-NG.
• Revert to a clean snapshot before every sample; take working snapshots during analysis.
• Move samples in infected-password archives, neutralise extensions, and defang every indicator you write down.
• Verify isolation before each session — and have an escape plan before you need one.