Homelab Build
Penetration Testing Lab Architecture

Why I Built This Lab

Most security certifications and courses teach you concepts. What they don't give you is a realistic environment to practice those concepts repeatedly, break things intentionally, and develop genuine muscle memory. I wanted to be able to practice Active Directory attacks — Kerberoasting, AS-REP roasting, lateral movement, DCSync — and web application exploitation without using live systems or depending on a VPN connection to a hosted lab.

The goal was a self-contained environment I could snapshot before any major attack chain, test techniques from a real Kali machine, and fully document what I was seeing. Every machine in this lab exists to teach me something specific.

Lab Overview

Network Architecture

Three completely isolated network segments prevent any accidental traffic leakage and simulate real network boundaries:

The Machines

Kali Attack Machine — 10.10.10.50

Primary attack platform. Full Kali Linux installation with the complete offensive toolkit. Dual-homed with access to both the attack network and (selectively) the AD environment for AD attack scenarios. All practice sessions run from here.

DC01 — Domain Controller — 10.80.80.2

Windows Server running the ad.lab domain. Intentionally misconfigured with vulnerable accounts to practice specific attack techniques:

Linux Web Server — 10.10.10.100

Ubuntu 22.04 LTS running multiple intentionally vulnerable web applications via Docker:

• DVWA (Damn Vulnerable Web Application) — SQL injection, XSS, file inclusion, command injection
• WordPress 5.0.0 — Outdated WordPress with vulnerable plugins for CVE practice
• OWASP Juice Shop — Modern JavaScript application for OWASP Top 10 practice
• WebGoat — Structured Java-based learning environment

What I Practice Here

Active Directory Attacks

• Kerberoasting — SPN enumeration, service ticket extraction, offline hash cracking
• AS-REP Roasting — Unauthenticated hash extraction from pre-auth disabled accounts
• Credential Spraying — Low-and-slow username enumeration without lockouts
• Lateral Movement — Pass-the-hash, WMI, PSExec
• DCSync — Domain controller replication abuse to extract all domain hashes
• Golden Tickets — Krbtgt hash abuse for persistent access

Web Application Exploitation

• SQL injection (manual + SQLmap)
• Authentication bypass via CVE exploitation
• Remote code execution via file upload vulnerabilities
• Privilege escalation from web shell to root

Post-Exploitation

• SUID binary enumeration and abuse
• Cron job hijacking
• PATH variable manipulation
• Credential dumping via Mimikatz

How I Use It

A typical practice session follows this workflow:

1. Take Proxmox snapshots on all target VMs (clean restore point)
2. Start from the appropriate starting position:
   - Unauthenticated: just Kali on the network, no creds
   - Assumed breach: john.smith credentials provided
3. Run through the attack chain completely from enumeration to objective
4. Document every command, output, and decision in Markdown
5. Restore to snapshot — repeat until execution is clean
6. Write the formal write-up from my notes

The snapshot restore workflow is intentional — it forces me to practice the same technique repeatedly until I understand exactly what each tool is doing and why each command produces the output it does.

What I've Learned

Technical Skills

• Kerberos fundamentals — How authentication tickets work, why pre-auth exists, what an SPN is and why it matters for security
• Active Directory concepts — Domain structure, privileged groups, delegation, trust relationships
• Web application security — How CVEs actually work at the code level, not just "run this tool"
• Defensive thinking — Building vulnerable environments forces you to understand how defenders would detect what you're doing

Soft Skills

• Documentation discipline — Every session is documented. Writing professional write-ups from notes is now a habit.
• Troubleshooting methodology — When things don't work (and they don't, constantly), systematic debugging
• Network architecture thinking — Building the lab required understanding how real corporate networks are structured

Lab Limitations

Being honest about what this lab is and isn't:

• Single physical desktop — no redundancy, no failover testing
• No external internet connectivity from lab VMs — isolated by design, but limits some scenarios
• All workloads on one machine — resource contention during heavy scanning or cracking
• No dedicated EDR/SIEM — detection and response techniques require external environments

Future Improvements

• SIEM integration — Deploy Wazuh or Elastic SIEM to see detection from the defender side
• Multiple AD forests — Cross-forest trust attacks and forest compromise scenarios
• Cloud infrastructure — AWS/Azure-integrated scenarios for hybrid attack paths
• More complex privilege escalation chains — Multi-hop escalation requiring chained vulnerabilities
• Linux AD scenarios — Kerberos attacks from and against Linux-joined machines

Tools Used