Building a Home Pentest Lab
- Install a hypervisor: VirtualBox (free, cross-platform) or VMware Workstation Player (free for personal use).
- Download the Kali Linux prebuilt VM image from kali.org — this is your attacker machine.
- Create an isolated internal network in the hypervisor (VirtualBox: "Host-only Adapter"; VMware: "Host-only" or custom vmnet) so lab traffic never touches your real LAN or internet.
- Download one vulnerable target to start: Metasploitable2 (classic, simplest) or spin up OWASP Juice Shop via Docker:
docker run -p 3000:3000 bkimminich/juice-shop - Set Kali's network adapter and the target's network adapter to the same internal/host-only network. Confirm they can ping each other but Kali's second adapter (NAT) is what gives you internet access for updates — the target gets no NAT adapter at all.
- Run
nmap -sV -sC <target-ip>from Kali against the target to confirm connectivity and start recon.
Progress:
- Install hypervisor, enable virtualization in BIOS/UEFI if needed
- Create isolated internal/host-only network
- Install Kali Linux VM (NAT adapter for updates + internal adapter for lab traffic)
- Install target VM(s) — internal adapter only, no NAT
- Verify isolation: target cannot reach the internet, host machine cannot be reached from the lab network
- Snapshot both VMs in clean state
- Practice cycle: recon → scan → exploit → post-exploit → document
- Reset to snapshot between exercises
1. Recon. nmap -p- -T4 <target> for full port sweep, then nmap -sV -sC -p<open-ports> <target> for service/version fingerprinting. For web targets, add whatweb and gobuster dir -u http://<target> -w /usr/share/wordlists/dirb/common.txt.
2. Vulnerability mapping. Match service/version output against known CVEs (searchsploit <service name/version>). For web apps, run nikto -h <target> and manually walk the app through Burp Suite (proxy traffic, repeater for request tampering).
3. Exploitation. Use Metasploit (msfconsole, search <cve or service>, use, set RHOSTS, run) or manual exploit scripts from searchsploit/Exploit-DB. Prefer manual exploitation over auto-pwn modules once comfortable — it's where the actual learning happens.
4. Post-exploitation. Once you have a shell: escalate privileges (linpeas.sh/winPEAS.exe for enumeration), dump credentials, pivot if multiple targets exist.
5. Document. Write a one-page findings report for every exercise: target, vulnerability, exploit used, impact, remediation. This is the habit that transfers directly to real-world authorized work and certs like OSCP.
6. Reset. Revert to snapshot before the next exercise so each run starts clean.
Example 1 — Web application: Input: "I want to practice web app exploitation" Output: Run Juice Shop in Docker. Proxy browser traffic through Burp Suite (Kali default). Work through SQL injection on the login form, then IDOR on the account/basket endpoints. Track progress against the public Juice Shop scoreboard to confirm you're finding the intended bugs.
Example 2 — Network service exploitation:
Input: "I want to practice exploiting a vulnerable Linux box"
Output: Boot Metasploitable2 on the internal network. nmap -sV reveals vsftpd 2.3.4 (backdoored version). searchsploit vsftpd 2.3.4 returns a known backdoor exploit; use it via msfconsole (use exploit/unix/ftp/vsftpd_234_backdoor) to get a root shell. Document the CVE and remediation (upgrade vsftpd, disable unused services).
Example 3 — Active Directory:
Input: "I want to learn AD attacks like a real engagement"
Output: Build a small AD lab with a Windows Server 2019/2022 domain controller VM (Windows eval ISOs are free for 180 days) plus 1–2 Windows 10/11 client VMs joined to the domain, all on the same internal network. Practice with BloodHound (map attack paths), Responder (LLMNR/NBT-NS poisoning), Impacket scripts (secretsdump.py, psexec.py), and Mimikatz for credential dumping on a VM you control. This mirrors HackTheBox's "Active Directory" track and most of OSCP's AD content.
Example 4 — Mobile/Android:
Input: "I want to test my own Android app or phone security"
Output: Use Android Studio's emulator (not your daily-driver phone) as the target. Install your own APK or a deliberately vulnerable app like DIVA or InsecureShop. Use adb to pull/inspect the APK, apktool/jadx to decompile and review code, MobSF (Mobile Security Framework, run via Docker) for automated static/dynamic analysis, and Burp Suite as an intercepting proxy for the emulator's traffic.
Example 5 — Wi-Fi/own hardware:
Input: "I want to test my home Wi-Fi security"
Output: Use a USB Wi-Fi adapter that supports monitor mode (check compatibility before buying — not all adapters work in a VM). Run the aircrack-ng suite from Kali against your own router's SSID: airmon-ng start wlan0, airodump-ng wlan0mon, capture a handshake, then attempt to crack it with a wordlist (aircrack-ng -w rockyou.txt capture.cap). Confirms whether your WPA2 passphrase is weak.
- Snapshot VMs before every exercise; reset after, not just before — leftover state from last time causes confusing results.
- Enable nested virtualization in your hypervisor if you ever need a VM inside a VM (e.g., Docker containers that themselves try to virtualize) — VirtualBox: enable "Enable Nested VT-x/AMD-V" in VM settings; check your CPU/BIOS supports it.
- Give Kali at least 4GB RAM / 2 CPUs and target VMs 1-2GB RAM minimum, or tools like Burp and Metasploit will crawl or crash.
- Use TryHackMe and HackTheBox alongside your own lab — they provide structured, legal targets mapped to real certification paths (OSCP, PNPT), so you're not limited to the few VMs you can build yourself.
- Keep a running notes file (Obsidian, CherryTree, or plain markdown) per target: commands run, output, what worked. This becomes your personal methodology reference and report-writing practice.
- Bridged networking instead of internal/host-only — accidentally exposes vulnerable targets to your real LAN or the internet; always double-check adapter mode before powering on a target VM.
- Forgetting the target has no NAT adapter — if it can reach the internet, your isolation failed; verify with
ping 8.8.8.8from the target (should fail). - Virtualization not enabled in BIOS/UEFI — causes cryptic hypervisor errors ("VT-x is not available") on laptops where it's disabled by default; enable Intel VT-x/AMD-V in firmware settings first.
- Running nested hypervisors without nested virtualization enabled — Docker Desktop or a VM-in-a-VM will fail silently or perform terribly without this.
- Testing against your daily-driver phone/laptop instead of a dedicated VM/emulator — full exploitation attempts can brick a device or lock you out of accounts; always use a disposable/snapshot-able target.
- Running Wi-Fi tools against a router that isn't yours — even "testing my own network" needs care if you share a connection (apartment Wi-Fi, ISP-managed mesh) with others who haven't consented.
- Skipping documentation — doing the exploit without writing it up means the next similar box takes just as long; the report step is where retention actually happens.