Converting CVEs Into Capability: Your Home Lab Playbook

I’ve written before about why your old computer is still worth something. Here’s one of the best uses for it: chasing the latest vulnerabilities in a sandbox where breaking things costs you nothing.

With an attack VM and a victim VM, you can turn a CVE advisory into hands-on understanding in an afternoon. Start with a recent vulnerability, or a famous older one, that has a public PoC. Search the CVE number or product name alongside “poc” and you’ll usually turn up a GitHub repo or write-up. A PoC (proof of concept) is working code that demonstrates the exploit, which saves you from having to do the exploit development yourself.

Confirm you can actually get your hands on the vulnerable software before you commit to a target. Older CVEs are often easier here since the affected version is archived and easy to find. Good places to start are notable vulnerabilities like Shellshock (CVE-2014-6271), BlueKeep (CVE-2019-0708), or Log4Shell (CVE-2021-44228).

Once you’ve picked your target, spin up a VM to host the vulnerable software. Any Linux distro will usually work as a base, though match the OS to whatever the advisory calls for. Install whatever the software needs to run: a database, a web server, dependencies. Snapshot the VM before you touch anything else. If you brick it mid-exploit, and you will eventually, you roll back and keep moving instead of rebuilding from scratch.

Don’t forget: isolate your lab network. Use a dedicated hypervisor, air-gap it, or put it on a separate VLAN with no access to anything that matters. Some exploits spread on their own. You don’t want something nasty jumping from your lab VM to your work laptop to your entire network. Assume anything you run here could break free.

Get your logging running first. Wireshark for network traffic, Sysinternals tools (Windows) or Osquery (Linux) for host-level activity. You want to see what the exploit actually does on the wire and on disk, not just whether it worked.

Run the PoC. It may not work on the first try, or the first PoC you find may not work at all. Try variations. Once you get the result you’re after, stop and take notes: how did it work, and what access do you have now?

Go back through your network and host logs for IOCs (indicators of compromise). Look for a file with a hash the advisory calls out, or a network connection an IDS would flag. This is what got left behind, and it’s the part most people skip.

You don’t need a polished report. You need a summary that answers the “so what.” I’ve worked with analysts who can walk through the technical mechanics of a fresh CVE in detail and then completely lose the thread when asked to explain why it matters. State the impact plainly: what can an attacker actually do with this, and who should care?

A home lab turns a CVE advisory from something you read into something you’ve done. Find a PoC, build a disposable range, snapshot it, run the exploit, and log everything along the way. The write-up is the step most people skip, and it’s the one that actually builds the skill.