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:

• Practice legally and safely, without any risk of touching real systems
• Break things repeatedly without consequence
• Test new tools and techniques before ever using them in a paid engagement
• Build toward certifications like OSCP, CRTP, or CRTO with realistic hands-on practice

Core Lab Architecture

Hardware and Virtualization Options

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

• 16–32GB RAM (Active Directory labs are memory-hungry once you run multiple Windows VMs simultaneously)
• A multi-core CPU
• 250GB+ of free storage for VM disks

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

• VMware Workstation Pro or VMware ESXi — industry-standard, widely used in real red team infrastructure
• VirtualBox — free and sufficient for beginners, though slightly less performant
• Proxmox — a free, bare-metal hypervisor option if you want to dedicate a separate machine as a home lab server

Network Segmentation

Design your lab network to mimic a real corporate environment:

• An isolated internal network (host-only or a dedicated virtual switch) where your Active Directory domain lives — this should never route directly to the internet
• A separate attacker network segment representing your Kali/attack box, bridged carefully so you control exactly what it can reach
• Optionally, a simulated DMZ segment if you want to practice external-to-internal pivoting scenarios

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:

• Kerberoastable service accounts — create a service account with a Service Principal Name (SPN) and a weak password
• Unconstrained delegation on a member server
• Overly permissive ACLs — grant a low-privilege user GenericAll rights over a higher-privilege group
• Password reuse across multiple accounts, including a domain admin account reused on a workstation
• LLMNR/NBT-NS enabled (the Windows default) to practice Responder-based hash capture

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

• Create a free Microsoft Azure account (free tiers and trial credits are typically available for learning purposes)
• Set up Azure AD Connect to sync your on-prem “lab.local” domain to a corresponding Azure AD tenant, simulating a realistic hybrid identity environment
• Deliberately misconfigure cloud-side permissions (an over-permissioned service principal, an Azure AD role assigned too broadly) to practice cloud-specific attack paths

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:

• Hack The Box and TryHackMe — offer structured, guided machines and Active Directory-specific labs that reinforce concepts with immediate feedback and community write-ups if you get stuck.
• Game of Active Directory (GOAD) — a pre-built, deliberately vulnerable multi-domain Active Directory environment you can deploy quickly, useful once you understand the fundamentals and want to practice against a more complex, pre-configured environment.
• VulnHub — offers downloadable vulnerable VMs, useful for practicing individual exploitation techniques outside a full domain context.

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

• Building a lab that’s too clean. A default, unmodified Active Directory install teaches you very little — the real learning is in deliberately recreating common real-world misconfigurations.
• Not isolating the lab network properly. Bridging your vulnerable VMs directly to your home network risks real exposure — always use host-only or internal-only virtual networks for the vulnerable segment.
• Running out of RAM. Active Directory labs with multiple Windows VMs are memory-hungry; if things feel sluggish, reduce simultaneously running VMs or upgrade RAM before troubleshooting “broken” tools that are actually just starved for resources.
• Forgetting to license/activate Windows Server. Evaluation editions work fine for lab use but expire after 180 days — plan to rebuild or extend the evaluation period periodically.
• Skipping snapshots. Without snapshots, one bad net user command that locks out an account (or a ransomware simulation gone wrong) means rebuilding everything from scratch.
• Only practicing tools, not concepts. Running bloodhound-python without understanding what an ACL abuse path actually means will leave you stuck the moment a real engagement doesn’t match a tutorial exactly.

Security Risks and Defensive Recommendations

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

• Keep the lab fully air-gapped or heavily firewalled from your home network and the internet
• Never reuse lab passwords, snapshots, or configurations in any real production environment
• Store any malware samples or offensive tooling in a dedicated, isolated VM — never on your primary host machine
• Destroy or securely wipe lab VMs before repurposing hardware for anything sensitive

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

• Disable LLMNR/NBT-NS via Group Policy after practicing Responder attacks
• Set strong, non-guessable passwords on service accounts, and consider Group Managed Service Accounts (gMSA) to prevent Kerberoasting
• Audit and correct overly permissive ACLs discovered via BloodHound
• Enable Windows Defender Credential Guard and disable unconstrained delegation

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.