Build Your Own Pentesting Lab.
part 1: why you need one.

You can’t practice hacking on real systems. You can’t learn hacking without practice. A home lab solves both problems. Let’s build one from scratch.

The scenario: you just got voluntold to pentest

It’s your second week at a mid-size company called BrightPath Financial. You’re still figuring out where the good coffee is. Then your manager walks over, leans on your desk, and hits you with this:

“Hey so… we had a security incident last quarter. Nothing major. Just a phishing email that gave someone access to the payroll server. Anyway, the board wants us to start doing penetration testing internally. You have a cybersecurity background, right?”

You nod. Because of course you nod. You’re the IT person. You’re supposed to know everything from fixing printers to hacking into your own network. That’s in the fine print of every IT job description right between “other duties as assigned” and “must be a team player.”

Here’s the thing though. You can’t just fire up some hacking tools and start attacking the production network. That’s how you get fired. Or arrested. Or both, if the day is really going well.

What you actually need is a lab. A safe, isolated, completely separate environment where you can practice breaking into things without accidentally breaking something real. A place where if you crash everything, you just reset it and try again. Nobody gets paged. Nobody loses data. Nobody calls legal.

That’s what we’re building in this series.

The problem with learning security without a lab

Pentesting is one of those skills where reading about it does absolutely nothing for you. You can watch a hundred YouTube videos about how nmap works or what Metasploit does. You can take notes. You can make flashcards. And at the end of all that, you still won’t know how to do it.

Because until you actually type the commands, see the output, mess it up, Google why it didn’t work, try again, and finally get a shell on a target machine… you haven’t learned anything. You’ve just watched someone else learn. That’s called entertainment, not education.

But you can’t practice on real systems. That’s illegal. Doesn’t matter if you were “just testing” or “doing research.” If you don’t have explicit written permission to test a system, you’re breaking the law. Full stop. The Computer Fraud and Abuse Act does not have a “but I was learning” exception.

And you can’t just scan your own laptop. Pointing nmap at localhost is about as useful as shadow boxing in the mirror. Sure, it looks cool. But you’re not actually learning how to fight.

So where do you practice?

You build a lab. A pentesting lab is a collection of virtual machines running on your computer. One of them is your attack machine. The others are intentionally vulnerable targets — machines that were specifically designed to have security holes in them so you can find and exploit them. On purpose. Legally. Without anyone going to jail.

The whole thing runs on an isolated virtual network that is completely cut off from the internet and from your real home network. You can scan it, exploit it, crash it, and nuke it from orbit. The worst thing that happens is you have to re-download a file.

The lab blueprint: what we’re building and why

Here’s the full picture of what the lab looks like when we’re done with all four parts of this series. Three virtual machines on one isolated network, all running inside your computer.

┌─────────────────────────────────────────────────────┐
│                YOUR COMPUTER (Host)                  │
│                                                      │
│   ┌──────────────────────────────────────────────┐   │
│   │         VMware Workstation Player             │   │
│   │                                               │   │
│   │   ┌──────────┐   ┌───────────────────────┐   │   │
│   │   │   KALI   │   │   METASPLOITABLE 2    │   │   │
│   │   │  LINUX   │   │   (linux target)      │   │   │
│   │   │ (attack) │   │                       │   │   │
│   │   └────┬─────┘   └──────────┬────────────┘   │   │
│   │        │                    │                 │   │
│   │   ─────┴─── ISOLATED NET ──┴──┬──────────    │   │
│   │                               │              │   │
│   │              ┌────────────────┴──────────┐   │   │
│   │              │         DVWA              │   │   │
│   │              │   (web app target)        │   │   │
│   │              └───────────────────────────┘   │   │
│   │                                               │   │
│   │     ❌ NO connection to your real network      │   │
│   │     ❌ NO connection to the internet           │   │
│   └──────────────────────────────────────────────┘   │
│                                                      │
│   ✅ Your real network stays completely safe          │
└─────────────────────────────────────────────────────┘

Let’s break down each machine and why it’s there.

Kali Linux — your attack machine. Kali comes pre-loaded with hundreds of security tools. Network scanners, password crackers, vulnerability exploiters, web app testers… the whole toolkit. It’s free, it’s open source, and it’s what most pentesters use in the real world. When BrightPath’s manager asks “what tools are you using?”, you say Kali Linux and they nod approvingly because they’ve seen it on Mr. Robot.

Metasploitable 2 — your first target. Built by Rapid7 (the company behind Metasploit) to be ridiculously insecure on purpose. We’re talking default passwords, unpatched services, open ports everywhere. It’s a server that’s begging to be hacked. It exists specifically so people like us can practice finding and exploiting real vulnerabilities.

DVWA (Damn Vulnerable Web Application) — your web hacking target. A PHP web app that’s intentionally full of security holes: SQL injection, cross-site scripting, file upload vulnerabilities, command injection… all the greatest hits of web application security failures. If BrightPath has a customer portal (and they definitely do), you need to know how to test for these things.

All three sit on an isolated virtual network. They can talk to each other. They cannot talk to your real network or the internet. This matters. You don’t want your attack traffic accidentally hitting your roommate’s laptop or your ISP flagging your connection because you’re running network scans at 1am.

Hardware: can your computer handle this?

You don’t need a gaming PC or a server rack. But you do need a computer that isn’t completely ancient. Here’s what matters:

RAM is the big one. Each virtual machine needs its own slice of memory. Kali wants 2GB minimum. Metasploitable needs about 512MB. DVWA runs fine on 512MB. Add in what your actual computer needs to not die (Windows, macOS, or Linux), and you’re looking at needing at least 8GB total. 16GB is where things stop feeling sluggish. If you have 8GB you can make it work. You’ll just need to be disciplined about only running two VMs at a time.

Storage matters more than you’d think. Kali’s virtual disk is about 20GB. Metasploitable is about 2GB. DVWA is about 8GB. Plus VMware itself. You want at least 50GB of free space, and an SSD makes a massive difference. If your VMs are running off a spinning hard drive, you’ll be watching loading bars. A lot of loading bars.

CPU needs to support virtualization. Almost every Intel or AMD processor made in the last 10 years supports this, but it might be turned off in your BIOS. We’ll check that in Part 2. The feature is called VT-x on Intel chips and AMD-V on AMD chips. If it’s disabled, your virtual machines either won’t start or will run so slowly you’ll think the computer is broken.

Any operating system works. I’m covering Windows, macOS, and Linux in this series. VMware Workstation Player runs on Windows and Linux. For Mac users, we’ll use VMware Fusion Player, which is the same thing with a different name and a turtleneck.

MINIMUM (it'll work but you'll feel it):
  CPU:      64-bit with virtualization (VT-x or AMD-V)
  RAM:      8 GB
  Storage:  50 GB free
  OS:       Windows 10/11, macOS, or Linux

RECOMMENDED (comfortable, no lag):
  CPU:      4+ cores
  RAM:      16 GB
  Storage:  100 GB free on SSD
  OS:       whatever you're comfortable with

The download list: grab all of this right now

Download everything below before you start Part 2. Nothing is worse than being in the middle of setting things up and waiting 45 minutes for a file to finish downloading. Get it all now. Future you will be grateful.

1. VMware Workstation Player (Windows/Linux) or VMware Fusion Player (macOS)

Go to VMware’s website and download the free version. Yes, there’s a free version. The paid versions have extra features you don’t need right now. We want the free one.

VMware Downloads:
https://www.vmware.com/products/desktop-hypervisor/workstation-and-fusion

Download it. Don’t install it yet. We’ll do that together in Part 2.

2. Kali Linux (pre-built VM image)

Do NOT download the ISO. I repeat. Do not download the ISO unless you enjoy manually installing operating systems for fun. And if you do, I respect that energy, but we’re not doing it today.

Go to the Kali website and download the pre-built VMware image. This is a virtual machine that’s already set up and ready to import. No installation wizard. You just open it in VMware and it boots up.

Kali Pre-Built VM (VMware version):
https://www.kali.org/get-kali/#kali-virtual-machines

Look for the VMware image. It's a .7z file.
You'll need 7-Zip to extract it.

3. Metasploitable 2

Hosted on SourceForge. It’s a .zip file containing a ready-to-go VMware virtual machine. About 800MB. Search for “Metasploitable 2 download SourceForge” and grab the zip. Don’t extract it yet.

4. DVWA (Damn Vulnerable Web Application)

DVWA runs on a web server, so there are a few ways to set it up. The easiest is a pre-built VM. We’ll handle the setup in Part 3, but if you want to get ahead:

DVWA GitHub:
https://github.com/digininja/DVWA

5. 7-Zip (Windows) or The Unarchiver (macOS)

You need something to extract .7z files. Linux users, you probably already have the tools. Windows users grab 7-Zip. Mac users grab The Unarchiver from the App Store. Both are free.

Why a local lab beats a cloud lab for learning

You might be wondering why we’re building this on your own computer instead of spinning something up in AWS or Azure. Fair question. Three reasons.

It’s free. Cloud labs cost money. Even a small EC2 instance running 24/7 adds up fast. Your computer is already sitting there doing nothing while you read this. VMware Player is free. Kali is free. The vulnerable VMs are free. The only thing you’re spending is disk space and electricity.

It’s always available. No internet required once everything is set up. You can practice on an airplane, at a coffee shop with terrible WiFi, or in your garage at 2am when you can’t sleep because you almost have that exploit working. The lab runs on your machine. Period.

It’s how pentesters actually work. In the real world, when you’re doing an engagement for a company like BrightPath Financial, you’re not running your tools from some cloud instance. You’re sitting on their network with your laptop, running Kali in a VM, scanning their infrastructure. Building a local lab teaches you the exact workflow you’ll use on the job.

Real world: how this plays out at an actual company

Let’s come back to BrightPath Financial because this is why building a lab isn’t just a fun project. It’s a career skill.

BrightPath’s network has a bunch of internal servers. A web server running the customer portal. A database server with financial records. A file share that everyone has access to. And an old print server that nobody has updated since 2019 because “it still works.”

Before you run a single scan against any of that, your manager is going to ask you some questions. What tools are you going to use? What’s your methodology? How do you know your scans won’t crash anything? Have you done this before?

If your answer is “I watched some videos and read the nmap documentation”, you’re going to get a politely concerned look and a suggestion to maybe hold off on that.

But if your answer is “I’ve been running assessments in my home lab for months. I have a Kali attack box, multiple vulnerable targets, and I’ve documented my methodology across dozens of practice runs. Here’s my process document”, you’re going to get a very different reaction.

The lab isn’t just where you learn the tools. It’s where you build the evidence that you know what you’re doing. Every scan you run, every vulnerability you find, every exploit you execute in your lab is something you can screenshot, document, and point to when someone asks if you’re qualified.

Think about what BrightPath actually needs from their pentest. They need someone who can scan the network without crashing the payroll server. Who can find that old unpatched print server everyone forgot about. Who can test the customer portal for SQL injection without accidentally deleting customer data. Who can write a report at the end that says “here’s what I found, here’s how bad it is, and here’s how to fix it.”

Every single one of those skills gets practiced in the lab we’re building. The targets are different, but the methodology is identical. Metasploitable teaches you network pentesting. DVWA teaches you web app testing. The isolated network teaches you how to scope an engagement properly. And documenting your process teaches you how to write the report.

That’s Part 1. You know why you need a lab, what we’re building, what your computer needs, and what to download. No hands-on yet. That’s next.