Building an Isolated Malware Analysis Lab: Step-by-Step Network Configuration in VMware

May 17, 2026

Want to dive into malware analysis without risking your primary machine? Discover how to properly configure an isolated, host-only network between Windows and Linux VMs to securely analyze threats and capture live traffic using Wireshark.

Setting up a sandbox for malware analysis is like handling biological threats—you need a secure containment zone before opening the vial. If your virtual machines have a direct pathway to your home network or the broader internet, a single piece of sophisticated malware can easily escape and wreak havoc.

In this guide, we will walk through the absolute first step of malware analysis infrastructure: establishing a completely isolated, host-only virtual network environment between a Windows guest machine and a Linux analysis machine using VMware Workstation. By the end of this tutorial, your Windows target will be routed directly through your Linux machine, allowing you to intercept, log, and analyze all outbound traffic securely via Wireshark.

The Ultimate Goal: Total Isolation

When analyzing malicious files, your virtual environment needs to mimic standard operational functionality without actually connecting to the open web. We want to avoid two major risks:

  1. Malware escaping: Malicious software calling home to a Command and Control (C2) server or scanning your physical local network.
  2. Leaking diagnostics: Windows or third-party apps telemetry leaking lab metrics to external servers.

To mitigate this, we rely on a Host-Only Network, which allows our virtual machines to communicate exclusively with each other and the host system, entirely isolated from external internet access.

Step 1: Disconnecting External Adapters & Verifying Offline Status

Before turning on any routing, you must verify that your virtual ecosystem is completely cut off from the web.

  1. In VMware, locate your Windows virtual machine settings.
  2. Ensure the active Network Adapter is disconnected or set appropriately to pull away from any NAT or Bridged configurations.
  3. Boot up the Windows environment and pull up your terminal or web browser to verify isolation.

If you attempt to navigate to a live repository like GitHub, you should immediately hit a network disconnection page:

You're not connected
And the web just won't be the same without you...

To verify this from the Command Prompt (cmd), run a quick ping test to an external domain:

ping google.com

You should receive an immediate failure message stating that the ping request could not find the host. Finally, check your active IP address configuration:

ipconfig

At this stage, your Ethernet adapter should read Media disconnected, meaning no IP address is currently assigned.

Step 2: Transitioning to a Host-Only Virtual Architecture

Now that the internet connection is broken, we need to create our private sandbox.

  1. Open the Virtual Network Editor inside VMware (found via Edit > Virtual Network Editor).
  2. Look at your Host-Only network configuration block (typically assigned to VMnet1 or a similar virtual interface). Here, you will see your specific Subnet IP range assigned by the hypervisor.

Next, we must assign this Host-Only profile to both virtual machines:

  • On the Windows Target: Open your VM hardware settings, navigate to the Network Adapter, and switch the connection type from NAT/Bridged to Host-Only. Ensure the status box indicates it is connected.
  • On the Linux Analysis Tool (REMnux/Ubuntu): Repeat the exact same workflow. Navigate to hardware configurations and set the network profile to Host-Only.

Both machines are now sitting in the exact same room, but the door to the outside world is officially locked.

Step 3: Determining the Linux Analysis IP

Our Linux virtual machine will act as the gatekeeper and traffic monitoring station. Before configuring the Windows target, we need to extract the static network properties of our Linux system.

Open your Linux terminal and check your active network interface configurations:

ifconfig

Locate your primary interface (e.g., ens33). Take note of the assigned inet address. For instance, if your hypervisor's private range is configured as shown in the lab setup:

  • Linux Lab IP: 192.168.88.129
  • Subnet Mask: 255.255.255.0

Step 4: Configuring Static Manual Routing on Windows

To ensure all raw background traffic originating from the Windows side flows straight into our Linux monitoring tools, we have to manually configure the Windows IPv4 properties.

  1. Open the Control Panel on your Windows guest machine.
  2. Navigate to Network and Internet > Network and Sharing Center, then select Change adapter settings.
  3. Right-click your active Ethernet connection and open its Properties.
  4. Double-click on Internet Protocol Version 4 (TCP/IPv4).
  5. Change the selection from Obtain an IP address automatically to Use the following IP address.

Input the following parameters customized to your VMware subnet room:

  • IP address: Assign a manual, free IP on the same subnet (e.g., 192.168.88.64).
  • Subnet mask: 255.255.255.0
  • Default gateway: Set this to the Linux Lab IP (192.168.88.129).
  • Preferred DNS server: Set this to the Linux Lab IP (192.168.88.129).

Why set the Linux IP as the Gateway and DNS? By assigning your Linux machine as the default gateway and DNS provider, any URL request or connection attempt initiated by malware on the Windows machine will blindly route directly into your Linux interface, thinking it is reaching the internet.

Click OK to save and apply the settings.

Step 5: Testing Connectivity and Capturing Live Packets

With the private pipe established, it's time to verify that the machines can talk to each other without leaving the hypervisor footprint.

Open your Windows Command Prompt and ping your Linux box:

ping 192.168.88.129

You should see an instantaneous, successful reply from your Linux host. Switch over to your Linux terminal and run the inverse test to verify mutual connectivity:

ping 192.168.88.64

Visualizing the Data Flow in Wireshark

To watch this process occur in real-time, launch Wireshark on your Linux machine with root privileges.

  1. Select your primary host-only interface (e.g., ens33) to begin capturing packets.
  2. Head back over to the Windows terminal and fire off another sequence of pings.
  3. In Wireshark, you will immediately see standard ICMP Echo Requests arriving from 192.168.88.64 and hitting 192.168.88.129.

To isolate this stream from other internal system updates, you can apply a clean filter directly in Wireshark's filter bar:

ip.addr == 192.168.88.64

This presents a tidy, real-time breakdown of all operations, showing you exactly how the Windows environment is behaving under the hood.

Next Steps

Congratulations! You have officially built a highly isolated, safe, and observable malware analysis sandbox. Your Windows target cannot touch your physical hardware, nor can it communicate across your home Wi-Fi network.

From here, you can load up specialized simulation utilities on your Linux environment (like INetSim to simulate web services, DNS responses, and mail servers). When you detonate a specimen on Windows, it will try to download payloads or check in with its author, and you will see every single byte documented clearly inside your Wireshark terminal. Happy hunting, and stay safe!

← All posts