Red-Team Homelab - Complete Technical Documentation
This blog post documents the current, fully working state of a multi-segment Red-Team homelab. The focus of this environment is not on abstract theory or isolated attack techniques, but on building a technically accurate, reproducible lab that behaves like a real enterprise network.
Special attention was paid to reproducing the same architectural weaknesses, configuration pitfalls, and operational constraints that appear during professional red-team engagements. The lab exposes realistic failure modes, misconfigurations, and attack paths that cannot be simulated in flat or over-simplified setups.
At this stage, the lab is intentionally left insecure. The priority was not defense, but correctness: clean architecture, deterministic routing behavior, and a fully functional Active Directory environment. Defensive controls are deliberately postponed to avoid masking design or integration errors during the initial build phase.
Objective of the Lab (Current State)
The primary objective was to design and implement a realistic, multi-tier network lab with strict segmentation and clearly defined trust boundaries. The environment had to support real offensive workflows, including multi-hop attacks, pivoting, and directory-based abuse, rather than simplified CTF-style scenarios where everything is reachable by default.
To achieve this, the lab enforces several non-negotiable design principles.
There is a clear network separation between three security zones: an external attacker network, a demilitarized zone (DMZ), and an internal enterprise network. Each zone represents a different trust level and attack surface.
All routing between these zones is handled exclusively by dedicated Linux routers. No host performs routing implicitly, and there is no collapsed or hidden forwarding logic inside the hypervisor.
The DMZ intentionally contains vulnerable systems. These are not hardened targets but systems designed to be compromised first, serving as realistic footholds for further attacks.
The internal network is built around a fully functional Active Directory environment, including Windows and Linux domain members. This is essential for testing credential abuse, Kerberos attacks, and lateral movement techniques that depend on directory services.
The lab also establishes a clean baseline for advanced red-team activity, including pivoting, lateral movement, credential abuse, and full Active Directory attack chains.
Role mapping is intentionally simple and explicit. Kali Linux represents the external attacker. DVWA and Metasploitable3 act as DMZ footholds. A Windows-based Active Directory domain represents the internal enterprise environment.
Platform and Virtualization Layer
The entire lab runs on a bare-metal Proxmox VE host using KVM/QEMU for virtualization. This design choice avoids additional abstraction layers that could hide networking behavior or interfere with routing visibility.
Bare-metal virtualization ensures that Layer 2 and Layer 3 behavior is explicit and observable. This is particularly important when troubleshooting routing issues, asymmetric paths, or DNS-related failures during attack simulations.
The platform is characterized by the following properties:
- Proxmox VE runs directly on hardware without an intermediate host OS
- KVM/QEMU is used for virtualization
- Storage is provided via
local-lvm, enabling flexible disk management - Networking is implemented using Linux bridges (
vmbr*) - VirtIO devices are used for performance and compatibility
- SeaBIOS is selected for firmware compatibility
- The
pc-i440fxmachine type is used for maximum legacy support
This configuration is critical for older operating systems such as Windows Server 2008 R2, which is required for Metasploitable3 and often behaves unpredictably on newer firmware or machine types.
Virtual Machines and Roles (Current State)
The lab consists of eight virtual machines, each with a clearly defined role and no overlapping responsibilities. Every system exists for a specific architectural or attack-related purpose.
Two Debian-based systems act as routers. Router1 functions as the edge router between the attacker network and the DMZ. Router2 acts as the core router separating the DMZ from the internal network.
Kali Linux serves as the external attacker workstation and is the only system initially positioned outside the trusted environment.
Metasploitable3 and DVWA reside in the DMZ and represent intentionally vulnerable targets designed to be compromised early in an attack chain.
The internal network contains a Windows Server 2022 domain controller, a Windows domain client, and a Linux domain client. Together, they form a realistic Active Directory environment suitable for directory-based attacks.
The explicit separation of responsibilities prevents accidental shortcuts and enforces realistic attack paths.
Network Design and Segmentation
The network is divided into three strictly separated IPv4 segments, each representing a different trust level.
The attacker network (10.10.10.0/24) contains systems controlled entirely by the red team. The DMZ (10.20.20.0/24) hosts exposed services and vulnerable systems. The internal network (10.30.30.0/24) represents protected enterprise assets.
There is no Layer 2 overlap between these segments. No shared bridges, no VLAN shortcuts, and no dual-homed hosts that bypass routing controls. All traffic must traverse the routers explicitly.
This design ensures that pivoting and lateral movement are mandatory skills rather than optional conveniences.
Logical Network Plan
The following ASCII diagram reflects the actual implemented topology, not an abstract design concept. Every system, IP address, and connection shown here exists exactly as depicted.
Attacker Network
10.10.10.0/24
+--------------------+
| Kali Linux |
| Attacker Workstation
| 10.10.10.10 |
+--------------------+
|
|
+--------------------+
| C2 Server (planned)|
| Red Team C2 |
| 10.10.10.20 |
+--------------------+
|
|
+------------------+
| Router1 (Edge) |
| Debian |
| VMID 100 |
| |
| ens18: 10.10.10.1|
| ens19: 10.20.20.1|
+------------------+
|
|
DMZ Network
10.20.20.0/24
+--------------------+ +-----------------------+
| DVWA | | Metasploitable3 |
| Vulnerable Web App | | Vulnerable Windows |
| VMID 310 | | VMID 300 |
| 10.20.20.20 | | 10.20.20.10 |
+--------------------+ +-----------------------+
|
|
+------------------+
| Router2 (Core) |
| Debian |
| VMID 110 |
| |
| ens18: 10.20.20.254
| ens19: 10.30.30.1 |
+------------------+
|
|
Internal Network
10.30.30.0/24
+-----------------------+
| Windows Domain |
| Controller |
| windows-dc |
| VMID 400 |
| 10.30.30.10 |
+-----------------------+
| |
| |
+-——————————————+ +-—————————————————+
| Windows Client | | Linux Client |
| VMID 410 | | VMID 420 |
| 10.30.30.20 | | 10.30.30.30 |
| AD Member | | AD Member (SSSD) |
+-———————————————+ +-—————————————————+
This structure intentionally enforces pivoting, multi-hop routing, and correct mental models of network traversal.
IP Addressing
All systems use static IP addressing. Dynamic addressing was deliberately avoided to ensure deterministic behavior during troubleshooting, exploitation, and traffic analysis.
Each system’s gateway and DNS configuration is explicitly defined to prevent hidden dependencies or unexpected behavior.
Router Configuration and Routing Logic
IP forwarding is explicitly enabled on both routers and persisted across reboots. This ensures that routing behavior is intentional rather than accidental.
Static routes are configured manually on each router. Router1 knows how to reach the internal network only via Router2, and Router2 knows how to return traffic to the attacker network only via Router1.
This explicit routing model avoids asymmetric routing issues and mirrors real enterprise environments where missing or misconfigured return routes are a common source of operational failure.
Metasploitable3 Migration (VirtualBox → Proxmox)
Metasploitable3 was migrated instead of rebuilt to preserve its original vulnerabilities and configuration state.
The disk image was transferred, converted from VDI to QCOW2, imported into Proxmox, and configured with an explicit boot order. No changes were made inside the guest system, ensuring behavioral fidelity.
Active Directory Deployment
The domain controller runs Windows Server 2022 and provides only two roles: Active Directory Domain Services and DNS.
No additional services were installed to minimize noise and reduce troubleshooting complexity.
Before joining any clients, the domain was thoroughly validated using domain discovery tools, diagnostics, and DNS SRV record checks. Only after all checks passed was the domain considered stable.
Linux Client AD Integration (Problem and Resolution)
Linux AD integration proved to be the most critical and educational component of the lab.
Initial failures included unsuccessful domain discovery, broken SRV record resolution, and Kerberos authentication errors.
The root cause was not Active Directory, but DNS behavior on the Linux client. The system was using systemd-resolved with a local stub resolver and incorrect upstream DNS due to an additional interface.
The solution involved enforcing deterministic DNS behavior: explicitly configuring the domain controller as the only DNS server, disabling fallback mechanisms, and overriding resolver behavior.
Once corrected, domain joining, Kerberos authentication, and SSSD-based identity resolution worked reliably.
This mirrors real-world failures frequently encountered during internal assessments when Linux systems are improperly integrated into Windows domains.
Windows Client Integration
The Windows client was joined to the domain using standard procedures. DNS was correctly pointed to the domain controller, and domain logons were validated successfully.
End-to-End Verification
Connectivity and functionality were verified from multiple perspectives. The attacker can reach all intended segments, internal clients can resolve and authenticate correctly, and routing behaves exactly as designed.
Security Posture (Intentional)
No firewalls.
No filtering.
No restrictions.
This is deliberate. The current environment is a clean, noise-free baseline intended for controlled introduction of defensive measures later.
Current State Summary
The lab now provides a realistic, stable, and reproducible foundation for red-team operations. Network segmentation, routing, and directory services are fully functional and aligned.
What Comes Next: Planned Extensions of the Lab
With the current state of the lab fully functional and verified, the environment now represents a clean baseline. Everything works as intended: routing, DNS, Active Directory, Windows and Linux clients, and DMZ exposure. This is exactly the point where further realism can be layered on top without ambiguity.
The next steps are therefore not about “making it work”, but about making it realistic, restrictive, and observable.
Dedicated C2 Infrastructure in the Attacker Network
The most obvious missing component is the C2 server in the attacker network. While Kali currently acts as the attacker workstation, a real Red Team setup separates tooling from command-and-control infrastructure.
The C2 server will be placed in the attacker network (10.10.10.0/24) alongside Kali, but it will not be directly exposed to the rest of the lab. Instead, it will serve as a backend system responsible for:
- beacon handling
- tasking
- payload hosting
- encrypted communication channels
This component was intentionally excluded from the initial build because a realistic C2 setup requires additional architectural decisions, such as redirectors, TLS profiles, and listener separation. Treating it as “just another VM” would be misleading and unrealistic.
The C2 infrastructure will therefore be documented in a separate, dedicated post, focusing on OPSEC, traffic shaping, and realistic attacker workflows.
Enforcing Routing Constraints (No Flat Reachability)
At the moment, the lab allows full reachability across all networks. This was intentional during the build phase to validate correctness and simplify debugging.
The next step is to enforce strict routing constraints, ensuring that:
- systems within the same network segment can communicate normally
- systems across segments cannot communicate directly
- all inter-segment traffic must traverse the routers
This means introducing firewall rules on Router1 and Router2 so that:
- the attacker network cannot directly reach the internal network
- the DMZ cannot freely access internal systems
- only explicitly allowed traffic is permitted
Once enforced, this will eliminate any “cheating paths” and make pivoting mandatory. Compromising a DMZ system will no longer automatically grant access to the internal network. Instead, the attacker must establish tunnels, port forwards, or proxy chains through compromised hosts.
This step transforms the lab from a connectivity testbed into a true attack simulation environment.
Pivot-Only Access Model
After routing restrictions are in place, the lab will move to a pivot-only access model.
In this model:
- Kali cannot directly access the internal network
- internal systems are only reachable after compromising a DMZ host
- lateral movement requires explicit tunneling (SSH, SOCKS, agent-based pivots)
This aligns with real-world engagements, where internal networks are never directly exposed and attackers must chain compromises together.
Technically, this will involve:
- firewall rules on the routers
- removal of unnecessary routes
- validation that direct scans from Kali fail
- confirmation that pivot-based access succeeds
Intentional Misconfigurations and Weaknesses
With the architecture locked down, the next phase introduces intentional misconfigurations.
These are not random mistakes, but controlled weaknesses designed to simulate common enterprise failures, such as:
- overly permissive firewall rules
- weak or reused credentials
- excessive AD group memberships
- service accounts with SPNs suitable for Kerberoasting
- misconfigured DNS or time synchronization
- insecure delegation or NTLM fallback scenarios
Each misconfiguration will be introduced deliberately, documented clearly, and later exploited step by step. This allows the lab to be reset to a known-good state and reused for different attack paths.
Monitoring and Visibility from the Domain Controller
A critical addition to the lab will be monitoring and visibility, implemented directly on the Domain Controller.
The goal is to observe what attacks actually look like from the defender’s perspective, not just to execute them.
Planned monitoring components include:
- enhanced Windows Event Logging
- Active Directory–centric audit policies
- authentication and Kerberos event tracking
- detection of unusual logon patterns
- visibility into LDAP, NTLM, and Kerberos usage
This monitoring layer turns the lab into more than just a Red Team playground. It becomes a dual-purpose environment, suitable for understanding both attack techniques and defensive signals.
In later stages, this can be extended with:
- log forwarding
- correlation tools
- behavioral baselining
From Baseline to Scenarios
Once all of the above is in place, the lab will move from “infrastructure” to scenario-based usage.
Examples include:
- DMZ web exploit → internal AD compromise
- credential reuse across segments
- Kerberos abuse from Linux
- full domain takeover with post-exploitation persistence
Because the foundation is clean and well-documented, each scenario can be replayed, reset, and modified without ambiguity.
Closing Perspective
The current state of the lab is intentionally boring: everything works, everything is reachable, nothing is hidden.
That is exactly what makes it valuable.
From here on, every restriction, misconfiguration, and monitoring decision will be layered on top of a known-good baseline. When something breaks, it will break for a reason, not because of accidental misconfiguration.
This is the point where the lab transitions from building infrastructure to simulating real-world attacks.