Penetration Testing Lab Setup
Build practice environments that are isolated, repeatable, and tied to the rest of the Hackers Manifest methodology. Build a clean attack machine, add the targets you actually need, validate each layer, and snapshot or tear it down before you move on. Beyond the shared Kali prerequisite the labs are independent, so read them in whatever order matches what you are practising.
Build Rule
If you cannot explain how a lab is isolated, how to prove it works, and how to clean it up, it is not ready to run.
What Belongs Here
A page earns a place in Lab Setup only when its primary deliverable is a runnable, isolated, disposable environment you end up attacking, and it states all four of isolation, validation, cleanup and freshness. This section owns what you build, whether it is isolated, how to prove it works and how to destroy it. The section you arrived from owns the technique you run against it.
Three pages are the deliberate exception, because they are reference material that applies to every lab rather than a lab of their own: Lab Lifecycle, Isolation Patterns and Cost & Hardware. NetHunter is the other exception, explained beside the planner below. Nothing else earns a place here without building something you can attack.
Use a Lab, or Build One?
Two lab concepts run through this site, and they answer different questions. The Practice Labs blocks on technique pages point at labs that already exist — Hack The Box, TryHackMe, VulnHub, PortSwigger, a DVWA instance someone else hosts — so reach for those when you want to drill a technique today. This section is the other half: build, isolate, validate and destroy an environment you control, when no ready-made target matches the technique, the telemetry or the isolation boundary you need.
Safety Baseline
Choose Your Lab
Ten labs, each mapped to the outcome it unlocks and how to keep it isolated. Filter them to the ones your hardware and goal actually support; the same controls drive the Markdown and JSON plans.
NetHunter is the one deliberate exception to the rule above: it provisions a device rather than building a lab, and it stays in this section because it produces the mobile testing platform the other labs assume.
Cloud Security Lab sizing: the 4 GB is your local attack host. The scenario itself is sized by the provider and the module you deploy, so it is provider dependent — read the module before you apply it.
Kali NetHunter sizing: the platform is a Linux host plus a supported phone, not a VM — host memory is not the constraint; the device, its firmware and the download set are.
Lab Planner
Filter the ten labs below by what you want to practise and what hardware you have. The grid, the export and the share link all follow these four controls.
Kali Linux Setup is the one real prerequisite: every target lab assumes it exists and can reach the target on a host-only network. The Markdown and JSON exports number labs in export order, with Kali as step 01 when the filters select a target lab; that numbering is an export order, not a required study sequence.
Showing 8 of 10 labs — 2 critical-risk labs hidden by default
Kali Linux Setup
Baseline attacker VM with tool hygiene, project structure, wordlists, and snapshots.
Web Application Lab
Docker-based vulnerable web and API apps for practicing web testing workflows.
Vulnerable Virtual Machines
Downloadable and containerized targets for network, Linux, Windows, and web exploitation practice.
Active Directory Lab
Windows domain lab for Kerberos, AD CS, BloodHound, delegation, and privilege escalation paths.
Purple Team / SIEM Lab
Detection-capable enterprise lab using Wazuh, Elastic, Sysmon, Sigma, and attack replay.
Cloud Security Lab
AWS, Azure, GCP, and Kubernetes vulnerable environments with billing guardrails and teardown discipline.
Wireless Testing Lab
Authorized Wi-Fi testing with known adapters, driver checks, and a practice AP you control.
CI/CD Pipeline Lab
GitLab, Jenkins, Gitea, runners, registry, and deliberately vulnerable pipeline scenarios.
Recommended operating rhythm
Build one lab at a time, validate it, snapshot it, run the exercise, record evidence, then clean up or revert before starting the next one.
Universal Validation Checklist
Before setup
- - Document scope and authorization.
- - Confirm host resources and free disk space.
- - Create NAT, host-only, or internal networks deliberately.
- - Download installers from official sources and verify version notes.
Before exercises
- - Take a clean snapshot or export container state.
- - Prove the lab is reachable only from intended interfaces.
- - Run one benign test event and capture evidence.
- - Write the cleanup command beside the setup command.
Freshness Rule
Treat commands that install cloud tools, mobile firmware, SIEM stacks, Docker images, or security tools as version-sensitive. Check upstream release notes before reuse, then update snapshots and cleanup commands after every major tool upgrade.
Supporting Guides
Everything above builds one lab. These three apply to all of them: keeping a lab reproducible, keeping it off your real network, and keeping the hardware and the bill honest.
Lab Lifecycle
Snapshot, baseline and teardown: build once, reset in seconds, and destroy the lab without leaving exposed state behind.
Isolation Patterns
Host-only, internal, NAT Network and loopback-bind — what each one actually isolates, what it does not, and the command that proves it.
Cost & Hardware
What each lab really needs, which hypervisor to pick, and how to keep cloud spend and licensing from surprising you.
Authorization and Legal Scope
A lab removes the technical risk, not the legal one. Every rule on this page assumes you own the target, the network it sits on, and the account it runs in. The legal and compliance section covers engagement authorization, scope documents and the reporting obligations that follow; it is the reference for anything below.
- Hardware — your own device, or written permission from its owner. Never a work laptop under someone else's management.
- Radio — transmit only on equipment you own. Capturing frames that are not yours is not made legal by a monitor-mode adapter.
- Cloud — use an account you own and can close. Building a vulnerable stack in a client's tenant is a scope change, not a lab.
- Samples — handling real malware is a licensing and export-control question as well as a safety one. Keep samples inside the isolated lab and never in a shared repository.
- Third-party platforms — a hosted lab is governed by its own terms; "it is a training site" is not authorization to attack it.
Online Practice Platforms
Hack The Box
Retired machines, Pro Labs, AD practice
Intermediate practice after local fundamentals
TryHackMe
Guided rooms and beginner learning paths
Best first online platform
PortSwigger Web Security Academy
Free web vulnerability labs
Pair with the Web App Lab and Burp/ZAP
PentesterLab
Web, API, and badge-driven exercises
Focused vulnerability drills
Pwned Labs
Cloud security scenarios
Cloud practice without building every scenario locally
CyberDefenders
Blue-team and DFIR investigations
Pair with Purple Team and Malware labs
What Makes A Lab Report-Ready?
A lab you cannot evidence is a lab you cannot report from. Every lab records the same three things: the evidence, the fact that it repeats from a clean snapshot, and what the defenders saw. The evidence itself follows one shape across all ten labs:
Evidence
- One folder per lab, named for the lab and dated (
2026-10-17-malware-lab). - Prove it was isolated — the network list, the interface binding, or the IP plan, captured once.
- Prove it worked — one benign test event, captured before you change anything.
- Prove it is gone — the teardown output, not a promise that you ran it.
- Screenshots over recall — a command's output is evidence; your memory of running it is not.
Keep exports outside the VM. A snapshot rollback destroys everything inside it, including the notes you took.
Repeatability
The setup, validation, exploitation, and cleanup steps can be rerun from a clean snapshot.
Detection
Whenever possible, the lab records what was detected, missed, and tuned after the exercise.
Practice These Labs With
Web Pentesting
Practice web workflows against your local labs.
AD Attack Paths
Use the AD lab to practice Kerberos, BloodHound, and AD CS paths.
Cloud Pentesting
Apply the cloud lab to AWS, Azure, GCP, and Kubernetes testing.
DFIR
Use lab telemetry for evidence handling and incident response practice.
Internal Pentest
Turn vulnerable VMs and AD into internal assessment practice.
Reporting Templates
Document lab findings with professional reporting structure.