Offensive Security Researcher & Quantum Cryptography Analyst

How to Build a Red Team Lab for Beginners

Abdul Wahab Junaid
How to Build a Red Team Lab for Beginners

You can watch a hundred red teaming videos and read every writeup on HackTricks, but none of it sticks the way it does when you build your own vulnerable Active Directory domain, break it, fix it, and break it again. A home lab is the single highest-leverage investment a beginner in offensive security can make, and the good news is that it costs a lot less time and money than most people assume.

This guide walks through building a functional red team lab from scratch — hardware/virtualization choices, network design, vulnerable Active Directory setup, attacker infrastructure, and a realistic practice methodology you can follow week by week as your skills grow.

Why You Need a Red Team Lab

Reading about Kerberoasting or LLMNR poisoning is one thing. Actually setting up a domain controller, deliberately misconfiguring it, and then attacking it yourself builds a completely different level of understanding — the kind that shows up in real engagements when things don’t go exactly according to the tutorial.

A lab also lets you:

Core Lab Architecture

Hardware and Virtualization Options

You don’t need enterprise-grade hardware. A reasonably modern machine with:

is enough to run a functional lab. Choose a hypervisor:

Network Segmentation

Design your lab network to mimic a real corporate environment:

Critical safety note: Keep your lab fully isolated from your home network and the internet wherever possible, especially once you start running actual malware samples, C2 frameworks, or intentionally vulnerable software. A misconfigured lab bridging to your home Wi-Fi is how people accidentally infect their own devices.

Step-by-Step: Building the Lab

Step 1: Set Up Your Hypervisor and Virtual Networks

Install your chosen hypervisor and create at least two virtual networks: one for the internal “corporate” lab (host-only/internal mode) and one for your attack box (which may need NAT for downloading tools, but ideally on a separate virtual switch from the vulnerable machines).

Step 2: Build the Domain Controller

Install Windows Server (evaluation editions are free from Microsoft for lab use) and promote it to a domain controller:

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName "lab.local"

Purpose: The first command installs the Active Directory Domain Services role and its management tools on the Windows Server instance. The second promotes the server into a new Active Directory forest, creating the domain “lab.local” that the rest of your lab machines will join.

Step 3: Add Member Servers and Workstations

Join at least one additional Windows Server (for lateral movement practice) and one or two Windows 10/11 workstations to the domain:

Add-Computer -DomainName "lab.local" -Credential (Get-Credential) -Restart

Purpose: This joins the local machine to the “lab.local” domain, prompting for domain administrator credentials, and restarts the machine to complete the domain join — simulating a typical corporate workstation.

Step 4: Deliberately Misconfigure the Domain

This is the part tutorials often skip, and it’s the most important step. Real learning comes from building realistic misconfigurations, not a pristine default install. Introduce common real-world weaknesses such as:

Example: creating a Kerberoastable account with PowerShell:

New-ADUser -Name "svc-sql" -AccountPassword (ConvertTo-SecureString "Summer2024!" -AsPlainText -Force) -Enabled $true
Set-ADUser -Identity "svc-sql" -ServicePrincipalNames @{Add="MSSQLSvc/sql01.lab.local:1433"}

Purpose: The first command creates a new service account with a deliberately weak password. The second assigns it a Service Principal Name, making it a valid Kerberoasting target — any authenticated domain user can now request a Kerberos ticket for this account and attempt to crack it offline.

Step 5: Set Up Your Attack Box

Install Kali Linux as your primary attacker machine, on its own network segment with a route into the lab environment (simulating an initial foothold, e.g., a compromised workstation).

Step 6: Practice the Full Attack Chain

With the environment built, run through a realistic attack chain:

responder -I eth0

Purpose: Responder listens for LLMNR/NBT-NS broadcast requests on the network and responds to them, tricking Windows machines into sending NTLM hashes directly to your attack box — a common early foothold technique in real internal engagements.

GetUserSPNs.py lab.local/user:password -dc-ip 10.10.10.10 -request

Purpose: This Impacket script queries the domain for all accounts with SPNs (Kerberoastable accounts) and requests their Kerberos tickets, which can then be cracked offline with hashcat to recover the service account’s plaintext password.

bloodhound-python -u user -p password -d lab.local -ns 10.10.10.10 -c All

Purpose: This collects Active Directory relationship data (group memberships, permissions, sessions) and formats it for BloodHound, letting you visually map attack paths toward Domain Admin.

Step 7: Reset and Rebuild Regularly

Use hypervisor snapshots aggressively. Take a clean snapshot right after your domain setup and misconfigurations are complete, so you can revert instantly after each practice run rather than rebuilding from scratch every time.

Recommended Practice Progression

  1. Week 1–2: Build the domain, add a couple of misconfigurations, and practice basic enumeration (net user, net group, PowerView, BloodHound collection).
  2. Week 3–4: Practice credential capture (Responder, Kerberoasting) and offline cracking with hashcat.
  3. Week 5–6: Practice lateral movement using captured credentials (CrackMapExec/NetExec, psexec-style techniques).
  4. Week 7–8: Practice privilege escalation paths using BloodHound-identified attack paths (GenericAll, unconstrained delegation abuse).
  5. Ongoing: Add new misconfigurations you’ve read about in real-world writeups and practice detecting and exploiting them from scratch.

Extending Your Lab to Cloud and Hybrid Environments

Once your on-prem Active Directory lab feels comfortable, extending it to include cloud identity is increasingly worthwhile, given how much real-world red teaming now involves hybrid Azure AD/Entra ID environments.

Setting Up a Basic Azure AD Lab Tier

Practicing Cloud-Specific Attack Techniques

az ad sp list --all --query "[?appOwnerOrganizationId==null]"

Purpose: This Azure CLI command lists service principals in the tenant, helping identify potentially over-permissioned or misconfigured application identities — a common starting point for cloud privilege escalation in hybrid environments.

Combining an on-prem AD lab with a connected cloud tenant lets you practice increasingly common real-world scenarios: pivoting from a compromised on-prem account into cloud resources via synced credentials, or abusing an Azure AD role assignment to escalate privileges entirely within the cloud tenant.

Using CTFs and Pre-Built Vulnerable Machines to Supplement Your Lab

Building your own lab from scratch is valuable, but it shouldn’t be your only practice method. Supplement it with:

The combination of building your own environment (which teaches you the underlying mechanics deeply) and working through pre-built platforms (which exposes you to a wider variety of scenarios faster) produces a much more well-rounded skill set than relying on either approach alone.

Common Mistakes and Troubleshooting Tips

Security Risks and Defensive Recommendations

Since this lab teaches real attack techniques, treat the environment itself with security discipline:

From a defensive learning angle, once you’ve practiced the attacks, go back and practice the corresponding defenses:

Frequently Asked Questions

1. Do I need a powerful computer to build a red team lab? Not necessarily — 16GB RAM and a modern multi-core CPU is enough for a basic 3–4 VM Active Directory lab; 32GB gives more comfortable headroom for running additional machines simultaneously.

2. Is it legal to run these tools in my own home lab? Yes, as long as everything stays within your own isolated environment that you own and control — the legal concern only arises when these techniques are used against systems you don’t own or have authorization to test.

3. What’s the difference between using VirtualBox and VMware for a lab? VirtualBox is free and sufficient for learning; VMware Workstation Pro offers better performance and features like snapshot trees, which are genuinely useful once your lab grows more complex, but aren’t strictly necessary to get started.

4. How do I get free Windows Server licenses for my lab? Microsoft offers time-limited evaluation editions of Windows Server directly from their website, which are sufficient for lab purposes and can be reinstalled or reactivated as needed.

5. Should I use pre-built vulnerable AD environments instead of building my own? Pre-built environments (like GOAD – Game of Active Directory) are excellent for accelerating setup, but building your own at least once teaches you far more about how Active Directory actually works under the hood.

6. How often should I rebuild my lab? There’s no fixed schedule — rebuild whenever you want to practice a fresh scenario, or rely on snapshots to reset quickly for repeated practice on the same environment.

7. What should I learn first in my lab: attacking or defending? Start with attacking to understand how vulnerabilities are actually exploited, then follow up by practicing the corresponding defensive hardening — understanding both sides makes you a genuinely better security professional either way.

8. Should I extend my lab to include cloud environments like Azure AD? Eventually, yes — once you’re comfortable with on-prem Active Directory fundamentals, adding a connected cloud tenant reflects how most real-world enterprise environments actually operate today, and cloud identity attack paths are an increasingly common focus in real engagements.

9. Are platforms like Hack The Box a substitute for building my own lab? Not a full substitute, but a valuable supplement — building your own environment teaches you the underlying mechanics of Active Directory deeply, while guided platforms expose you to a wider variety of pre-built scenarios more quickly than you could build alone.

Conclusion

A red team lab is the fastest way to turn theoretical knowledge into practical, muscle-memory skill. Building your own vulnerable Active Directory environment, deliberately misconfiguring it, and then attacking it with the same tools used in real engagements teaches you far more than any video walkthrough. Start small, keep it properly isolated, use snapshots aggressively, and steadily layer in more realistic misconfigurations as you grow more comfortable. The time you invest here will show up directly in how confidently you handle your first real internal penetration test or red team engagement.

Exit mobile version