Malware Analysis — Part 1: Building the Lab

Previous: Part 0 — What Is Malware Analysis?

Why Build a Lab at All?

Before touching any software, it's worth understanding what problem this lab is solving — because the problem is more serious than most beginners realize.

Malware is designed to run on real systems. When you execute a piece of malware, it will attempt to do exactly what it was built to do — encrypt files, steal credentials, establish persistence, phone home to a command server, spread to other machines on the network. It does not know or care that you intended it only as a "quick test."

This creates a non-negotiable requirement: malware must be analyzed in an environment that is completely isolated from everything you care about. Not "mostly isolated." Not "isolated except for that one shared folder." Completely isolated.

A properly built malware analysis lab gives you:

• Isolation — malware cannot escape the VM or reach your home network
• Control — you control every network connection the malware makes
• Observability — every action the malware takes is logged and visible
• Repeatability — snapshots let you restore a clean state in seconds and run the same analysis again with different monitoring tools

This part builds that foundation. Everything in every subsequent part depends on getting this right.

Why Hyper-V on Windows 11 Pro?

The professional world of malware analysis uses several virtualization platforms. The most common in corporate environments are VMware vSphere (enterprise) and VMware Workstation Pro (desktop). Both are excellent but not free.

For this series we use Microsoft Hyper-V because:

• It's built into Windows 11 Pro — no additional software to purchase
• It's a Type 1 hypervisor — it runs at the hardware level, not inside Windows like VirtualBox does
• It coexists cleanly with WSL2 (which also uses Hyper-V under the hood)
• It has all the features a malware analysis lab needs: snapshots, virtual networking, checkpoint management

What you need:

• Windows 11 Pro (Hyper-V is not available on Windows 11 Home)
• A CPU with virtualization support (Intel VT-x or AMD-V) — enabled in BIOS
• At minimum 16GB RAM (32GB recommended — see resource budget below)
• 200GB+ free disk space for VMs

Understanding the Network Architecture

This is the most important concept in this entire part. Read it carefully.

The lab uses three separate virtual networks (called switches in Hyper-V) to create strict isolation between the internet, your home network, and the malware analysis environment.

               Internet
                   |
          +-----------------+
          | External Switch |   <- connected to the real internet
          +--------+--------+
                   |  (WAN only)
          +--------+--------+
          |     pfSense     |   <- your virtual firewall / router
          +--------+--------+
                   |  (LAN only)
          +--------+--------+
          | Internal Switch |   <- completely isolated lab network
          +----+--------+---+
               |       |
      +-----------------+  +-----------------+
      |  Win Malware VM |  | REMnux Analysis |
      +-----------------+  +-----------------+


          +-----------------+
          |   Mgmt Switch   |   <- host access only (RDP / SSH)
          +--------+--------+
                   |
          Windows 11 Pro Host

Why three switches?

The External Switch is the only one connected to the internet. pfSense connects its WAN interface here. Nothing else does — connecting a malware VM directly to the External Switch would expose it to the internet and expose your home network to it.

The Internal Lab Switch is completely private. No physical adapter is attached. Traffic on this network can only go between the VMs connected to it — and the only way out is through pfSense, which you control. This is where your malware VM and REMnux live. When malware tries to connect to its command server, that traffic goes through pfSense, where you can block it, log it, or route it to INetSim for interception.

The Management Switch optionally connects your host machine to REMnux and pfSense for administrative access — RDP, SSH, file transfers. This switch is never connected to the malware VM.

The key security property: The malware VM's only path to the outside world is through pfSense on the Internal Switch. You control pfSense. You decide what gets through. The malware cannot bypass this.

Enabling Hyper-V

Open PowerShell as Administrator and run:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

Or via the GUI: Control Panel → Programs → Turn Windows features on or off → Hyper-V (check all sub-items) → OK → Restart.

After the restart, open Hyper-V Manager from the Start menu.

Creating Virtual Switches

Virtual switches are Hyper-V's equivalent of physical network switches. You must create them before creating any VMs.

Open Hyper-V Manager → Virtual Switch Manager (right panel).

Switch 1 — External Switch (Internet Access)

1. Select New virtual network switch → External → Create Virtual Switch
2. Name: External
3. Connection type: External network
4. Select your physical network adapter (Ethernet or Wi-Fi)
5. Check Allow management operating system to share this network adapter (this lets your host machine still access the internet)
6. Click OK

What this does: Creates a bridge between the virtual network and your physical network adapter. pfSense's WAN interface will connect here, giving it internet access.

Switch 2 — Internal Lab Switch (Isolated Malware Network)

1. Click New virtual network switch → Internal → Create Virtual Switch
2. Name: Internal-Lab
3. Connection type: Internal network
4. Click OK

What this does: Creates a completely private network. No physical adapter is attached, so traffic on this network cannot reach your home network. Only VMs explicitly connected to this switch can communicate with each other. This is where your malware lives.

Switch 3 — Management Switch (Host Access)

1. Click New virtual network switch → Internal → Create Virtual Switch
2. Name: Management
3. Connection type: Internal network
4. Click OK

What this does: Creates a private network for administrative access. Your Windows host machine will automatically get an IP on this network (via the virtual adapter Hyper-V creates), letting you SSH and RDP into your analysis VMs without going through the malware network.

Installing pfSense

pfSense is a professional-grade open source firewall and router. In this lab it serves as the gateway between your isolated malware network and the outside world — giving you complete control over every connection the malware attempts to make.

Why pfSense and not just Windows Firewall?

Windows Firewall blocks connections on your host machine. pfSense operates at the network level — it's a separate device (VM) that all traffic must route through. The malware has no way to modify pfSense's rules the way it might be able to disable Windows Firewall. More importantly, pfSense gives you deep packet inspection, full traffic logging, and the ability to intercept and redirect connections for analysis.

Create the pfSense VM

In Hyper-V Manager: New → Virtual Machine

After creation, open the VM settings and add two network adapters:

1. Network Adapter 1: Connect to External switch (this is the WAN)
2. Network Adapter 2: Connect to Internal-Lab switch (this is the LAN)

Optionally add a third adapter connected to Management if you want to access the pfSense web UI from your host.

Install pfSense

Start the VM and open the console (Connect button in Hyper-V Manager). Follow the installer — accept all defaults. pfSense will auto-detect:

• WAN: the adapter connected to External
• LAN: the adapter connected to Internal-Lab

After installation and reboot, pfSense will show a console menu. The LAN interface will have an IP like 192.168.1.1. Any VM on the Internal-Lab switch can reach the pfSense web UI at that address.

Configure pfSense for the Lab

From the pfSense console or web UI (http://192.168.1.1):

Default credentials: admin / pfsense — change these immediately.

Key configuration for a malware lab:

1. Block all outbound traffic by default. In pfSense: Firewall → Rules → LAN → Add rule to block all outbound traffic. You'll create specific allow rules only for controlled analysis sessions.

2. Enable full traffic logging. Under Firewall → Rules, enable logging on every rule. This creates a complete record of every connection the malware attempts.

3. Configure DNS. Under Services → DNS Resolver, enable the DNS resolver. During analysis, you'll often point this at INetSim (running on REMnux) to intercept DNS queries.

Resource Budget

For a machine with 32GB RAM:

For a machine with 16GB RAM, reduce the Windows VM to 4GB and skip Kali until you have more resources.

Snapshot Strategy

Snapshots are one of the most important safety mechanisms in your lab. A snapshot saves the complete state of a VM at a point in time — RAM contents, disk state, all settings. You can restore to it in seconds.

The core principle: The Windows Malware VM should be treated as disposable. After every analysis session, you restore it to a clean state. The malware never persists.

Install Windows VM
      |
Install Windows Updates
      |
Install FLARE-VM (analysis tools)
      |
Apply hardening settings
      |
+-----v--------------+
|  BASELINE SNAPSHOT |  <- this is your safety net
+-----+--------------+
      |
Analyze malware (Parts 7, 8, 9...)
      |
Export findings / write notes
      |
Restore baseline snapshot
      |
Ready for next sample

Creating a snapshot in Hyper-V:

In Hyper-V Manager, right-click the VM → Checkpoint (Hyper-V calls snapshots "checkpoints"). Name it descriptively: Windows-Baseline-Clean.

Restoring a snapshot:

Right-click the checkpoint → Apply. The VM reverts instantly to that exact state.

Transferring Files Between Host and VM

File transfer between your host and your VMs is one of the trickiest safety problems in malware analysis. The tools designed to make it easy — shared folders, clipboard sharing, drag-and-drop — are also the tools most likely to let malware escape its container.

Here are three approaches, ordered from most convenient to most secure:

Method 1 — Management Switch Network Share (Convenient)

Set up a Windows file share on the Management switch network, accessible only from the Management interface — never from the Internal-Lab switch.

1. On your Windows host, create a dedicated folder: C:\MalwareSamples
2. Right-click → Properties → Sharing → Advanced Sharing
3. Share the folder, give it a name like Samples
4. Set permissions to read-only for the analysis VM user

In the Windows analysis VM, map the network drive using the host's Management switch IP address. The malware VM connects only to the Internal-Lab switch and cannot see this share.

Method 2 — ISO File (More Secure)

The safest way to transfer files into the malware VM. Put the sample in a folder, burn it to an ISO image, mount the ISO in the VM as a virtual DVD. The ISO is read-only — the malware cannot write back to it.

On Windows host, create an ISO from a folder:

# Using built-in Windows tools (PowerShell)
$Source = "C:\MalwareSamples"
$Destination = "C:\samples.iso"

# Use third-party tool like ImgBurn or NTLite, or:
# In File Explorer, right-click folder → Send to → DVD RW Drive
# Then use 'Burn disc image' feature

Or use CDBurnerXP (free) or ImgBurn (free) to create the ISO, then mount it in Hyper-V via VM Settings → DVD Drive → Image file.

Method 3 — Hyper-V Enhanced Session (Balanced)

Hyper-V's Enhanced Session mode provides clipboard integration and basic file transfer through the RDP-based console connection. This is more convenient than ISOs but less isolated than a read-only mount.

Enable Enhanced Session: Hyper-V Manager → Hyper-V Settings → Enhanced Session Mode Policy → Allow enhanced session mode.

In the VM settings, also enable: Integration Services → Guest services.

When connecting to the VM, you'll be prompted about Enhanced Session mode. Accept, and you'll have clipboard access and can drag-and-drop files.

When to use which method:

Security Settings — Hardening the VM Environment

Before creating your baseline snapshot, apply these settings to the Windows Malware VM to reduce the risk of VM escape and accidental activation of malware outside the analysis window:

Disable Dangerous Integration Features

In Hyper-V Manager, VM Settings → Integration Services:

• ✅ Keep: Operating system shutdown, Time synchronization, Heartbeat
• ❌ Disable: Guest services (file copy), Data exchange

In the Windows VM itself, disable:

• Remote Desktop (not needed on the malware VM — use the Hyper-V console)
• Windows Update (prevents unexpected changes during analysis)
• Windows Defender real-time protection (it will interfere with analysis — see Part 2 for the proper exclusion configuration)
• Automatic sample submission to Microsoft (critical — you do not want malware samples automatically uploaded)

Network Adapter Settings

The malware VM should have exactly one network adapter connected to the Internal-Lab switch. No Management switch connection. No External switch connection. One adapter, one isolated network.

Verify this by opening the VM settings and checking network adapters.

Guiding Principles

Before moving to Part 2, internalize these principles. They are the foundation of safe malware analysis:

The malware VM is disposable. Treat it that way. Never store anything on it you can't afford to lose. Never run personal software on it. Restore to baseline after every session.

The host machine is sacred. Nothing from the malware network should ever touch your host machine directly. File transfers go through ISOs or the Management network only. Shared clipboard on the malware VM is disabled.

pfSense controls everything. Every network connection the malware makes goes through pfSense. You log it. You control it. The malware cannot bypass this.

If in doubt, restore the snapshot. A snapshot restore takes 30 seconds. Troubleshooting a potentially compromised analysis environment takes hours. When something unexpected happens, restore first and investigate second.

Build Order

Follow this sequence exactly — each step depends on the previous one:

1. Enable Hyper-V on Windows 11 Pro
2. Create the External virtual switch
3. Create the Internal-Lab virtual switch
4. Create the Management virtual switch
5. Download pfSense CE or OPNsense ISO
6. Create the pfSense VM with two network adapters
7. Install and configure pfSense — set firewall rules to block all outbound by default
8. Create the Windows Malware VM (do not install tools yet)
9. Connect the Windows VM to Internal-Lab switch only
10. Verify the Windows VM gets an IP from pfSense DHCP
11. Verify the Windows VM cannot reach the internet (pfSense blocks it)
12. Proceed to Part 2 — install FLARE-VM and take the baseline snapshot

Verification Checklist

Before moving to Part 2, confirm all of the following:

• Hyper-V is enabled and Hyper-V Manager opens
• Three virtual switches exist: External, Internal-Lab, Management
• pfSense VM boots and shows its console menu
• pfSense WAN has an IP from your home network
• pfSense LAN is on 192.168.1.1 (or your chosen IP)
• Windows Malware VM receives an IP from pfSense DHCP
• Windows Malware VM cannot reach the internet (test: ping 8.8.8.8)
• pfSense web UI is accessible from a VM on the Management switch
• No network adapter on the malware VM connects to External or Management switches

Previous: Part 0 — What Is Malware Analysis? Next: Part 2 — Setting Up the Windows Analysis VM with FLARE-VM