Can I use VirtualBox instead of KVM for this lab?

VirtualBox works for basic isolation but lacks fine-grained libvirt network XML control and performs worse under heavy I/O. KVM is strongly preferred for serious research; VirtualBox host-only adapters can substitute in a pinch but require careful adapter configuration to prevent bridging.

Is it legal to download malware samples for research?

In most jurisdictions, possessing malware samples for legitimate security research is legal, but executing them on systems you do not own or distributing them is not. Use lawful sources like MalwareBazaar, operate samples only in your own isolated lab, and check your local laws — regulations vary significantly by country.

Why not just use a dedicated Kali Linux VM as the analyst machine?

You can, and it is a reasonable starting point. The downside is that Kali is configured for ease of use rather than operational security — it runs services by default, patches lag, and its footprint is harder to audit. A hardened Debian or Arch base with selective tool installation is more reproducible and easier to lock down.

How do I let malware phone home to observe C2 behavior without risking real traffic leaving my network?

Route the victim VM through a gateway VM running a DNS sinkhole (INetSim or dnsmasq with wildcard responses pointing to your own IP), capture the TLS handshakes and HTTP requests, and use mitmproxy with a custom CA to decrypt HTTPS where possible. Never route real C2 traffic through your host's physical NIC.

How many snapshots should I keep before deleting old ones?

Keep the baseline and configured snapshots permanently. For pre-experiment snapshots, a rolling window of three to five is usually enough — each snapshot on a qcow2 disk creates a chain that degrades read performance if it grows too long. Use 'virsh snapshot-delete' to prune old ones and 'qemu-img commit' to flatten chains periodically.

Linux for Security Researchers (Lab Setup)

Running security research directly on your daily driver is how you lose data, leak credentials, or accidentally pivot into a network you have no business touching. A purpose-built VM lab gives you isolation, repeatability, and the ability to blow everything up and start fresh. This guide walks through building a serious research environment: isolated networking, Kali-grade tooling on mainstream distros, snapshot discipline, decoy network topologies, and safe malware sample capture.

Hypervisor and Host Hardening

Use KVM/QEMU with libvirt on your host. It is mature, auditable, and integrates with systemd without friction. VirtualBox works but lacks fine-grained network isolation primitives you will need later. VMware Workstation is acceptable but proprietary.

# Debian/Ubuntu
sudo apt install --no-install-recommends qemu-kvm libvirt-daemon-system \
  virtinst virt-manager bridge-utils ovmf

# Fedora / RHEL 9+ / Rocky 9
sudo dnf install @virtualization virt-manager ovmf

# Arch
sudo pacman -S qemu-desktop libvirt virt-manager dnsmasq ovmf bridge-utils

sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER"   # log out and back in after this

On the host, harden before you do anything else. Disable the default libvirt NAT network right away — you will replace it with controlled segments.

virsh net-destroy default
virsh net-autostart --network default --disable

Designing Isolated Network Segments

The lab needs at least three virtual networks, none of which bridge to your physical NIC:

management — your analyst VM talks to everything here; no internet routing
victim-net — where target VMs live; completely isolated, no host route
capture-net — optional MITM segment for traffic interception

Define each as an isolated libvirt network (no forward mode):

cat > /tmp/lab-mgmt.xml <<'EOF'
<network>
  <name>lab-mgmt</name>
  <bridge name="virbr-mgmt" stp="on" delay="0"/>
  <ip address="10.10.0.1" netmask="255.255.255.0"/>
</network>
EOF
virsh net-define /tmp/lab-mgmt.xml
virsh net-start lab-mgmt
virsh net-autostart lab-mgmt

cat > /tmp/lab-victim.xml <<'EOF'
<network>
  <name>lab-victim</name>
  <bridge name="virbr-victim" stp="on" delay="0"/>
  <ip address="10.20.0.1" netmask="255.255.255.0"/>
</network>
EOF
virsh net-define /tmp/lab-victim.xml
virsh net-start lab-victim
virsh net-autostart lab-victim

Your analyst VM attaches to lab-mgmt only. Victim VMs attach to lab-victim only. If you want controlled internet access for a victim (to let a sample phone home to a sinkhole), route it through a dedicated gateway VM — never directly through the host.

Kali Tools on a Mainstream Distro

Running Kali as your analyst OS is fine for CTFs. For serious research you want a reproducible, auditable base. Install tools selectively on Debian, Ubuntu, or Arch instead.

Core tooling via package managers

# Debian/Ubuntu — install key tools without pulling in the full Kali meta
sudo apt install nmap masscan wireshark-qt tshark tcpdump netcat-openbsd \
  socat binwalk foremost volatility3 gdb gdb-multiarch radare2 \
  sqlmap hydra hashcat john aircrack-ng exploitdb metasploit-framework

# Fedora
sudo dnf install nmap wireshark tcpdump ncat socat gdb radare2 hashcat john

# Arch (AUR covers anything missing from official repos)
sudo pacman -S nmap masscan wireshark-qt tcpdump netcat socat gdb radare2 \
  hashcat john aircrack-ng metasploit
yay -S volatility3 exploitdb sqlmap  # from AUR

Python-based tooling in isolated environments

Never install research Python packages system-wide. Use virtual environments per project:

python3 -m venv ~/labs/pwntools-env
source ~/labs/pwntools-env/bin/activate
pip install pwntools impacket scapy mitmproxy

Wireshark without running as root

sudo usermod -aG wireshark "$USER"
# log out and back in, then capture as your normal user

Snapshot Discipline

Snapshots are your undo button. Take them at defined checkpoints, not randomly.

baseline — clean OS install, fully patched, no research tools
configured — tools installed, services disabled, hardened
pre-experiment — immediately before detonating a sample or running an exploit

# Create a snapshot
virsh snapshot-create-as --domain victim-win10 \
  --name "pre-experiment-2024-07-15" \
  --description "Clean state before running sample SHA256:abc123" \
  --atomic

# List snapshots
virsh snapshot-list victim-win10

# Revert to snapshot
virsh snapshot-revert victim-win10 "pre-experiment-2024-07-15"

For qcow2-backed VMs, confirm your disk format supports internal snapshots:

qemu-img info /var/lib/libvirt/images/victim-win10.qcow2 | grep format

Building a Decoy Network (INetSim / FakeNet-NG)

A decoy network makes malware believe it has full internet access while you intercept every connection. Run the fake services on your analyst VM or a dedicated gateway VM on lab-victim.

# Debian/Ubuntu
sudo apt install inetsim

# Arch (AUR)
yay -S inetsim

Edit /etc/inetsim/inetsim.conf — the critical settings:

service_bind_address  10.20.0.1   # your gateway VM IP on victim-net
dns_default_ip        10.20.0.1   # all DNS resolves to yourself
http_version          1.1
start_service         dns
start_service         http
start_service         https
start_service         smtp
start_service         ftp

sudo systemctl enable --now inetsim

Point victim VMs to 10.20.0.1 as their default gateway and DNS server. All TCP/UDP traffic gets logged under /var/log/inetsim/.

For Windows samples, FakeNet-NG (from FLARE) is often more realistic. Run it on the analyst VM or a Linux gateway and redirect traffic with nftables:

sudo nft add table ip lab-redirect
sudo nft add chain ip lab-redirect prerouting \
  '{ type nat hook prerouting priority -100; }'
sudo nft add rule ip lab-redirect prerouting \
  iifname "virbr-victim" tcp dport != 22 \
  redirect to :8080

Capturing and Handling Malware Samples Safely

Acquiring samples carries legal risk. Use established, lawful repositories: MalwareBazaar, VirusTotal Intelligence (requires subscription), or samples you have collected yourself from honeypots you operate.

Setting up a capture directory

mkdir -p ~/labs/samples
chmod 700 ~/labs/samples
# Always store samples compressed and password-protected
# Convention: infected / infected is the standard zip password for sharing

# Hash before touching anything
sha256sum suspicious_file.exe | tee ~/labs/samples/suspicious_file.sha256

# Wrap in a password-protected zip immediately
zip -P infected ~/labs/samples/suspicious_file.zip suspicious_file.exe
rm suspicious_file.exe

Static analysis before detonation

# File type identification
file suspicious_file.exe
exiftool suspicious_file.exe

# String extraction
strings -n 8 suspicious_file.exe | less

# PE header analysis
python3 -c "import pefile; pe=pefile.PE('suspicious_file.exe'); pe.print_info()"

# Disassemble with radare2 (non-interactive)
r2 -A -q -c 'pdf @main' suspicious_file.exe 2>/dev/null | head -60

Traffic capture during detonation

# On the analyst/gateway VM, capture all victim-net traffic to a pcap
sudo tcpdump -i virbr-victim -w ~/labs/captures/$(date +%Y%m%d-%H%M%S).pcap

Verification

Before running any experiment, confirm isolation is real:

# From the victim VM, this should FAIL (no internet route)
ping -c 3 8.8.8.8

# This should SUCCEED (hits INetSim on gateway)
curl http://example.com

# Confirm host routing table does NOT include victim-net prefix on a physical interface
ip route show | grep 10.20.0

Troubleshooting

VMs cannot reach gateway: Check that libvirt created the bridge (ip link show virbr-victim) and that the VM NIC is attached to the correct network in the VM XML (virsh dumpxml vmname | grep network).
INetSim not responding: It binds to a specific IP — confirm your victim VM's default gateway matches service_bind_address exactly. Check sudo systemctl status inetsim for port conflicts with existing services.
Snapshots fail on LVM-backed storage: Internal QEMU snapshots require qcow2 format. LVM-backed VMs need external snapshots (--disk-only flag) plus memory state handling.
Wireshark cannot capture: Confirm your user is in the wireshark group and that dumpcap has the right capabilities: getcap /usr/bin/dumpcap should show cap_net_admin,cap_net_raw+eip.