Lab4PurpleSec: The Purple Team Homelab Everyone's Switching To

Stop piecing together fragmented security labs. If you're still juggling separate environments for Red Team attacks and Blue Team detection, you're burning precious training hours on infrastructure instead of actual skills. What if one modular, open-source project could give you a realistic enterprise network—with Active Directory, a SIEM, IDS/IPS, and intentionally vulnerable web applications—all speaking to each other in real-time?

Welcome to Lab4PurpleSec, the Purple Team homelab that's making experienced practitioners abandon their cobbled-together setups. Born from the previously named "Lab4OffSec" project, this environment doesn't hand you pre-built OVAs and call it "learning." It forces you to build from scratch, understand every network segment, and witness your attacks trigger actual alerts in Wazuh. That's the difference between playing CTFs and thinking like a defender who understands attacker tradecraft.

In this complete guide, I'll walk you through why Lab4PurpleSec is dominating cybersecurity training conversations, how to deploy it, and the exact scenarios that will level up your Purple Team skills. Whether you're a student breaking into the field or a seasoned analyst sharpening your detection engineering chops, this environment delivers something precious: realistic, repeatable, and measurable security practice.

What is Lab4PurpleSec?

Lab4PurpleSec is a modular, open-source cybersecurity homelab designed for comprehensive Purple Team training. Created by 0xMR007 and actively maintained, it simulates a near-enterprise network environment where offensive and defensive security converge. The project was renamed from "Lab4OffSec" to better reflect its core mission: bridging the gap between Red Team exploitation and Blue Team detection in a single, cohesive training ground.

Unlike many "homelab" projects that dump vulnerable VMs on your host and call it a day, Lab4PurpleSec enforces proper network architecture. You get segmented zones—WAN, DMZ, LAN, and Active Directory—connected through a real pfSense firewall running Suricata IDS/IPS. Your attacks must traverse these boundaries. Your detections must account for lateral movement, pivoting, and multi-stage intrusions.

The project integrates several battle-tested components:

• GOAD (Game of Active Directory) MINILAB: A deliberately vulnerable Active Directory environment from Orange Cyberdefense, featuring domain controllers and Windows clients with realistic misconfigurations
• Docker-based Web DMZ: Hosting OWASP-vulnerable applications and Metasploitable instances for web exploitation practice
• pfSense + Suricata: Enterprise-grade firewall and intrusion detection/prevention system monitoring traffic between segments
• Wazuh SIEM: Centralized security information and event management, ingesting logs from Linux and Windows endpoints, plus network device telemetry

What makes Lab4PurpleSec genuinely trend-worthy is its educational philosophy. No pre-built virtual machines. No black-box appliances. You install every component from official ISOs, configure each network interface, and troubleshoot your own misconfigurations. This "from scratch" approach ensures reproducibility, deep systems understanding, and the ability to customize for specific training objectives.

The project supports VirtualBox, VMware Workstation/Player, and Hyper-V, with documented deployment on Windows, Linux, and macOS host systems. It's MIT-licensed, actively seeking contributions, and designed with scenario-based learning at its core.

Key Features That Make Lab4PurpleSec Stand Out

True Network Segmentation Most homelabs flatline at "attacker VM and target VM on same network." Lab4PurpleSec implements proper defense-in-depth architecture: WAN (simulated internet), DMZ (exposed services), LAN (internal corporate network), and AD (domain-joined systems). Your pivoting skills actually matter here.

Integrated Detection Stack The Wazuh SIEM manager ingests syslog, Windows Event Logs, file integrity monitoring data, and Suricata alerts. When you Kerberoast a service account, Wazuh sees the abnormal Kerberos traffic. When you drop a webshell, Suricata flags the HTTP anomalies. You're not just attacking—you're learning what your attacks look like from the defender's chair.

Flexible Deployment Modes Choose your adventure: automated Vagrant/Ansible deployment for speed, or manual installation for maximum learning. The automated path spins up five core VMs in minutes, while manual installation walks you through every configuration decision.

Resource-Conscious Design With a minimum of 16GB RAM, you can run targeted scenarios. The documentation explicitly guides you to start only the VMs needed for your current exercise. The Wazuh manager demands 8GB alone, but you don't need it running during pure Red Team practice.

Scenario-Driven Architecture Every component exists to support realistic attack chains. The DMZ web server isn't just "vulnerable"—it's positioned for WAN→DMZ→LAN pivoting scenarios. The AD environment isn't just misconfigured—it's integrated with the SIEM so you can trace TTPs across the kill chain.

Cross-Platform Compatibility Whether you're on Windows with VMware Workstation Pro, Linux with VirtualBox, or macOS with your preferred hypervisor, the documented network configurations translate across platforms.

Real-World Use Cases Where Lab4PurpleSec Dominates

Purple Team Exercise Preparation

Organizations building internal Purple Team programs need reproducible environments. Lab4PurpleSec provides the baseline: your Red Team operator executes a technique, your Blue Team analyst validates detection coverage, and together you improve. The integrated Wazuh SIEM gives you concrete telemetry to analyze, not hypothetical "what if" discussions.

SOC Analyst Onboarding

New security operations center analysts need safe environments to learn alert triage without risking production systems. Deploy Lab4PurpleSec, execute the documented scenarios, and have trainees investigate the resulting Wazuh alerts. They'll see real Suricata signatures fire, correlate events across multiple log sources, and build incident response instincts.

Certification Practical Labs

Preparing for OSCP, PNPT, CRTP, or Blue Team certifications requires hands-on repetition. Lab4PurpleSec's Kerberoasting, pivoting, and web exploitation scenarios map directly to certification objectives. More importantly, the detection perspective prepares you for the "defend" portions of modern exams.

Detection Engineering R&D

Security engineers developing new detection rules need realistic attack data. Instead of hoping your production SIEM catches something interesting, generate known-bad activity in Lab4PurpleSec and refine your Sigma rules, Wazuh decoders, or custom Suricata signatures against guaranteed telemetry.

University Cybersecurity Curricula

Educators struggle to provide authentic infrastructure for capstone projects. Lab4PurpleSec's modular design lets students deploy incrementally: web exploitation in semester one, Active Directory attacks in semester two, and full Purple Team operations as a final project.

Step-by-Step Installation & Setup Guide

Prerequisites Check

Before touching any installer, verify your hardware against these tiers:

Critical insight: RAM is your bottleneck, not CPU. Virtualization performance depends heavily on memory availability. The Wazuh manager alone consumes 8GB.

Required software:

• Hypervisor: VirtualBox (free) or VMware Workstation/Player
• Vagrant: Version 2.2+ for automated deployment
• Ansible: Optional, for manual playbook execution
• ISO Images: See docs/SETUP/prereqs.md for complete list including pfSense, Ubuntu, Debian, Windows Server, Kali Linux

Automated Deployment (Recommended Path)

This deploys five core VMs automatically:

On Windows (PowerShell):

# Navigate to the automation directory containing Vagrantfile
cd automation

# Enable Ansible provisioning for configuration management
$env:VAGRANT_ANSIBLE = "true"

# Initialize and provision all automated VMs
vagrant up

On Linux/macOS (Bash):

# Navigate to the automation directory
cd automation

# Export environment variable to trigger Ansible provisioning
export VAGRANT_ANSIBLE=true

# Start VM creation and automated configuration
vagrant up

What deploys automatically:

• LAN-SIEM-LIN: Wazuh Manager (8GB RAM required)
• LAN-TEST-LIN: Ubuntu Desktop with GUI for testing
• LAN-ATTACK-LIN: Kali Linux for internal network attacks
• WAN-ATTACK-LIN: Kali Linux for external/DMZ-facing attacks
• DMZ-WEB01-LIN: Debian web server with Docker applications

Manual Components (Required for Complete Lab)

These require hands-on installation from official sources:

1. pfSense Firewall: Download ISO from Netgate, create VM with three network interfaces (WAN bridged, LAN 192.168.10.0/24, DMZ 192.168.20.0/24), follow docs/SETUP/pfsense_setup.md

2. GOAD MINILAB: Clone Orange Cyberdefense's GOAD repository, deploy via Vagrant per their documentation, then integrate into LAN segment using docs/SETUP/GOAD_setup.md

3. Metasploitable2/3: Deploy from Rapid7's official repositories for additional vulnerable targets

4. Wazuh Agents: Manual installation on Windows domain machines and pfSense, enrollment to LAN-SIEM-LIN manager

5. Web Applications: Docker Compose setup on DMZ-WEB01-LIN per docs/SETUP/Web_server_setup.md

Network Architecture Configuration

The pfSense VM (FW-PFSENSE) must start first—it's the lab's central nervous system. Configure three interfaces:

After pfSense installation, add firewall rules permitting required traffic, configure NAT for the Nginx reverse proxy, and deploy Suricata with appropriate rule sets.

REAL Code Examples from Lab4PurpleSec

The project's documentation and automation scripts contain concrete, usable code. Here are the critical examples with detailed explanations.

Example 1: Vagrant Environment Variable Configuration

This pattern appears in the Quick Start section, enabling Ansible provisioning:

# Windows: Set environment variable in current PowerShell session
$env:VAGRANT_ANSIBLE = "true"

# This tells Vagrant to execute Ansible playbooks after VM creation
# Without this, VMs would boot but remain unconfigured
vagrant up

# Linux/macOS: Export variable for current shell session
export VAGRANT_ANSIBLE=true

# Equivalent functionality across platforms
# The variable scope is session-only; add to ~/.bashrc for persistence
vagrant up

Why this matters: Lab4PurpleSec uses Vagrant's multi-provider provisioning. The VAGRANT_ANSIBLE flag triggers post-creation configuration that installs Wazuh components, updates attack tools, and establishes baseline security settings. Without this variable, you'd have five vanilla VMs requiring hours of manual configuration.

Example 2: Network Interface Configuration for pfSense

From the manual deployment documentation, the three-interface setup:

# Conceptual network topology from docs/SETUP/prereqs.md
# Applied during pfSense VM creation in your hypervisor

Network Adapter 1 (WAN):
  - Type: Bridged Adapter
  - Purpose: Connects to physical network for internet access
  - IP Assignment: DHCP from home router

Network Adapter 2 (LAN):
  - Type: LAN Segment / Host-Only
  - Subnet: 192.168.10.0/24
  - Purpose: Internal corporate network for AD, workstations, SIEM

Network Adapter 3 (DMZ):
  - Type: LAN Segment / Host-Only  
  - Subnet: 192.168.20.0/24
  - Purpose: Isolated zone for public-facing web services

Implementation insight: This segmentation forces realistic routing decisions. Your WAN attacker at 192.168.1.x cannot directly reach the domain controller at 192.168.10.x. You must compromise the DMZ web server (192.168.20.x), establish a foothold, then pivot through pfSense's carefully (mis)configured rules. This mirrors actual enterprise network architecture where flat networks are the exception, not the rule.

Example 3: Repository Structure Navigation

Understanding the project organization accelerates troubleshooting:

Lab4PurpleSec/
├── automation/
│   ├── Vagrantfile              # VM definitions: RAM, CPU, network, base boxes
│   ├── ansible/
│   │   ├── playbooks/           # Ordered execution: base hardening → tool installation
│   │   └── roles/               # Reusable configurations per VM type
│   └── scripts/
│       └── provision.sh         # Pre-Ansible bootstrap for dependency resolution
├── docs/
│   ├── SETUP/
│   │   ├── prereqs.md           # ISO checksums, download URLs, hypervisor-specific notes
│   │   ├── VMs_installation.md  # Step-by-step with screenshots for manual path
│   │   ├── pfsense_setup.md     # Interface assignment, rule creation, Suricata tuning
│   │   ├── Web_server_setup.md  # Docker Compose, Nginx reverse proxy, app deployment
│   │   ├── Wazuh_setup.md       # Manager installation, agent enrollment, custom rules
│   │   └── GOAD_setup.md        # Domain integration, DNS forwarding, trust relationships
│   └── TESTS/
│       ├── Web_server.md        # Validation: curl tests, vulnerability verification
│       ├── pfSense.md           # Connectivity matrix, Suricata alert generation
│       ├── Wazuh.md             # Log ingestion verification, dashboard confirmation
│       └── GOAD-MINILAB.md      # Domain join tests, authentication flow validation
└── CONFIGS/
    ├── web-server/
    │   ├── docker-compose.yml   # OWASP apps, Metasploitable services, logging sidecars
    │   └── nginx/
    │       └── reverse-proxy.conf  # DMZ-to-LAN routing, header sanitization
    └── pfsense/
        └── suricata-rules/      # Custom signatures for lab-specific detections

Navigation strategy: When your Wazuh agent fails to enroll, check docs/SETUP/Wazuh_setup.md first, then validate against docs/TESTS/Wazuh.md. When pivoting fails, verify CONFIGS/pfsense/ rules match your scenario's expected misconfiguration. The structure separates "how to build" from "how to verify" intentionally.

Example 4: Scenario Execution Pattern

The documented scenarios follow a consistent analytical framework:

## Scenario: Pivoting — WAN → DMZ → LAN

### Objective
Obtain initial access on DMZ web VM, then pivot to LAN/AD machine.

### Skills / Tools
- Reconnaissance (nmap, masscan)
- Tunneling (SSH dynamic forwarding, SOCKS proxy)
- Pivoting (proxychains, route injection)

### Execution Flow
1. WAN-ATTACK-LIN scans DMZ-WEB01-LIN perimeter
2. Exploit web vulnerability → shell on DMZ host
3. Establish SSH tunnel: `ssh -D 1080 user@dmz-web01-lin`
4. Configure proxychains for LAN segment routing
5. Scan LAN from DMZ perspective: `proxychains nmap 192.168.10.0/24`
6. Identify and attack AD member server

### Expected Detections
- **Web logs**: HTTP 200s with suspicious patterns in /var/log/nginx/access.log
- **IDS alerts**: Suricata ET SCAN rules firing on nmap from DMZ IP
- **Wazuh alerts**: Authentication anomalies, privilege escalation indicators

### Key Consideration
Adapt pfSense rules to simulate realistic misconfiguration—
too permissive DMZ→LAN rules enable pivoting but should
trigger policy violation alerts.

Learning value: This structure teaches attack chain analysis, not just tool usage. You must understand why each detection fires, which log source provides primary evidence, and how defenders would reconstruct your activity timeline.

Advanced Usage & Best Practices

Resource Orchestration Strategy Don't run everything simultaneously unless you have 64GB RAM. The documentation explicitly supports scenario-based VM management. Start with WAN-ATTACK-LIN and DMZ-WEB01-LIN for web exploitation practice. Add LAN-SIEM-LIN when you're ready to analyze detections. Spin up GOAD components only for Active Directory scenarios.

Snapshot Discipline Before executing destructive scenarios, snapshot your VMs. Lab4PurpleSec's "from scratch" philosophy means rebuilding is educational—but repetitive. Snapshot clean states, attack freely, restore, and iterate. This is especially critical for the Wazuh manager, where database corruption from excessive test events wastes hours.

Custom Rule Development Use the CONFIGS/pfsense/suricata-rules/ directory to add custom signatures. When you discover a novel detection gap, write the rule, test against your attack, and contribute back. This transforms consumption into production—exactly the skill progression hiring managers value.

Cross-Scenario Correlation Advanced practitioners should chain scenarios: webshell persistence from Scenario 2 becomes your initial access for Scenario 3's Kerberoasting. This forces you to manage multiple footholds, understand operational security from the attacker's view, and trace complex multi-stage detections.

Performance Optimization If RAM-constrained, reduce VM allocations in the Vagrantfile. The Wazuh manager needs 8GB for full functionality, but you can temporarily reduce GOAD domain controllers to 2GB for specific exercises. Document your modifications for reproducibility.

Comparison with Alternatives

When to choose Lab4PurpleSec: You need realistic enterprise architecture, want to understand both attack and defense perspectives, require offline operation, and value educational depth over instant gratification.

When alternatives win: VulnHub for quick, single-purpose practice; Hack The Box for competitive ranking and community; custom builds when you have specific, unusual requirements.

FAQ: Common Developer and Practitioner Questions

Q: Can I run Lab4PurpleSec on Apple Silicon (M1/M2/M3)? A: Yes, with caveats. Use VirtualBox 7.0+ or VMware Fusion with ARM-compatible base boxes. Some Windows VMs may require x86 emulation, which impacts performance. Consider running Linux-only scenarios for optimal experience.

Q: How long does full deployment take? A: Automated VMs: 30-60 minutes depending on internet speed. Manual components (pfSense, GOAD, agents): 4-6 hours for first-timers, 2-3 hours with experience. The investment pays dividends in understanding.

Q: Is this legal to use for commercial training? A: Yes, under MIT License terms. You must maintain copyright notices and license information. See LICENSE for specifics. The environment itself must remain isolated—never expose vulnerable VMs to production networks.

Q: What's the difference between Lab4PurpleSec and standalone GOAD? A: GOAD provides the vulnerable Active Directory. Lab4PurpleSec wraps it in complete network context: firewall rules you must bypass, SIEM that detects your techniques, and web applications serving as initial access vectors. It's GOAD plus enterprise realism.

Q: Can I add my own vulnerable applications? A: Absolutely. The Docker-based DMZ is designed for extension. Add containers to CONFIGS/web-server/docker-compose.yml, update Nginx routing, and document in your scenario notes.

Q: Wazuh isn't receiving logs—what's wrong? A: Check three things: agent enrollment completed (see docs/SETUP/Wazuh_setup.md), firewall rules permit 1514/1515 UDP/TCP between segments, and VM clocks are synchronized. Time skew breaks TLS certificate validation silently.

Q: How do I contribute improvements? A: See CONTRIBUTING.md for guidelines. The project welcomes documentation improvements, additional scenarios, automation enhancements, and verified configurations for new hypervisors.

Conclusion: Your Purple Team Journey Starts Now

Lab4PurpleSec represents something rare in cybersecurity training: an environment that respects your intelligence while demanding your effort. It doesn't hand you trophies for running msfconsole. It gives you the architectural complexity that real defenders wrestle with daily, then asks you to break it, understand it, and ultimately protect it better.

The "from scratch" philosophy isn't gatekeeping—it's the secret sauce. When you've manually configured Suricata rules, troubleshooted Wazuh agent enrollment across network segments, and watched your own Kerberoasting attempt trigger a detection you engineered, you've crossed from tool operator to security practitioner.

Whether you're preparing for certification, building a SOC training program, or simply hungry for deeper understanding, Lab4PurpleSec delivers. The modular design grows with you. Start with web exploitation in the DMZ. Progress to Active Directory compromise. Eventually, you'll be writing custom detection rules and validating them against live attacks in real-time.

Ready to stop simulating and start practicing? Clone Lab4PurpleSec from GitHub today, block out your weekend for initial deployment, and join the growing community of practitioners who've discovered what realistic Purple Team training actually feels like. Your future self—whether in a SOC, on a Red Team, or architecting defenses—will thank you for the foundation you build here.

Have questions about deployment or scenario ideas? Open an issue in the GitHub repository—the maintainer actively responds, and your question likely helps others too.