On-site Security Lab

1) Overview

Goal: Create a compact, repeatable security lab that runs four virtual machines to simulate a real‑time attacker vs. defender scenario. One Kali box is dedicated to offensive operations (red team), and the second Kali box focuses on monitoring/response (blue team). A Windows Server will act as an AD‑DC, and a separate Client VM will join the domain to serve as the primary target and endpoint. The environment is reachable remotely over Tailscale.

2) Lab Hardware & Host Setup

2.1 Hardware Selection

• Primary host: Dell OptiPlex mini PC — 6 cores / 12 threads, 16 GB RAM, 1 TB storage.
• Not recommended: Mac mini with 4 cores (insufficient for 4 concurrent VMs under expected load).

2.2 Host Configuration

• Do not join the host to the on‑site AD domain.
• Install Tailscale on the host only (not inside the guest VMs). Remote into VMs via the host using SSH/RDP/VMware Console.
• Install VMware Workstation to run the four VMs efficiently.

3) Network & Access

3.1 Topology (Logical)

• VM Network: NAT/Host‑only for lab internal traffic (adjust as needed for specific tests).
• Remote Access: Tailscale on host; use SSH/RDP to access VMs from authorized devices.

3.2 Identity Considerations

• Host remains workgroup‑joined (no AD).
• Windows Server provides AD services solely to the lab network.

4) Virtual Machines

4.1 Windows Server (AD‑DC)

• Role: Domain Controller (AD DS).
• OUs: Create an Users OU (~100 users) and an Admins OU.
• Password Policy: Randomize ~90% of user passwords; 10% receive assorted, policy‑graded passwords (simple → strong) according to privilege.
• Admins OU: Add Elias and Eddie with appropriate admin roles.

4.2 Client

• Purpose: Primary target for pen‑tests.
• OS: Windows or Ubuntu (join to the domain during setup if Windows; if Ubuntu, integrate with domain where applicable).

4.3 Kali – Red (Offense)

• Use for discovery, exploitation, credential access, and lateral movement tests.

4.4 Kali – Blue (Response)

• Use for network/host visibility, log review, and rapid response during red actions.

5) Active Directory Setup

5.1 OU & User Provisioning

• Create base OUs: Users, Admins, and optional Workstations.
• Generate ~100 standard users via PowerShell (see repo link below).
• Randomize 90% of passwords; log username, password, and time of reset to a secure file.
• Assign 10% with privileged roles; set graded passwords aligned to role sensitivity.

5.2 Example: Password Randomization Log Format

# Username,Password,ResetTime
jsmith,5P@u7A1k,2026-01-15T13:37:00Z
adoe,?L9vB2rr,2026-01-15T13:38:22Z
...

6) Client Configuration

• Join the Client to the domain during imaging/first‑boot (or configure SSSD/Kerberos if using Ubuntu).
• Install baseline tools (EDR/logging if testing, remote admin tools, patching).
• Harden baseline per role; capture a clean snapshot before exercises.

7) Attacker ↔ Defender Operations

7.1 Example Scenarios

• Recon → Phishing simulation → Initial access on Client → Privilege escalation → DC credential exposure attempt.
• Lateral movement tests from Client to Server, measuring detection and response speed.

7.2 Blue Team Tasks

• Establish logging (Windows Event Forwarding, Sysmon), periodic log reviews, and incident notes.
• Document Indicators of Compromise (IOCs) and lessons learned per run.

8) Implementation Plan

1. Repo & Storage: Create/organize GitHub repo for scripts and docs.
2. Host Prep: Add NVMe if needed, install Ubuntu (or preferred host OS), VMware Workstation, and Tailscale (host only).
3. VM Builds: Provision Windows Server, Client, and two Kali VMs. Snapshot clean states.
4. AD Provisioning: Create OUs, generate users, set randomized passwords, create Admins OU entries for Elias & Eddie.
5. Access & Tests: Verify remote access via Tailscale; run initial red/blue dry‑run.