How to Build a Safe Security Test Lab

Updated 2026-10-25

Testing security tools and analyzing malware requires an isolated environment disconnected from external networks. This guide uses the Hyper-V test lab operated by mamoruhacker as a practical model. It covers architectural design principles, PowerShell setup commands, operational rules, and legal boundaries.

• Why virtual switches must be separated by purpose, and how packet isolation works
• Step-by-step PowerShell commands to configure Hyper-V virtual switches, NAT networks, and virtual machines
• Official download sources and setup procedures for analysis operating systems (FLARE-VM and REMnux)
• Operational rules and checkpoint strategies to prevent host contamination during analysis
• Legal boundaries and prohibited actions under cybercrime legislation

##Why You Need an Isolated Lab

Running penetration testing tools or malware samples on a daily-use computer or organizational network creates severe risks. Tools can inadvertently transmit packets to external hosts, and malware can propagate to other devices on the same local network.

An isolated lab lets you:

• Limit the blast radius: Keep traffic between virtual machines that you control.
• Roll back: Use checkpoints (snapshots) to return a machine to its state before a test.
• Watch the traffic: Capture traffic inside the isolated network with tools such as Wireshark.

##Architecture of the Operator’s Lab

The host machine runs Windows 11 Pro with 64 GB of RAM, using Hyper-V as the hypervisor. WSL2 (Kali Linux) runs on the host to serve as a central workbench for tool execution, sample storage, and audit log analysis.

The lab uses three virtual switches, one for each purpose:

This is one example from the operator’s environment, not a guarantee of safety. If a switch is miswired or a setting is missed, traffic can leave the lab. Repeat the checks in Step 7 every time you change the setup.

Virtual Machine Specifications

The table below outlines the core hardware parameters assigned to each VM:

##Prerequisites

Before beginning setup, verify host system requirements and acquire official software images.

Host Hardware and OS Requirements

Based on Microsoft Learn documentation, running Hyper-V requires:

• Operating System: Windows 11 Pro or Enterprise (64-bit). Windows Home edition does not support Hyper-V.
• Processor: 64-bit CPU with Second Level Address Translation (SLAT).
• RAM: Minimum 4 GB. In the operator’s setup, running FlareVM (6 GB) and REMnux (3 GB) together uses 9 GB for the VMs alone.
• Virtualization Support: Hardware virtualization (Intel VT-x or AMD-V) enabled in BIOS/UEFI.

Official Software Sources

To prevent tampering and supply-chain compromise, download all components exclusively from official repositories:

##Step-by-Step Setup Instructions

Open PowerShell with administrative privileges and follow these steps to construct the lab environment.

Step 1: Enable the Hyper-V Feature

Run the following command to enable the Hyper-V hypervisor and management tools:

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

Restart your computer when prompted.

• Verification: After restarting, run Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V in PowerShell. Confirm that State : Enabled is displayed.

Step 2: Create Virtual Switches

Hyper-V provides three virtual switch types. Choosing the correct switch is vital to lab security.

Create the Private switch dedicated to sample isolation:

New-VMSwitch -Name "LabPriv" -SwitchType Private

For web application security testing, configure an Internal switch paired with a NAT network:

# 1. Create an Internal switch
New-VMSwitch -Name "LabNat" -SwitchType Internal

# 2. Identify the interface index and assign a gateway IP
Get-NetAdapter "vEthernet (LabNat)" | Select-Object ifIndex, Name
New-NetIPAddress -IPAddress 192.168.100.1 -PrefixLength 24 -InterfaceIndex <ifIndex>

# 3. Create the NAT gateway (limited to one NAT network per host)
New-NetNat -Name "LabNatNetwork" -InternalIPInterfaceAddressPrefix 192.168.100.0/24

• Verification: Run Get-VMSwitch and verify that both LabPriv (Private) and LabNat (Internal) appear in the output.

Step 3: Create the Analysis Virtual Machine

Create a Generation 2 virtual machine attached to the LabPriv switch:

New-VM -Name "FlareVM" -Generation 2 -MemoryStartupBytes 6GB -NewVHDPath "D:\Hyper-V\Virtual Hard Disks\FlareVM.vhdx" -NewVHDSizeBytes 100GB -SwitchName "LabPriv"

Attach the downloaded Windows 11 Enterprise evaluation ISO and set the boot order:

Add-VMDvdDrive -VMName "FlareVM" -Path "D:\ISOs\Win11_Enterprise_Eval.iso"
Set-VMFirmware -VMName "FlareVM" -FirstBootDevice (Get-VMDvdDrive -VMName "FlareVM")

• Verification: Run Get-VM -Name "FlareVM" and verify the assigned memory and virtual switch configuration.

Step 4: Install Windows and Take an Initial Checkpoint

Start the VM and complete the initial Windows setup:

1. Power on the VM and follow the installation wizard.

2. During the initial out-of-box experience (OOBE), set up a local user account. Do not sign in with a cloud or corporate Microsoft account.

3. Once booted into the desktop, disable automatic checkpoints and switch the checkpoint architecture to Standard checkpoints so system memory can be preserved:

   # Disable automatic checkpoints
   Set-VM -Name "FlareVM" -AutomaticCheckpointsEnabled $false
   
   # Configure standard checkpoints
   Set-VM -Name "FlareVM" -CheckpointType Standard
   
   # Take the clean baseline checkpoint
   Checkpoint-VM -Name "FlareVM" -SnapshotName "win-clean"

• Verification: Run Get-VMSnapshot -VMName "FlareVM" and verify that win-clean exists.

Step 5: Attach a Temporary NIC and Install FLARE-VM

Because the FLARE-VM installation package downloads tools over the internet, connect a temporary network adapter to the NAT switch during the installation process only.

1. Add a temporary network adapter:

   Add-VMNetworkAdapter -VMName "FlareVM" -SwitchName "LabNat" -Name "TempInstallNIC"

2. Inside the guest OS, disable Windows Defender real-time protection and tamper protection via Group Policy or Windows Security settings as documented in the FLARE-VM README.

3. Open PowerShell as Administrator inside the guest and run the official installer:

   (New-Object net.webclient).DownloadFile('https://raw.githubusercontent.com/mandiant/flare-vm/main/install.ps1', "$env:temp\install.ps1")
   Unblock-File "$env:temp\install.ps1"
   Set-ExecutionPolicy Unrestricted -Force
   & "$env:temp\install.ps1"

4. Once installation completes and the VM restarts, immediately remove the temporary NIC to eliminate all outbound network routes:

   Remove-VMNetworkAdapter -VMName "FlareVM" -Name "TempInstallNIC"

5. In an elevated PowerShell inside the guest (FlareVM), give the private-switch adapter a static IP and point DNS at REMnux. Do not set a gateway. The addresses are examples.

   New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 10.10.10.20 -PrefixLength 24
   Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.10.10.1

6. Create the primary analysis rollback checkpoint:

   Checkpoint-VM -Name "FlareVM" -SnapshotName "flare-clean"

• Verification: Inside the guest, run Get-NetAdapter. Confirm that TempInstallNIC is absent and only the private network adapter remains connected.

Step 6: Import REMnux and Configure INetSim

Import REMnux by converting the official virtual appliance into a Hyper-V VHDX:

1. Extract the OVA archive with tar and decompress .vmdk.gz with gunzip.

2. Convert the virtual disk using qemu-img (or StarWind V2V Converter):

   qemu-img convert -p -O vhdx -o subformat=dynamic remnux-vmdk.vmdk remnux.vhdx

3. Create a Generation 1 virtual machine in Hyper-V (the converted disk uses legacy BIOS boot) and attach it to the LabPriv switch.

4. Boot REMnux and immediately change the default user credentials. The private switch has no DHCP, so set a static IP (for example, 10.10.10.1/24) with netplan.

5. Edit /etc/inetsim/inetsim.conf to bind listener services to the static Ethernet interface IP instead of loopback (127.0.0.1):

   service_bind_address    10.10.10.1
   dns_default_ip          10.10.10.1

6. Start INetSim:

   sudo inetsim

• Verification: From FlareVM, query nslookup example.com 10.10.10.1. Verify that INetSim returns its simulated IP address (10.10.10.1).

Step 7: Verify Network Isolation

Before placing any malware sample into the environment, rigorously test isolation integrity:

1. Outbound leakage test: From FlareVM, attempt network connections to public addresses and external domain names:

   Test-NetConnection -ComputerName 8.8.8.8 -InformationLevel Detailed
   Invoke-WebRequest -Uri "https://www.google.com" -TimeoutSec 5

   Confirm that Test-NetConnection reports PingSucceeded : False and that Invoke-WebRequest ends with an error. If either succeeds, a route to the outside still exists. Fix the wiring before you bring in any sample.

2. Internal loopback test: Confirm that HTTP requests to 10.10.10.1 successfully reach INetSim’s default response page.

##Operational Rules for Safe Analysis

Physical and virtual isolation must be backed by disciplined operational habits to prevent accidental contamination.

Ten Operational Rules Followed by the Operator

1. Execute samples on FlareVM only: Never execute malware on other VMs (REMnux or host workstations).
2. Never maintain permanent external NICs: Analysis VMs must not have standing internet access. Temporary NICs are connected only during updates and removed immediately after.
3. Sever transfer networks prior to execution: Ensure all file-transfer connections are disconnected before running any sample.
4. Disable Enhanced Session Mode: Hyper-V Enhanced Session Mode uses RDP and allows clipboard and drive redirection. To prevent malware from traversing these channels, operate via Basic Session or PowerShell Direct. Disable Enhanced Session Mode host-wide with:

   Set-VMHost -EnableEnhancedSessionMode $false

5. Turn off IPv6 and IP forwarding on sample VMs: To prevent unexpected traffic from IPv6 auto-configuration, the operator unbinds IPv6 on the sample-related VMs and also turns off IP forwarding on REMnux. Note that Microsoft does not recommend unbinding IPv6 on Windows in general; it suggests preferring IPv4 with the registry value DisabledComponents = 0x20 instead. Unbinding it is the operator’s choice for isolated sample VMs only.
6. Automate cable and switch verification: Run verification scripts before starting VMs to confirm no analysis VM is connected to an External or NAT switch.
7. Never store live samples on host NTFS volumes: Host antivirus software (Microsoft Defender) can detect and quarantine samples, breaking research consistency. Store samples exclusively within WSL2 virtual disk files.
8. Collect evidence before rolling back: Reverting to a checkpoint wipes all ephemeral files and memory state. Safely export memory dumps, PCAP captures, and event logs via PowerShell Direct before initiating a rollback.
9. Disable host-guest shared folders: Avoid shared folder features that provide potential lateral movement paths for ransomware or worms.
10. Maintain strictly local accounts: Never log in with cloud identities or personal credentials inside the analysis machines.

##Alternatives for Non-Hyper-V Users

If you run Windows Home edition, macOS, or Linux, the desktop hypervisors below provide equivalent network isolation capabilities:

In VirtualBox, configuring an “Internal Network” confines packet delivery strictly to designated virtual machines, keeping traffic completely hidden even from the host OS. Never attach test VMs to a “Bridged” adapter, as bridged adapters place VM network traffic directly onto your physical LAN.

##Legal Boundaries and Compliance

Security research must always operate within established legal boundaries.

Unauthorized Computer Access Act

Under Japan’s Act on the Prohibition of Unauthorized Computer Access (Act No. 128 of 1999), unauthorized entry into computer systems protected by access controls is strictly prohibited:

Penal Code Provisions (Creation of Unauthorized Computer Commands)

Handling malware and security testing tools is regulated under the Penal Code:

• Article 168-2 (Creation of Unauthorized Computer Commands): Creating, providing, or executing computer viruses or unauthorized commands without legitimate cause is punishable by imprisonment for up to 3 years or a fine up to 500,000 yen.
• Article 168-3 (Acquisition of Unauthorized Computer Commands): Acquiring or storing unauthorized computer commands without legitimate cause is punishable by imprisonment for up to 2 years or a fine up to 300,000 yen.
• Article 234-2 (Obstruction of Business by Computer Damage): Damaging computers used for business operations or feeding them unauthorized commands to cause disruption carries up to 5 years imprisonment or a fine up to 1,000,000 yen.

Permitted Research Boundaries

• Virtual machines in your own fully isolated private lab
• Target systems covered by explicit written authorization (contracts specifying testing scope, time windows, and authorized testing techniques)

Testing exploit techniques against third-party systems without prior written authorization constitutes a serious crime, even if no damage occurs. Never distribute or leak malware samples outside your private lab.

##Primary Sources and Verification Date

All technical claims, product licensing terms, and regulatory provisions were verified on October 25, 2026:

• Install Hyper-V on Windows（Microsoft Learn）
• New-VMSwitch（Microsoft Learn PowerShell Module）
• Set up a Hyper-V NAT network（Microsoft Learn）
• New-VM（Microsoft Learn PowerShell Module）
• Using checkpoints to revert virtual machines to a previous state（Microsoft Learn）
• Share devices with your Hyper-V virtual machine（Microsoft Learn）
• Manage Windows virtual machines with PowerShell Direct（Microsoft Learn）
• Guidance for configuring IPv6 in Windows for advanced users（Microsoft Learn）
• Windows 11 Enterprise Evaluation（Microsoft Evaluation Center）
• mandiant/flare-vm（GitHub）
• Get the REMnux Virtual Appliance（REMnux Documentation）
• INetSim Official Documentation
• VMware Desktop Hypervisor Pro Apps now Free for All Users（VMware Official Blog, 2024-11-11）
• Oracle VM VirtualBox User Manual: Virtual Networking
• Act on the Prohibition of Unauthorized Computer Access（e-Gov Legal Database）
• Penal Code of Japan（e-Gov Legal Database）

##Next Steps

• OWASP Juice Shop: Deploy an intentionally vulnerable web application on your target VM to practice vulnerability assessment safely
• Nmap: Practice network mapping and port discovery against targets within your private lab
• Wireshark: Inspect and analyze protocol traffic inside your isolated virtual network

✕ Close (Esc)