cybersecurity · Apr 19, 2026 · 18 min read

Build Your Own Pentesting Lab.
part 2: installing VMware and Kali Linux.

The foundation of every pentest lab is a hypervisor and an attack machine. By the end of this post, both will be running on your computer. All three operating systems covered.

// series: build your own pentesting lab from scratch
  1. Why You Need a Pentesting Lab (And What We’re Building)
  2. Installing VMware and Your Attack Machine (Kali Linux)
  3. Setting Up Your Targets (The Machines You’re Allowed to Break)
  4. Your First Hack (And Where to Go Next with TryHackMe)
// what we’re getting into
  1. The scenario: BrightPath needs you to build the toolbox
  2. Quick check: is virtualization turned on?
  3. Installing VMware on Windows
  4. Installing VMware on macOS
  5. Installing VMware on Linux
  6. Importing the Kali Linux VM
  7. First boot: logging in and looking around
  8. Updating Kali (do this before anything else)
  9. Quick tour: what’s inside this thing
  10. Take a snapshot (future you will thank you)
  11. Final checklist: confirm Part 2 is fully working

The scenario: BrightPath needs you to build the toolbox

Remember BrightPath Financial from Part 1? Your manager told you to set up internal pentesting. You now have a plan. You know you need a lab. You downloaded all the files. Now it’s time to actually build the thing.

Today we’re doing two things. First, we install VMware Workstation Player. That’s the hypervisor — the software that lets you run virtual machines. Think of it as the garage where all your cars live. Without the garage, the cars have nowhere to go.

Second, we import and boot Kali Linux. That’s your attack machine. The car with no speed limit. By the end of this post, you’ll have Kali running inside VMware, fully updated, and you’ll know where all the important tools live.

No targets yet. That’s Part 3. Today is about getting the foundation solid. Because if VMware is misconfigured or Kali is outdated, everything we do later breaks in annoying ways that are hard to troubleshoot.

Quick check: is virtualization turned on?

Before we install anything, we need to confirm your CPU’s virtualization feature is enabled. If it’s not, VMware will either refuse to start VMs or run them so slowly you’ll think something is fundamentally wrong with your computer.

Windows:

Open Task Manager (right-click the taskbar or hit Ctrl + Shift + Esc). Click the Performance tab. Click CPU. Look in the bottom right area for a line that says Virtualization: Enabled. If it says Enabled, you’re good. Skip ahead to the VMware install.

If it says Disabled, you need to turn it on in your BIOS. Restart your computer. During boot, hit the key that opens BIOS setup — usually F2, F10, F12, or Del depending on your manufacturer. Look for a setting called Intel VT-x, Intel Virtualization Technology, AMD-V, or SVM Mode. Enable it. Save and exit. That’s it.

note: Every BIOS looks different. If you can’t find the virtualization setting, Google your laptop or motherboard model plus “enable virtualization.” Someone has made a guide for your exact hardware. Guaranteed.

macOS:

Good news. If you’re on a Mac with an Intel chip, virtualization is always on. Apple doesn’t give you the option to turn it off. If you’re on Apple Silicon (M1, M2, M3, M4), VMware Fusion supports it natively. You don’t need to check anything. Just move on.

Linux:

Open a terminal and run this:

bash
egrep -c ‘(vmx|svm)’ /proc/cpuinfo

If the output is 0, virtualization is disabled. Enable it in BIOS the same way as Windows. If the output is 1 or higher, you’re good.

Installing VMware on Windows

You should have VMware-player-xxxxx.exe sitting in your Downloads folder from Part 1. If not, go grab it from the VMware website now. We’ll wait.

Step 1. Double-click the installer. If Windows asks “do you want to allow this app to make changes,” click Yes. It’s a hypervisor. It’s going to make changes. That’s the whole point.

Step 2. The setup wizard opens. Click Next. Accept the license agreement. You didn’t read it. Nobody reads it. That’s fine. Click Next.

Step 3. It asks where to install. The default location is fine. Leave it alone. There’s a checkbox that says “Add VMware application directory to the system PATH.” Check it. This lets you run VMware commands from the terminal later if you ever need to, and it costs you nothing.

Step 4. There’s a checkbox for “Check for product updates on startup” and “Join the VMware Customer Experience Improvement Program.” Uncheck both. You don’t need update nags popping up while you’re in the middle of exploiting a box, and you definitely don’t need VMware phoning home about your usage habits.

Step 5. Click Install. Wait. It takes a couple minutes. When it’s done, click Finish.

Step 6. Launch VMware Workstation Player. It’ll ask if you want to use it for free for non-commercial use or enter a license key. Choose free for non-commercial use. You’re learning. That’s non-commercial. If your company wants you to use it for work at BrightPath, they can buy the license. That’s their problem.

VMware is now installed on Windows. You should see an empty window that says “Welcome to VMware Workstation Player.” Beautiful. Lonely. We’ll fix that when we import Kali.

note: If Windows throws a Hyper-V conflict warning, it means Windows’ built-in hypervisor is competing with VMware. Open PowerShell as Administrator and run bcdedit /set hypervisorlaunchtype off then reboot. This disables Hyper-V so VMware can do its thing. If you use WSL2 or Docker Desktop, be aware this may affect them. For this lab, VMware takes priority.

Installing VMware on macOS

On Mac you’re using VMware Fusion Player. Same engine, different packaging. Apple tax without the actual tax since the personal use license is free.

Step 1. Open the .dmg file you downloaded. Drag VMware Fusion into your Applications folder. That’s the install. macOS keeps things simple when it’s not busy asking you for permission to breathe.

Step 2. Open VMware Fusion from Applications. macOS will immediately ask if you’re sure you want to open it because it was “downloaded from the internet.” Yes. You are sure. Click Open.

Step 3. It’ll ask for your password to install some helper tools. These are kernel extensions that let VMware create virtual networks and talk to your hardware. Enter your password and let it do its thing.

Step 4. It asks for a license key or personal use. Choose the free personal use license. You may need to create a Broadcom account (they bought VMware). Yes, it’s annoying. Do it anyway. It takes two minutes and then you never think about it again.

Step 5. On macOS Ventura and later, it will ask for permission to load a System Extension. Go to System Settings → Privacy & Security, scroll down, and click Allow next to the VMware extension. You might need to restart.

VMware Fusion is now installed. You’ll see a window asking what you want to do. Ignore it for now. We’re importing Kali in a minute.

note: Apple Silicon users (M1/M2/M3/M4): make sure you downloaded the ARM version of Kali, not the AMD64 version. The Kali download page has both. If you grab the wrong architecture, the VM will refuse to boot and the error message will be completely unhelpful about why. Ask me how I know.

Installing VMware on Linux

Linux users. You already know what you’re doing more than you think. The install is a .bundle file, which is basically a shell script with an installer strapped to it.

Step 1. Open a terminal. Navigate to wherever you downloaded the file.

bash
cd ~/Downloads
ls VMware*

You should see something like VMware-Player-Full-xxxxx.x86_64.bundle.

Step 2. Make it executable and run it.

bash
chmod +x VMware-Player-Full-*.bundle
sudo ./VMware-Player-Full-*.bundle

It’ll run a text-based or graphical installer depending on your distro. Accept the defaults. Accept the license. Choose free for non-commercial use.

Step 3. You might need some build dependencies for the kernel modules. If VMware complains about not being able to compile modules, install these:

bash
# Ubuntu / Debian
sudo apt install build-essential linux-headers-$(uname -r) -y

# Fedora / RHEL / Rocky
sudo dnf install kernel-headers kernel-devel gcc make -y

# Arch
sudo pacman -S linux-headers base-devel

Then run the bundle installer again. It should compile the kernel modules and finish cleanly.

Step 4. Launch it.

bash
vmplayer

Or find it in your application menu. Same empty welcome screen as Windows. VMware is ready.

Importing the Kali Linux VM

Alright. VMware is installed on whatever OS you’re running. Now we bring in the attack machine.

Step 1. Extract the Kali download.

The file you downloaded from kali.org is a .7z archive. You need to extract it first.

extracting
Windows:  Right-click the .7z file → 7-Zip → Extract Here
macOS:    Double-click (The Unarchiver handles it)
Linux:    7z x kali-linux-*-vmware-amd64.7z

This gives you a folder with a bunch of files inside. The important one ends in .vmx. That’s the VMware configuration file. It tells VMware everything about this virtual machine: how much RAM, how many CPUs, what virtual disks to use, what network adapters to attach. It’s basically the VM’s birth certificate.

Step 2. Open it in VMware.

In VMware Workstation Player, click Open a Virtual Machine (or File → Open on Mac). Navigate to the folder you just extracted. Select the .vmx file. Click Open.

Kali appears in your VMware library. Don’t power it on yet. Let’s tweak a couple settings first.

Step 3. Adjust the VM settings.

Click on the Kali VM in the sidebar, then click Edit virtual machine settings (or the wrench icon on Mac).

recommended VM settings
Memory:       2 GB minimum, 4 GB if you have 16+ GB total RAM
Processors:   2 cores
Network:      NAT (for now — we change this in Part 3)
Display:      Check "Accelerate 3D graphics" if available

The RAM setting matters most. 2GB works for basic scanning and enumeration. 4GB is noticeably better if you’re running Burp Suite or multiple tools at once. Don’t go higher than half your total system RAM or your host machine will start swapping to disk and everything gets miserable.

note: We’re leaving the network on NAT for now so Kali can reach the internet for updates. In Part 3, we switch everything to Host-Only networking to create the isolated lab. NAT right now, Host-Only later. Don’t skip the switch in Part 3 or your “isolated” lab won’t be isolated at all.

First boot: logging in and looking around

Click Play virtual machine (the green play button). Kali boots up. It takes about 30 to 90 seconds depending on your hardware. You’ll see a boot screen with the Kali dragon logo, some text scrolling, and then a login screen.

The default credentials for the pre-built VM are:

credentials
Username:  kali
Password:  kali

Yes, the password is kali. No, this is not a secure password. Yes, it’s fine for a local lab VM that only exists on an isolated network. If anyone gets close enough to type a password into your lab VM, you have bigger problems than credential hygiene.

Log in. You’ll see the Kali desktop. It’s dark. It has a dragon. It looks exactly like what you’d imagine a “hacking operating system” looks like because the Kali team knows their audience.

First thing: VMware Tools. The pre-built VM usually has VMware Tools already installed, which gives you nice things like clipboard sharing between your host and the VM, drag-and-drop file transfer, and auto screen resizing. If your VM window stays a tiny fixed resolution when you resize it, VMware Tools might need reinstalling:

bash
sudo apt install open-vm-tools-desktop -y
sudo reboot

After the reboot, resizing should work. If it already works, skip this. No need to fix what isn’t broken.

Updating Kali (do this before anything else)

The pre-built image was packaged at some point in the past. Since then, tools have been updated, bugs have been fixed, and security patches have been released. Before you use Kali for anything, update everything.

Open a terminal. In Kali, it’s in the top menu bar or you can right-click the desktop. Run this:

bash
sudo apt update && sudo apt full-upgrade -y

Let’s break this down because we don’t just copy-paste commands on Project Pattie.

sudo runs the command as root. Package management needs root privileges because you’re modifying system files.

apt update refreshes the package list. It goes to Kali’s repositories and downloads the latest index of what’s available. It doesn’t install anything yet. It’s just checking the menu.

&& means “if the first command succeeds, run the second one.” If the update fails (maybe you don’t have internet), it won’t try to upgrade with stale data.

apt full-upgrade -y installs all available updates, including ones that require installing new packages or removing old ones. The -y flag auto-confirms so you don’t have to sit there pressing Y for every prompt. full-upgrade is more thorough than plain upgrade because it handles dependency changes.

This can take anywhere from 5 minutes to 30+ minutes depending on how old the image is and how fast your internet connection is. Go grab coffee. When it’s done:

bash
sudo reboot

Reboot to make sure any kernel updates take effect. Log back in when it comes back up.

Quick tour: what’s inside this thing

Kali comes with over 600 security tools pre-installed. You are not going to use most of them. Nobody uses most of them. But a handful are essential, and those are the ones you’ll use in Part 4 when we run our first actual pentest. Let’s find them now so you know where they live.

Click the Kali menu in the top left (or the Applications menu). You’ll see categories organized by attack phase. This is intentional. Pentesting follows a methodology, and Kali’s menu is organized around that methodology.

01 — Information Gathering is where reconnaissance tools live. This is always step one. Before you attack anything, you need to know what’s there.

key tools
nmap        — network scanner. finds hosts, open ports, services.
             this is the single most important tool in the box.
             you will use it on every single engagement.

nikto       — web server scanner. finds outdated software,
             misconfigurations, and known vulnerabilities.

dirb        — brute-forces directory names on web servers.
             finds hidden pages and admin panels.

whois       — domain registration lookup.
             tells you who owns a domain and when it expires.

05 — Vulnerability Analysis helps you figure out what’s actually exploitable once you know what’s running.

08 — Exploitation Tools is the big one. This is where Metasploit lives.

key tools
metasploit  — the exploitation framework. has thousands of
             exploits organized by target. point it at a
             vulnerable service, pick an exploit, fire.

searchsploit — offline database of public exploits.
              "does a known exploit exist for this service
              and version?" searchsploit answers that.

sqlmap      — automated SQL injection tool for web apps.
             we'll use this against DVWA in Part 4.

03 — Web Application Analysis is for when you’re testing websites and web apps.

key tools
burpsuite   — web proxy and scanner. intercepts traffic
             between your browser and the target. lets you
             modify requests, replay them, fuzz parameters.
             the free Community Edition comes with Kali.

wpscan      — WordPress vulnerability scanner.
             since half the internet runs WordPress,
             this gets used more than you'd expect.

You can also just open a terminal and type the tool name. Most Kali tools are command-line based. Let’s confirm the important ones are working:

bash
# check nmap version
nmap --version

# check metasploit is installed
msfconsole --version

# check sqlmap
sqlmap --version

# check nikto
nikto -Version

If all four return version numbers without errors, your attack machine is ready. If something is missing (unlikely on the pre-built image but not impossible), install it:

bash
sudo apt install nmap metasploit-framework sqlmap nikto -y

Take a snapshot (future you will thank you)

This is the step everyone skips and then regrets two weeks later when they break something and have to start over from scratch.

A snapshot saves the exact state of your VM at this moment. Fully updated, clean, tools verified, everything working. If you mess something up later — install the wrong package, misconfigure a network setting, accidentally delete something important — you just revert to this snapshot and you’re back to a known good state in seconds.

In VMware Workstation Player (Windows/Linux):

Player doesn’t have snapshot support in the free version. But there’s a workaround. Shut down the Kali VM completely (not suspend, shut down). Then go to the folder where your Kali VM files live and copy the entire folder somewhere else. That’s your manual snapshot. If things go wrong, delete the broken folder and copy the backup back.

Not elegant. But it works.

In VMware Fusion (macOS):

Fusion Player supports snapshots. With the VM running or stopped, go to Snapshots from the Virtual Machine menu. Click “Take Snapshot.” Name it something useful like clean-install-updated. Done.

snapshot naming suggestion
Snapshot name:   kali-clean-updated-2026-04
Description:     Fresh Kali import, fully updated, tools verified.
                 NAT networking (pre-lab-isolation).
                 Take new snapshot after Part 3 network config.
note: Take another snapshot after Part 3 when we set up the isolated network. That way you have two restore points: one with internet access (for updating later) and one with the lab network configured (for pentesting). You’ll bounce between them.

That’s Part 2. VMware is installed. Kali is imported, booted, updated, and ready. You know where the important tools live and you have a snapshot of this clean state. The attack machine is built.

But an attack machine with nothing to attack is just a really cool-looking Linux desktop. Time to fix that.

Final checklist: confirm Part 2 is fully working

Run these in your Kali terminal (and eyeball the host-side checks). If every step passes, you’re cleared to move on to Part 3.

bash
# 1. VMware Workstation Player launches on the host
#    -> Window says "Welcome to VMware Workstation Player"

# 2. Kali VM is in the library and powered on
#    -> Visible in VMware sidebar, status: Powered On

# 3. You're logged into Kali (run these inside Kali terminal)
whoami
#    -> kali

# 4. Network is reachable
ping -c 3 8.8.8.8
#    -> 0% packet loss

# 5. Kali package metadata is current
sudo apt update

# 6. No upgradable packages waiting
apt list --upgradable 2>/dev/null | grep -v Listing
#    -> empty output means you're fully patched

# 7. Core attack tools are installed and runnable
nmap --version
msfconsole --version
sqlmap --version
nikto -Version
#    -> all four return version numbers, no errors

# 8. Snapshot exists
#    Fusion: Virtual Machine -> Snapshots shows clean-install-updated
#    Player: backup folder exists alongside the .vmx file

Eight checks. If they all pass, the attack machine is built, verified, and protected by a known-good restore point. Future you is going to be very grateful for that snapshot.

next in series
Part 3: Setting up your targets (the machines you’re allowed to break)