eJPT Day 1: Kali in a VM

I am studying for the eJPT right now, not after passing it, and the first real wall I hit was not a single nmap flag or a Metasploit module. It was getting Kali Linux running cleanly in a virtual machine so I could actually break things without breaking my laptop. This is the setup I landed on, written down the way I wish someone had handed it to me on day one.

The goal for day one is small and worth saying out loud: get a working Kali VM, take a snapshot, run apt update, and stop. That is it. You do not need to start hacking anything tonight. You need a lab you trust.

Why a VM and not a dual boot

You want Kali isolated. A VM gives you a sandbox you can wreck, roll back, and rebuild in minutes. You can snapshot a clean state, throw a sketchy lab target at it, and if something goes sideways you restore the snapshot instead of reinstalling your whole machine. For eJPT-style practice that snapshot habit is the single most useful thing here, so I will come back to it.

One more thing that trips people up: download the prebuilt Kali VM image. Offensive Security publishes ready-made images for VMware, VirtualBox, and a separate ARM build. Grabbing the prebuilt image means you skip the full installer, and the tooling comes preconfigured. The default credentials on those images are kali / kali. Change that password the moment you boot in.

Apple Silicon Mac: UTM with the ARM Kali image

If you are on an M1, M2, M3, or M4 Mac, your processor is ARM, not x86. That matters. You cannot run the standard amd64 Kali image at native speed, so you want the ARM64 build of Kali and a hypervisor that uses Apple's virtualization.

I use UTM. It is free, open source, and wraps QEMU and Apple's Virtualization framework in something usable.

• Install UTM (the free download from the UTM site, or the paid Mac App Store build if you want to support them).
• Download the Kali ARM64 image. Kali publishes one specifically for Apple Silicon.
• In UTM, create a new VM, choose Virtualize (not Emulate), and point it at the ARM image.
• Give it at least 4 GB of RAM and 2 CPU cores if you can spare them. More is better, but that is a working floor.

A real gotcha: some x86-only tools and exploits will not run natively on ARM Kali. For most eJPT enumeration and the lab targets you connect to over the network, this is fine, because the target box does the work, not your Kali host. Just know the limitation exists before you burn an hour debugging a binary that was never going to run.

Linux: virt-manager and KVM

If your host is already Linux, you have the best option built into the kernel: KVM. It is fast because it is real hardware virtualization, and virt-manager gives you a clean GUI on top of it.

On a Debian or Ubuntu base:

sudo apt update
sudo apt install qemu-kvm libvirt-daemon-system virt-manager
sudo usermod -aG libvirt $USER

Log out and back in so the group change takes effect. Then open virt-manager, create a new VM, and install from the Kali ISO or import the prebuilt qcow2 image if you grabbed one. Confirm virtualization is actually on with:

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

A result of 1 or higher means your CPU supports it. If you get 0, check your BIOS for Intel VT-x or AMD-V and enable it.

Everyone else: VirtualBox as the fallback

On Windows, or an Intel Mac, or if you just want one tool that works everywhere, VirtualBox is the reliable fallback. It is free and cross-platform, and Kali ships a prebuilt VirtualBox image so you import instead of install.

• Install VirtualBox plus the Extension Pack.
• Download the Kali VirtualBox image, then use File, Import Appliance.
• Boot, log in with kali / kali, and change the password.

On Windows, VirtualBox and Hyper-V can fight over the virtualization layer. If your VM is painfully slow or will not start, that conflict is the usual cause. It is a known issue worth looking up for your specific setup rather than guessing at it.

Networking: NAT versus host-only, and why it matters

This is the part that quietly costs people the most time, so slow down here.

• NAT lets the VM reach the internet through your host. You want this on day one to run apt update and pull tools. The VM can get out, but other machines cannot easily reach in.
• Host-only creates a private network between your host and your VMs with no internet. This is where you put a vulnerable lab target so it is isolated. Your Kali box and the target can see each other, and nothing leaks onto your home network or the internet.

The practical pattern: NAT while you set up and update, then host-only (or a dedicated internal network) once you are running deliberately vulnerable machines. Never put an intentionally broken target on a network that can reach the open internet. That is the whole reason to isolate.

Snapshot, then update

Before you touch anything else, take a snapshot of the clean VM. UTM, virt-manager, and VirtualBox all support this from the GUI. Name it something like clean-install. When a lab leaves your box in a weird state, you restore instead of rebuild.

Then run the one command that makes day one feel finished:

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

That is day one. Working Kali, password changed, snapshot taken, packages current.

Honest wrap

I am still on this road myself, taking notes as I go, so treat this as a fellow student's lab journal and not a finished authority's. If a write-up of what I am actually studying for the cert is useful, I keep my running eJPT Field Notes here: aldowebsitellc.xyz/shop/ejpt-field-notes. Either way, get the VM up and snapshot it. Future you will be grateful.