Digital Playground: Building Your First Exploit Laboratory

Hey everyone! Welcome to week three of our exploit development journey. After exploring the mindset and ethical considerations that underpin good security research, it's time to get practical. Today we're building the foundation for all our future hands-on work: a secure, isolated laboratory environment where we can safely develop and test exploits without risking damage to production systems or accidental exposure to the internet.

• Digital Playground: Building Your First Exploit Laboratory
  • Why Isolation Matters: The Digital Containment Zone
  • Virtualization: The Foundation of Safe Testing
    • Virtual Machine Architecture Basics
    • Hypervisor Types: Choosing Your Foundation
    • Hardware Overview
  • Network Isolation: Containing the Danger Zone
    • My Recommended Network Setup
  • Building Your Attack VM: Parrot OS
    • Why Parrot OS Over Alternatives?
    • Basic Parrot OS Setup for Exploit Development
  • Target Environment Configuration
  • Additional Security Layers
    • 1. Snapshot Management
    • 2. Regular Backups
    • 3. External Storage Segregation
  • The Evolution of Your Lab Environment
  • Next Steps: Essential Security Tools
  • Until Next Time

Why Isolation Matters: The Digital Containment Zone

The tools and techniques we'll be developing throughout this series are powerful – that's what makes them valuable for security work, but it's also what makes them potentially dangerous if mishandled.

Think of exploit development like working with biological samples – you need a proper containment facility to ensure nothing harmful escapes into the wild. Your exploit lab serves the same purpose: creating boundaries that protect both your systems and the broader internet from accidental damage.

Virtualization: The Foundation of Safe Testing

Virtualization technology forms the cornerstone of our exploit development environment. By creating virtual machines, we can:

1. Isolate potentially dangerous processes from our main operating system
2. Create reproducible environments that can be reset to a clean state
3. Run multiple operating systems for cross-platform testing
4. Take snapshots to preserve interesting states or roll back after tests

Let's explore the key virtualization concepts that will support our exploit lab:

Virtual Machine Architecture Basics

At its core, virtualization creates the illusion of a complete computer system through software. This abstraction layer lets us run multiple isolated operating systems on a single physical machine:

Hypervisor Types: Choosing Your Foundation

There are two main hypervisor architectures to consider:

1. Type 1 (Bare-Metal): Runs directly on hardware (e.g., ESXi, Hyper-V, Proxmox VE)

   • Pros: Better performance, more isolation
   • Cons: Requires dedicated hardware, more complex to set up

2. Type 2 (Hosted): Runs on top of an existing OS (e.g., VirtualBox, VMware Workstation)

   • Pros: Easier to set up, more flexible for home labs
   • Cons: Slightly reduced performance, dependent on host OS stability

For most security researchers, Type 2 hypervisors offer the best balance of convenience and capability. I have personally used VMware Workstation for most of my lab purposes in the past and it's an excellent platform:

• Clean user interface that is easy to get around and manage
• Feature-rich enough for security testing and well developed
• Snapshot management is probably its best feature

However, VMware does have its quirks. Most of my work is done on a laptop and unless you've got a pretty beefy laptop (mine gets the job done) you're limited to how much you can really do. some of the vms we will be setting up will demand a decent amount of system resources at times and a virtual environment that runs on top of another system, especially since the host system itself consumes significant resources, which can bog things down. If you're hosting on a desktop system with good specs you will be fine either way but I demand a little more flexibility with my personal setup.

Because of that, I built a new system that will do well for many years to come and allow plenty of flexibility. Like many security researchers I have chosen to migrate over to Proxmox VE and have been quite happy with the switch. I will say it has been a new experience and some trials. Proxmox definitely hasn't been as easy to set up as VirtualBox and VMware have been. But it isn't exceedingly complex either. So lets get right into it and I'll go over my personal setup.

The above diagram lays out much of the structure of my personal setup and the main networks each are attached to. For this post we will be at a very high level, there’s quite a bit of setup required to reach this point, and still more to cover. This post will give you much of the structure to go set up your own lab environment and get your toes wet. Whether you decide to go with Proxmox as well or VMware, etc. is up to you.

Hardware Overview

The hardware I'm utilizing may be a tad overkill and may not be the best for some individuals but I wanted to have the flexibility that if I need it, it is there to use:

• Case: Lian Li Q58
• CPU: Intel i9-14900K (high thread count for virtualization)
• Motherboard: MSI MPG B760I Edge
• Memory: 64GB DDR5
• Graphics Card: MSI GTX 1080ti (that I scrapped from an older pc)
• Power Supply: Lian Li SP850
• AIO Cooling: Thermaltake TH280
• Primary Storage: 2x 4TB NVMe SSDs configured in ZFS RAID 1 (mirror) mode for redundancy and performance
• Backup/Utility Storage: 8TB External Drive (USB 3.0)

Network Isolation: Containing the Danger Zone

Proper network isolation is perhaps the most critical aspect of a safe exploit development environment. The goal is to create network configurations that allow your virtual machines to communicate with each other but prevent accidental connections to external systems.

My Recommended Network Setup

Most hypervisors offer several network attachment modes. I have kept my lab networking relatively simple.

I have 3 separate networks that provide the isolation I need while also maintaining that at times I will need to reach out to the internet.

VMBR0 - This network is utilizing a bridged network setup that allows communications to the outside world. These are more systems that are not so much utilized in our lab and are more systems that may serve specific purposes.

VMBR1 - Exploit dev environment - this is a purely isolated network with an entirely different IP range and subnet.

VMBR2 - Malware Analysis environment - if you're like me you may also dabble in some malware analysis, if you haven't taken that leap I highly recommend dipping your toes in. I'll have another series on malware analysis at another time but a lot of the skills you utilize in exploit dev and binary analysis will be the same skillset you utilize in malware analysis. Without the need to say this environment is extremely volatile and needs to be restricted by all means possible from reaching production systems. Running actual malware comes with some very nasty capabilities that can wreak havoc on a network and potentially even jump out of the vm to infect live systems and the utmost care must be taken.

Referring to my setup above you may also notice I have a couple containers setup that act as dhcp servers for each of the networks (VMBR1 and VMBR2). I am utilizing Alpine container templates for these with dnsmasq to automatically assign static network settings to hosts based on their MAC addresses. These are purely convenience for me, if you prefer manually setting this on the OS level that is an option. I prefer the centralized approach of editing the dnsmasq config file to always assign the same settings when the VMs are powered up.

With this setup:

1. The Attack VM can connect to both networks, with bridge disabled during actual testing
2. Target VMs connect only to the Host-Only network
3. For internet updates or tool downloads, I temporarily enable the Bridge adapter on the Attack VM
4. Critical testing happens with bridge completely disabled

Many of the VMs I have set up need internet capabilities at least for a time to download all the necessary packages and get set up. Proxmox allows us to set multiple different virtual network adapters that makes it easy to enable or disable networking as needed. Proxmox also has built in firewall capabilities that I personally appreciate, it's nice to not HAVE to set up an entire firewall system inside a VM. Proxmox has dedicated firewall rules and options that can be set on multiple different levels of the environment. VM level, Node level, and datacenter level and I implore you to spend some time with each, I personally have rules set up that allow specific ports that i need for my setup as well as rules that block inbound and outbound traffic by default. All the capabilities of the built-in firewall are there. This approach balances isolation with the practicality of being able to update your systems and download new tools.

Building Your Attack VM: Parrot OS

For my exploit development work, I personally use Parrot OS as my primary attack platform. It's a security-focused Linux distribution that comes with many of the tools we'll need pre-installed, has excellent hardware compatibility, and provides a clean, functional desktop environment.

Why Parrot OS Over Alternatives?

It's really just a personal preference, other options exist that are just as effective and feature rich. Kali Linux is a more well-known security distribution (and a perfectly fine alternative if you prefer it). I've found Parrot OS offers several advantages for exploit development work:

1. Lower resource requirements - runs better on modest hardware
2. More privacy-focused by default
3. Better out-of-the-box desktop experience with less configuration needed
4. Includes firejail for additional application sandboxing

Either option will work for our purposes, but the examples throughout this series will use Parrot OS.

Basic Parrot OS Setup for Exploit Development

Parrot Security OS comes preloaded with many tools essential for exploit dev, but pairing it with a virtual environment like Proxmox VE unlocks flexibility, safe rollback, and layered segmentation.

Although the base system requirements for Parrot OS are relatively modest, in my lab I go far beyond the minimum to ensure a smooth multitool workflow:

1. VM Resource Allocation (Lab Performance Spec)

   • CPU: 8 cores (overprovisioned for responsiveness during multi-window debugging)

   • RAM: 16GB (ideal for running multiple large tools concurrently like Binary Ninja, Burp, and browsers)

   • Disk: 150GB thin-provisioned on ZFS with compression enabled

   • Display: virtio-gpu for optimal GUI responsiveness when using noVNC or SPICE

   ⚙️ This is more horsepower than Parrot strictly needs, but it allows for uninterrupted heavy use—such as compiling custom payloads while simultaneously running fuzzers or emulators.

2. Proxmox VE CPU & Feature Configuration

   • Set CPU Type to host to enable full CPU instruction set access

   • Enable KVM virtualization and Nested Virtualization for potential nested hypervisor or emulation workflows

   • Ensure PAE/NX and ACPI are enabled in the VM's hardware config

   • Opt for UEFI BIOS (OVMF) to match modern OS requirements and bootloader support

3. Snapshot and Template Practices

   • After installing Parrot and customizing the base toolset, take a clean snapshot

   • Schedule regular snapshots through the Proxmox GUI for in-development rollbacks

   • Save time by converting your post-install system to a template for future project-based clones

   • Store snapshots and backups in your security dataset (rpool/vms/security) or on external storage (/mnt/lab_storage/backups)

4. Networking Considerations

   • Connect the VM to both vmbr1 (isolated security lab) and vmbr0 (bridged LAN) as needed

   • Firewall rules should restrict outbound access on vmbr0 to trusted update servers or SSH access only

   • This ensures you maintain a development-capable system without compromising your lab’s segmentation

✅ With Proxmox VE’s snapshot system, bridged networking, and CPU passthrough options, you get a high-fidelity development platform that balances flexibility with operational safety.

Target Environment Configuration

Along with your attack platform, you'll need various target systems to practice against. Here's my recommended minimal setup:

1. Vulnerable Linux VM

   • Debian or Ubuntu-based (for compatibility with most examples)
   • Minimal installation (to reduce resource usage)
   • Deliberately vulnerable configurations (which we'll cover in future posts)

2. Vulnerable Windows VM

   • Windows 10 (for modern exploitation techniques)
   • Older Windows versions for specific vulnerability categories (optional)
   • Defender disabled for testing

3. Purpose-Built Vulnerable Applications

   • DVWA (Damn Vulnerable Web Application)
   • Metasploitable
   • Specific vulnerable applications we'll build ourselves

I have a system that operates as a hub for various vulnerable web applications that are ready on the fly. This system has DVWA, bWAPP, Mutillidae, and WebGoat set up and ready to attack. The key is creating reproducible, controlled environments where you can practice safely without concern about stability or collateral damage. What areas of research you lean towards is up to you, I have a rather decent variety with my setup. Your lab can go any number of ways and may be more focused on a specific area of research. If you've got the disk space available to you and the system specs you can easily build out a very well rounded lab environment.

Additional Security Layers

A purpose-built lab needs more than isolation — it needs control, recoverability, and safe long-term operation. Here’s how I layer those protections in my Proxmox-based setup:

1. Snapshot Management

Frequent snapshots are essential in exploit development, where instability is part of the job. Being able to quickly roll back to a stable state is a huge time saver. It takes forming a bit of habit to get into but develop that habit because you will be thankful you had:

• Take snapshots before tool installs, exploit testing, or system changes

• Maintain a clean baseline for each VM (e.g., ParrotOS, Win10 Target)

• Name snapshots clearly (pre-ghidra, post-egghunter-test)

• Use Proxmox’s scheduler to automate periodic snapshots

• Leverage ZFS for fast, space-efficient, crash-safe rollbacks

2. Regular Backups

Backups complement snapshots and provide disaster recovery in the event a major mishap occurs:

• Daily ZSTD-compressed backups are scheduled via Proxmox's GUI

• I personally Store my backups on the external drive in relevant directories

• Covers all major VMs — dev boxes, targets, analysis environments

• Manual vzdump runs are taken before major experiments or risky operations

3. External Storage Segregation

My external drive is the main base for storing much of what I need in the day to day that are outside of the VM setup:

• For Exploit Dev:

  • /writeups – notes, logs, annotated crash reports, major writeups of findings

  • /data – compiled payloads, fuzzing results

  • /backups – routine and manual VM dumps

• For Malware Analysis:

  • /malware_repo – live samples and unpacked binaries

  • Accessible only to VMs on vmbr2 (e.g., FlareVM, REMnux)

  • Access is blocked from vmbr0 and vmbr1 via firewall rules and Samba ACLs

✅ Combined with ZFS, bridge isolation, and structured datasets, these layers make the lab safe, stable, and ready for repeated high-risk testing.

The Evolution of Your Lab Environment

As you progress through this series, your lab requirements will evolve. What starts as a single attack VM and target will gradually expand to include:

• Multiple target systems for different vulnerability classes
• Specialized tools that need their own environments
• Networking components for more complex attack scenarios

The beauty of virtualization is that you can expand your lab as needed without additional hardware. Starting with the basic setup described here gives you room to grow.

Next Steps: Essential Security Tools

Now that we have a framework for our laboratory environment, next week we'll populate it with the essential tools of the trade. we'll explore debuggers, disassemblers, fuzzers, and various utility software that form the exploit developer's toolkit. We'll focus on setting up Binary Ninja for our reverse engineering work. If you prefer IDA and have access to it, or Ghidra suits your workflow better, feel free to build out your own custom toolset. I find Binary Ninja to strike a very middle ground in affordability and functionality in design so that’s why it earns the spot as my primary disassembler.

Until Next Time

Building a proper exploit development laboratory is like establishing a solid foundation for a house – it's not the most exciting part of the process, but everything else depends on getting it right. The containment strategies and virtualization concepts we've covered today will serve you throughout your security journey, not just for exploit development, but for all kinds of security testing and research.

I'd love to hear about your own lab setups. What virtualization platforms do you prefer? Have you found other network configurations that work well for security testing? Are there additional isolation techniques you'd recommend?

Drop your thoughts in the comments, or reach out on X. I'm always curious to learn from other researchers' approaches.

Until next time,