Important resources to follow along with:

Setting up CAPEv2 involves installing and configuring a malware analysis sandbox on a Linux system, typically Ubuntu. CAPEv2 is an advanced fork of the Cuckoo Sandbox, designed for malware configuration and payload extraction. Below is a step-by-step guide to get you started, based on the official documentation and community discussions.

Note: The Proxmox hypervisor uses nested virtualization, CAPEv2 running on an Ubuntu VM will work with nested virt enabled, but for serious use, install CAPEv2 on a dedicated Ubuntu box. For testing or a homelab, this is fine for our purposes. We also have to make sure Proxmox itself then is secure (just in case malware escapes the VM).

Prerequisites#

  • OS: Ubuntu 22.04 LTS is recommended
  • Virtualization: Your CPU needs virtualization support (Intel VT-x or AMD-V).
  • Network: A stable internet connection and a virtual network interface (e.g. vmbrx)
  • Guest OS: A Windows VM (e.g., Win 10) for analysis
  • Resource Requirements: 16GB+ RAM, 4+ CPU cores, and 200GB+ storage (SSDs preferred). More is better if you’re running multiple VMs.

Considerations#

SCSI Controller#

  • Performance: Disk I/O speed for the Windows VMs, malware might do heavy read/write operations. We may need to account for unoptimized disk controllers, and SSD vs HDD.
  • Compatibility: The controller must work seamlessly with both the Ubuntu VM (host for CAPEv2) and the Windows guests CAPEv2 manages.
  • Detection Risk: Malware might detect certain controllers as signs of a virtualized environment, potentially altering its behavior.
  • Nested Virt Stability: Since we are running CAPEv2 in a Proxmox VM, the controller needs to play nice with nested KVM.

So which one to pick…?

After some research source from AI we find some pros/cons to each controller type:

LSI 53C895A / LSI 53C810#

Emulated SCSI controllers based on the LSI Logic hardware. The 53C895A is a later model than the 53C810, with better performance and wider compatibility.

Pros

  • Widely supported by Windows (one of CAPEv2’s guest OS) without extra drivers.
  • Less likely to be flagged by malware as a virtualization artifact (emulates real hardware).
  • Stable in nested setups—Proxmox and KVM handle LSI emulation well.

Cons

  • Slower than VirtIO because it’s emulated, not paravirtualized. Disk I/O might bottleneck under heavy malware activity.

LSI 53C895A is a decent choice if you prioritize stealth (malware evasion) over performance.

MegaRAID SAS 8708EM2#

An emulated controller, mimicking an SAS hardware RAID controller.

Pros

  • Also emulates real hardware, so less likely to be detected by malware than virtio scsi.
  • Slightly better performance than LSI 53C895A in some cases due to RAID emulation.

Cons:

  • Not as fast as VirtIO.
  • Less common in consumer setups—some malware might flag it as unusual.
  • Driver support in older Windows versions (e.g., Win 7) can be spotty.
  • Similar to LSI but less common. Not a top pick unless you’ve got a specific reason.

VirtIO SCSI / VirtIO SCSI Single#

VirtIO is a paravirtualized driver for KVM/QEMU

Pros

  • Best performance—paravirtualized, so it bypasses emulation overhead. Great for disk I/O-heavy malware.
  • Native to KVM, so it’s stable in your nested setup (Proxmox > Ubuntu > CAPEv2).

Cons

  • Requires VirtIO drivers in the Windows guest from Fedora.
  • Malware might detect VirtIO as a virtualization marker, potentially altering behavior (though CAPEv2 has anti-anti-VM features to mitigate this).

Best for performance, especially in nested virt. Recommended if you’re okay with the driver install and potential detection risk.

VMware PVSCSI#

A paravirtualized SCSI controller for VMware environments.

Pros:

  • High performance in VMware setups.

Cons:

  • Not native to KVM/QEMU. Proxmox can emulate it, but it’s not optimized for our stack.
  • Malware might detect it as a VMware artifact.
  • Potential stability issues in nested KVM.

Should you use it?

CAPEv2 uses KVM, not VMware. Avoid this.

Final Verdict#

Recommendation for performance: VirtIO SCSI Single

Why?

CAPEv2 benefits from performance, and VirtIO SCSI single offers the best disk I/O in a nested KVM setup like yours. It’s optimized for single-disk VMs (typical for CAPEv2’s Windows guests), and since CAPEv2 already uses KVM, VirtIO is the native choice. The “single” variant reduces overhead compared to regular VirtIO SCSI, which supports multiple devices you likely won’t need.

Tradeoff: Malware might detect VirtIO, but CAPEv2 has anti-detection features (e.g., in processing.conf) to mask virtualization.

Recommendation for stealth: LSI 53C895A

Why?

Why LSI 53C895A Might Enhance Stealth:

  • The LSI 53C895A mimics a physical SCSI controller commonly found in older server-grade hardware, as opposed to modern paravirtualized controllers like VirtIO SCSI. Malware often checks for virtualization-specific indicators, such as VirtIO drivers or devices, which are strongly associated with QEMU/KVM environments like Proxmox. The LSI 53C895A, being an emulated “real” device, may not immediately trigger these detection mechanisms, making the VM appear more like a physical machine.

  • VirtIO controllers are paravirtualized, meaning they require specific drivers in the guest OS and are optimized for performance in virtual environments. These drivers and their associated device signatures (e.g., “Red Hat VirtIO SCSI” in lspci) are well-known virtualization markers that malware can detect via system enumeration. The LSI 53C895A, however, doesn’t rely on paravirtualization and presents itself as a generic SCSI controller, potentially reducing the VM’s detectable virtualization footprint.

  • CAPEv2 often involves running Windows-based victim VMs where malware executes. However, the host (Ubuntu on Proxmox) and its configuration still influence the sandbox environment. If the Ubuntu host uses the LSI 53C895A for its own disks, it aligns with a stealthier setup by avoiding VirtIO-related artifacts that might leak into nested VM configurations or logs, which malware could theoretically access.

Tradeoff: You may sacrifice some or a lot disk I/O speed.

Setup Steps#

In Proxmox

  1. Load the Ubuntu 22.04 ISO
  2. Set RAM:

set the Ubuntu VM’s disk to use “VirtIO SCSI single” (as shown in your screenshot).

For CAPEv2’s Windows VMs, also use VirtIO SCSI: In virt-manager (on the Ubuntu VM), create the Windows VM with VirtIO SCSI as the disk controller.

Install VirtIO drivers in Windows: Download from https://fedorapeople.org/groups/virt/virtio-win/, mount the ISO in the VM, and install the SCSI driver.

Update CAPEv2’s cuckoo.conf to reflect the VM setup.

If you’re worried about malware detection and don’t mind slower performance, switch to LSI 53C895A. It’s less likely to be flagged, and Windows supports it natively—no extra drivers needed. But in a nested setup, the performance hit might be noticeable, especially with I/O-heavy malware.

Initial Setup#

Proxmox uses KVM (or LXC) to run your Ubuntu 22.04 VM. CAPEv2, inside that VM, also uses KVM to spin up its analysis VMs (e.g., Windows guests). This is nested virtualization: Proxmox’s KVM hosts Ubuntu, and Ubuntu’s KVM hosts CAPEv2’s guests.

CAPEv2 can run if Proxmox and the Ubuntu VM are configured correctly. Proxmox supports nested virtualization out of the box, but it needs to be enabled:

  1. Check Host CPU Support

On your Proxmox host, confirm nested virt is possible:

For Intel cat /sys/module/kvm_intel/parameters/nested

For AMD cat /sys/module/kvm_amd/parameters/nested

Should return Y or 1.

If N or 0, enable it in BIOS (VT-x/AMD-V) or load the module:

echo "options kvm-intel nested=1" | sudo tee /etc/modprobe.d/kvm-intel.conf

sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

  1. Enable Nested Virtualization in Proxmox VM

Your VM ID will be to the left sidebar of your Proxmox dashboard:

Edit your Ubuntu VM’s config in Proxmox (e.g., /etc/pve/qemu-server/VMID.conf) and add:

cpu: host

Or via GUI: VM > Hardware > Processor > Type > host.

This passes virtualization extensions to the VM.

Verify in Ubuntu VM: Inside the VM, check:

egrep -c '(vmx|svm)' /proc/cpuinfo

If > 0, nested KVM is ready.

Proxmox Networking and Considerations#

  • Use Proxmox firewall on the machine to block access to your local network and allow access only to Internet.
  • RDP is NOT safe because it needs a connection to your home network. DO NOT DO THIS for experimenting with malware.
    • Use the noVNC console in your Proxmox browser window instead.
  • Transfer all the files you need to have on the guest before downloading and experimenting with malware.

virt-manager (OPTIONAL)#

If you picked LSI 53C895A instead of VirtIO Single. The installation steps are identical except for the Windows VM setup in virt-manager—select SCSI with LSI 53C895A instead of VirtIO.