⚠️ Safety & Ethics
A local lab is the only safe place to practice offensive techniques. Never scan, attack, or attempt privilege escalation against networks or hosts you do not own or do not have explicit written permission to test. This guide helps you create an isolated environment for learning and safe experimentation.
🎯 Lab Goals
By the end of this guide you’ll have:
A reproducible lab topology (VMs + networks)
Snapshots and rollback points for safe experiments
Vulnerable targets to practice recon and privesc
Logging/monitoring to learn detection and defense
Scripts and workflows to automate tests (lab-only)
🧱 Recommended Tools & Software
Host OS: Windows / macOS / Linux (any modern machine)
Hypervisor: VirtualBox (free) or VMware Workstation Player/Pro
Optional orchestration: Vagrant for reproducible VM builds
Useful host tools:
Wireshark,adb(if mobile labs),docker(for microservices)Vulnerable images / CTFs: Metasploitable2/3, OWASP Juice Shop, Damn Vulnerable Web App (DVWA), VulnHub boxes, WebGoat, TryHackMe local machines (where allowed)
🏗️ Lab Topologies (pick one to start)
Topology A — Single-Host Isolated Lab (Beginner-friendly)
Host machine runs VirtualBox.
Create a Host-only network (e.g., 192.168.56.0/24).
VMs:
Attacker VM (Kali/Parrot) — connected to Host-only
Target VM(s) (Metasploitable, DVWA) — connected to Host-only
Purpose: Completely isolated; no internet access unless you add NAT.
Pros: Safe, simple, no accidental internet scans.
Cons: No internet updates unless you add another adapter or provision.
Topology B — Lab with Internet (safe outbound only)
Attacker VM: Dual NICs — Host-only (for targets) + NAT (for internet updates)
Targets: Host-only only
Host NAT provides package updates for the attacker but prevents targets from reaching internet directly.
Pros: Attacker can pull tools/updates; targets remain isolated.
Cons: Slightly more complex networking.
Topology C — Segmented Red/Blue Lab (Advanced)
Multiple networks: Attacker net, Target net, Admin net, IDS/Logging net.
Add an IDS VM (Security Onion / Suricata) on a mirrored interface to learn detection.
Use VirtualBox NAT networks or internal networks to simulate routing and firewalls.
Pros: Best for learning detection/pivoting.
Cons: More resource intensive and requires networking knowledge.
⚙️ VM Recommendations & Sizing
Attacker (Kali/Parrot)
CPU: 2–4 cores
RAM: 4–8 GB (8GB recommended if running many tools)
Disk: 40+ GB
Target (Ubuntu/DVWA/Metasploitable)
CPU: 1–2 cores
RAM: 1–2 GB (Metasploitable is lightweight)
Disk: 10–20 GB
IDS/Logging VM (optional)
RAM: 4–8 GB
Disk: 40+ GB (for logs)
Adjust according to host capacity. Always leave resources for your host OS.
🧭 Networking setup step-by-step (VirtualBox example)
Create Host-only network
VirtualBox → File → Host Network Manager → Create.
Example host-only network:
192.168.56.1/24.
Create NAT adapter for attacker (optional)
VM Settings → Network → Adapter 2 → Attached to NAT.
This allows the attacker VM to reach the internet while targets remain isolated.
Set VM NICs
Attacker VM: Adapter 1 → Host-only; Adapter 2 → NAT (optional).
Target VMs: Adapter 1 → Host-only only.
Test connectivity
From attacker:
ping 192.168.56.X(target).From target: should not have direct internet access (unless you purposely provide it).
🛡️ Snapshots, Cloning & Safety Practices
Snapshot before experiments: Snapshot the target VM clean so you can revert after privesc attempts.
Use linked clones for space saving when creating multiple similar targets.
Label snapshots: e.g.,
clean,after-enum,post-privesc.Never attach lab VM NICs to bridged networks unless you intentionally and safely want them reachable on your physical LAN.
📥 Useful Vulnerable Targets & Where to Get Them
Metasploitable2/3 — classic vulnerable Linux VM for privesc practice. (Download from official sources.)
OWASP Juice Shop — modern vulnerable web app (node-based).
DVWA (Damn Vulnerable Web App) — web app vulnerable to classic web issues.
VulnHub — community-contributed vulnerable VMs (great for CTF-style boxes).
WebGoat — OWASP educational app.
Custom vulnerable VMs — build intentionally vulnerable services (old versions of web apps, misconfigured services).
Always download from official or trusted mirrors and verify checksums where provided.
🔁 Lab Provisioning Options
Manual — install ISO images, configure NICs, snapshot.
Good for granular control and learning.
Vagrant — automate VM creation with
Vagrantfile. Great for reproducible labs and for publishing a lab setup others canvagrant up.Docker — run isolated web-app services (Juice Shop, DVWA) for lightweight labs. Combine with Docker Compose to create multi-service targets.
Example Vagrant snippet (starter):
Vagrant.configure("2") do |config|
config.vm.box = "kalilinux/rolling"
config.vm.network "private_network", ip: "192.168.56.10"
config.vm.provider "virtualbox" do |vb|
vb.memory = "4096"
vb.cpus = 2
end
end
🔍 Logging, Monitoring & Detection (Learn Blue Team skills too)
Add Security Onion / Suricata / Zeek as a sensor to the lab to capture network traffic.
Configure an ELK stack (Elasticsearch, Logstash, Kibana) or use Graylog for log aggregation.
Forward logs from attacker/target VMs to the logging VM.
Practice creating detection rules (e.g., alert when a reverse shell signature appears).
Why: Understanding detection helps you write better defensive suggestions and interpret what an attacker might leave behind.
🧪 Lab Exercises & Playbook
Snapshot the target VM before each exercise. Revert after.
Exercise 1 — Basic Recon Workflow
From attacker: run
nmap -sC -sV -oN quick.txt 192.168.56.0/24.Run the
lab_recon.shfrom Part 8 against a target.Document the outputs.
Exercise 2 — SUID & Permission Practice
On target VM: intentionally create a vulnerable SUID file in a test folder, practice finding it with
find / -perm -4000.Revert snapshot after learning.
Exercise 3 — Web App Enumeration
Deploy OWASP Juice Shop or DVWA.
Use
gobuster,curl, andniktoto enumerate.Practice safe HTTP payloads in lab, and then harden the app config.
Exercise 4 — Privilege Escalation Lab
Use a VulnHub box designed for privesc.
Follow steps: initial enumeration → permissions audit → find privesc vector → document remediation.
Exercise 5 — Detection & Alerting
Trigger a simple reverse connection in lab (e.g., from target to attacker listener).
Observe the IDS/Suricata logs and create an alert rule to catch that behavior.
✅ Best Practices & House Rules for Your Lab
Always snapshot before making destructive changes.
Label VMs clearly (attacker, target1-dvwa, logging).
Keep the lab isolated — avoid bridged adapters unless intended.
Keep your host software updated, but avoid auto-updating lab targets (you may want old versions).
Maintain a changelog: record commands, dates, and objectives for each session.
Share lab configs via
Vagrantfileor Git for reproducibility.
🎯 Coming Up Next
Part 12: Post-Exploitation in Linux Environments — we’ll apply everything from the lab to learn credential hunting, pivoting, persistence, and safe cleanup — lab-only techniques and defensive remediation included.
💬 Got Questions?
Drop them in the comments or join our community on Discord for exclusive hacking tips and resources.
Don’t worry — mastery comes with practice.
Just open your terminal and hack your brain into CLI mode daily.
Let’s keep building. 💻⚔️