How to Build an Isolated Malware Analysis Lab

What exactly is an isolated malware analysis lab?

An isolated malware analysis lab is a set of virtual machines with no network route to your workstation, your local network, or the internet, in which you can execute malicious code and watch what it does. What defines the lab is not the hypervisor or the tooling you install — it is the network topology. If the sample can reach anything you care about, you don't have a lab, you have an incident.

This guide builds that lab end to end with VirtualBox, explains why three of the four network modes any hypervisor offers will not do, and devotes an entire section to the part almost no tutorial includes: proving the isolation actually works before you go anywhere near a real sample.

I assume you can install an operating system in a virtual machine. Everything else is spelled out. The commands are VirtualBox because it is free and cross-platform; in VMware the concepts are identical and only the names change (what VirtualBox calls an internal network, VMware calls a LAN segment).

What are you actually protecting yourself from?

"Isolate the malware" sounds obvious until you ask from what. It is worth enumerating, because each risk is mitigated by a different design decision and it is easy to half-cover them:

The third one is the most underestimated. Detonating a sample with real internet access does not just expose you — it tips off the operator, who can pull the infrastructure down before you finish documenting it. In serious analysis you cut egress not only for safety, but for method.

Which network mode really isolates, and which only looks like it does?

This is where most home labs fall down. Every hypervisor offers four network modes and only one is fit for detonating malware:

The correct mode is the internal network: a virtual switch living purely in hypervisor memory, with no adapter on the host at all. Machines attached to it see each other and nothing else. The trade-off is that you also lose legitimate access (you cannot copy tools over the network), which is why the lab needs a second machine to act as a fake internet.

How do you build the lab, step by step?

Two virtual machines: an analysis box (Windows, where 90% of the malware you will see lives) and a services box (Linux, simulating the internet and capturing traffic).

1. The services machine

Use REMnux, an Ubuntu-based distribution maintained by Lenny Zeltser built for exactly this. It ships INetSim, FakeNet-NG, Wireshark and the rest of the toolkit already installed and configured, which saves you an entire afternoon.

2. The analysis machine

A clean Windows 10 or 11, with FLARE-VM on top — Mandiant's installer that lays down the reverse engineering arsenal. Install it while the network is still on NAT, because it needs to download packages; the moment it finishes, egress is cut and never reopened.

3. Cut egress and join both machines

With both VMs powered off, move them onto the same internal network. The name (labnet) is arbitrary, but it has to match: that string is what acts as the switch.

# Both VMs powered off before touching anything
VBoxManage modifyvm "Analysis-Win10" --nic1 intnet --intnet1 "labnet"
VBoxManage modifyvm "Services-REMnux" --nic1 intnet --intnet1 "labnet"

# No bridges back to the host: clipboard and drag-and-drop off
VBoxManage modifyvm "Analysis-Win10" --clipboard-mode disabled
VBoxManage modifyvm "Analysis-Win10" --draganddrop disabled

4. Static addressing

There is no DHCP server on an internal network, so addresses are set by hand. A layout that works well:

Note that the analysis machine points at the services machine as gateway and as DNS. That is the trick: everything the malware tries to resolve or contact ends up at INetSim.

5. Snapshots before anything else

The snapshot is not a convenience, it is part of the method: without it you cannot repeat an analysis under identical conditions, nor guarantee that what you are observing came from this sample and not the previous one.

# Clean state, tooling installed, network already isolated
VBoxManage snapshot "Analysis-Win10" take "clean-baseline" \
  --description "Win10 + FLARE-VM, intnet, no samples"

# And to return to it between samples
VBoxManage snapshot "Analysis-Win10" restore "clean-baseline"

How do you simulate the internet without real egress?

A sample with no network does very little. If it cannot resolve its command-and-control domain, many families abort execution and you never see the interesting phase. The answer is to hand it a fake internet that answers everything.

INetSim stands up simulated DNS, HTTP, HTTPS, SMTP, FTP and IRC servers. Its value is the wildcard DNS: any domain the sample asks for resolves to the services machine, and any request gets a plausible response.

# /etc/inetsim/inetsim.conf — the lines that matter

# Listen on the lab interface, not on localhost
service_bind_address    10.13.37.2

# Every domain queried resolves here
dns_default_ip          10.13.37.2

# Answer for any domain, not just a fixed list
dns_default_hostname    www
dns_default_domainname  local

The alternative is FakeNet-NG, which runs inside the analysis machine and intercepts traffic before it reaches the network adapter. It is more convenient for quick single-box triage; INetSim is better when you want clean traffic captured on a separate machine, which is the normal situation once you are documenting.

How do you verify the isolation actually holds?

This is the section missing from nearly every guide, and the only one standing between you and infecting yourself. Do it before you go near any real sample, with the analysis machine still clean.

1. 1From the analysis machine, run ping 10.13.37.2. It must reply: if it doesn't, the virtual switch is misconfigured and you will see no traffic.
2. 2Run ping 8.8.8.8. It must fail. If it replies, you have real egress and the lab is not isolated.
3. 3Try resolving any domain with nslookup does-not-exist.test. It should return 10.13.37.2, confirming wildcard DNS works.
4. 4Point a browser at any URL. You should get the INetSim page — not a network error, and certainly not the real site.
5. 5From your host, run VBoxManage list hostonlyifs. The lab network must not appear: an internal network creates no host adapter, and that absence is precisely the proof.
6. 6Try to reach your home router from the analysis machine (ping 192.168.1.1 or whatever yours is). It must fail.

What does malware do to detect it is running in a virtual machine?

Many families check whether they are being analysed and, if they detect it, sit still or exit. In the MITRE ATT&CK matrix this is technique T1497 (Virtualization/Sandbox Evasion). What they typically look at:

Now the honest part: for most work you don't need to harden anything. If you are triaging a suspicious email or a commodity binary, the sample will just run. Hardening costs time and pays off when you are chasing targeted families that do implement these checks. Start with a working lab and harden when you hit a sample that refuses to run.

And mind the trade-off: removing guest additions costs you convenience (no shared clipboard, fixed resolution) but also shrinks the hypervisor escape surface, so in this particular case convenience and safety point in opposite directions. I remove them.

How do you handle samples without infecting yourself by accident?

The lab can be perfect and you can still infect your workstation by mishandling the file before it gets inside. Handling discipline matters as much as topology.

1. 1Always download samples inside an encrypted container. The industry convention, used by repositories such as MalwareBazaar, is a ZIP with the password infected.
2. 2Never extract on the host. The file moves into the analysis machine still compressed — via an attached virtual disk, or a read-only share unmounted afterwards, never a permanent shared folder.
3. 3Hash it before touching anything, so you can reference the sample unambiguously: sha256sum sample.zip on Linux, or Get-FileHash -Algorithm SHA256 sample.zip in PowerShell.
4. 4Change the extension while moving it (.exe to .exe_, or drop it entirely). It prevents the classic accidental double-click.
5. 5Disable antivirus only inside the analysis machine. If Defender is live it will delete the sample mid-analysis and you will lose the work.
6. 6When you finish, restore the clean snapshot. Don't delete the file and carry on — restore.

The mistakes that keep coming back

• Mistaking host-only for isolation. This is failure number one and it leaves your own machine reachable by the sample.
• Leaving a second adapter on NAT "just to copy things across". One is enough for isolation to not exist.
• Restoring an old snapshot taken before the network was isolated, which silently reverts the network configuration too.
• Analysing without capturing traffic. If Wireshark wasn't recording, half the behaviour is gone and you get to start over.
• Reusing the machine between samples without restoring. You end up attributing to one sample the persistence left behind by another.
• Permanent shared folders. The most direct route for ransomware in the VM to encrypt files on the host.

With the lab standing, the natural next step is having a method instead of picking at tools at random. That route — static triage, decompilation, dynamic and network analysis through to a detection rule — is exactly what we work through in the Windows Malware path, and you can see it applied end to end in our step-by-step AgentTesla analysis.