Building a VAPT Home Lab: A Hands-On Walkthrough from Initial Access to Domain Compromise

Vulnerability Assessment and Penetration Testing (VAPT) is one of those skills you can't learn purely from theory. You can read every OWASP guide and watch every YouTube tutorial, but until you've actually chained an exploit together end-to-end and watched it work — or fail and force you to troubleshoot at 1 a.m. — it doesn't really click. This post walks through how I set up a personal VAPT lab and what a realistic attack path looks like inside it, from reconnaissance to a foothold on a Windows domain.

Why Build Your Own Lab

Platforms like TryHackMe and HackTheBox are great, but they're sanitized. Real environments are messier: misconfigured services, inconsistent patching, weird network quirks. Building your own lab forces you to deal with that mess — and it's also the only realistic way to safely practice attacks against Active Directory, which is where most real-world enterprise compromises happen.

My setup is intentionally simple:

• Attacker machine: Kali Linux, running as a VM
• Target environment: A Windows Server 2025 box configured as a full Active Directory Domain Services (AD DS) deployment
• Hypervisor: VMware, with everything isolated on a host-only or NAT network segment so nothing touches the outside world

This mirrors the bread-and-butter of professional VAPT engagements: an external or internal host, and a Windows domain to pivot through.

Step 1: Reconnaissance

Every engagement starts with recon, and the instinct to "just run Nmap" is fine but incomplete. I've been using Naabu, a fast port scanner from the ProjectDiscovery toolchain, to do an initial sweep before going deeper with targeted service enumeration. The value of Naabu in a lab context is speed — you get a quick picture of open ports across the target, then layer on something like Nmap's -sV -sC for service and script detection.

For the AD environment specifically, recon isn't just about ports. Tools like ADExplorer (part of Sysinternals) let you snapshot the directory structure once you have any foothold — even unauthenticated in some misconfigured environments — to map out users, groups, OUs, and trust relationships. And running PingCastle against the domain gives you a health-check score that mirrors what real AD security assessments report on: stale accounts, weak password policies, excessive privilege delegation, and so on. If you're new to AD attacks, PingCastle's output is genuinely one of the best teachers — it tells you exactly what's wrong and why it matters.

Step 2: Initial Access via Physical/HID Vector

Not every initial access vector is network-based. One of the most educational parts of my lab work has been experimenting with a USB Rubber Ducky — a keystroke injection device that impersonates a keyboard to execute a preprogrammed payload the instant it's plugged in.

The Ducky runs DuckyScript 3.0, and getting comfortable with it teaches you a lot about how trust boundaries break down at the human-interface layer. A basic payload chain looks like this:

1. Write a DuckyScript payload that opens a command shell (or PowerShell) on the target
2. Use it to download and execute a stager — in my case, a Meterpreter reverse shell payload
3. Catch the callback on the Kali attacker box with a Metasploit listener

This sounds simple, but the troubleshooting is where the real learning happens. A few issues I ran into that are worth knowing in advance:

• IP mismatches: If your listener is bound to the wrong interface IP (easy to mess up when running VMware NAT vs. bridged networking), your shell will just never call back. Always double-check ifconfig on the Kali box against what's hardcoded in the payload.
• PowerShell vs. CMD context errors: DuckyScript payloads often assume a specific shell context. A command that works fine typed manually in cmd.exe can silently fail — or behave differently — when injected into a PowerShell session, especially around execution policy and quoting.
• Windows Defender evasion: Out of the box, a vanilla Meterpreter payload gets flagged almost instantly by modern Defender. This is where encoding, obfuscation, or alternative delivery methods come into play — and where tools like Obfuscator-LLVM, which applies IR-level obfuscation passes, become relevant if you're compiling custom payloads rather than relying on off-the-shelf generators.

Step 3: Command and Control

Once you have a foothold, the next phase is establishing reliable C2. I've experimented with two frameworks in this lab:

• PoshC2: A PowerShell-centric C2 framework. Setup on Kali isn't always smooth — YAML config files are sensitive to formatting, and sed-based edits tend to be more reliable than manual editing when you're scripting repeatable lab builds. Pipenv dependency issues are also common enough that it's worth budgeting time for environment setup before you even get to the offensive work.
• Merlin C2: A cross-platform agent-based framework with a different protocol and deployment model than PoshC2. Comparing the two side by side is a good exercise in understanding how C2 architecture choices (HTTP/2 vs. other transports, agent check-in intervals, etc.) affect detectability.

Step 4: Post-Exploitation and Credential Access

This is where Active Directory labs really earn their keep, because credential theft and lateral movement are the core of most real breaches.

A few tools I've worked through:

• Mimikatz: the classic. Extracting plaintext credentials and hashes from LSASS memory.
• SharpDPAPI (from the GhostPack suite): targets Windows' Data Protection API, which underlies a lot of credential storage. Understanding the DPAPI key hierarchy — master keys, domain backup keys, how they chain together — is genuinely useful even outside offensive work, because it explains a lot about how Windows protects (and fails to protect) secrets at rest.
• LaZagne: a broader credential-harvesting tool that pulls saved passwords from browsers, mail clients, and other applications. Running it in a Python virtual environment keeps the dependency chain clean and avoids polluting your system Python.

Step 5: Detecting Your Own Attack

A VAPT lab is incomplete if it's offense-only. I run Wazuh (a host-based intrusion detection platform) and have been building out an Elastic SIEM stack — Elasticsearch, Kibana, Logstash, and Elastic Agent — to see the other side of the attacks I'm running. Mapping detection rules to MITRE ATT&CK techniques turns the whole exercise into a closed loop: attack, observe what got logged, tune detection, attack again. This is where VAPT work starts to feel less like "hacking for fun" and more like the actual job — because in a real engagement, the deliverable isn't the shell, it's the report that helps the defenders close the gap.

What's Next

The natural extension of this lab is scaling it up: more domain-joined hosts, more realistic misconfigurations, and tighter integration between the offensive and defensive sides so detection gaps become obvious. I'm also looking at IaC security scanning (Checkov, Trivy) to round things out — VAPT increasingly extends beyond traditional infrastructure into cloud and container environments.

If you're getting started with VAPT, my honest advice is: don't wait until you feel "ready" to build a lab. Spin up a free hypervisor, grab a Windows evaluation ISO, install Kali, and just start breaking things. The troubleshooting — the IP mismatches, the shell context errors, the YAML configs that won't parse — is the actual curriculum.