SOC Home Lab — Yousef Nabil

Executive Summary

What This Project Demonstrates

This project builds a functional SOC pipeline on a single laptop using three coordinated virtual machines. Rather than following a tutorial checklist, the goal was to understand how each component in a detection and response chain depends on the others — from endpoint telemetry generation through centralized log ingestion, alert correlation, and structured case management.

The lab was designed to answer a real operational question: if an event fires on a Windows endpoint, can I trace it from raw log through SIEM alert to an actionable case with investigation notes? Every configuration choice — dual-NIC networking, static host-only IPs, Sysmon as the telemetry source, archives.json as the proof layer — serves that objective.

🔎 Telemetry Generation

Sysmon captures process creation, network connections, file changes, and registry modifications on a Windows 11 endpoint. Windows Event Logs provide a complementary audit trail.

📊 Centralized Ingestion

Wazuh Manager receives agent data over ports 1514/1515, normalizes events in the Indexer, and surfaces them through the Dashboard for search and correlation.

📄 Case Management

TheHive receives alerts via its REST API, enabling promotion to cases with structured investigation notes — mirroring production SOC triage workflows.

Lab Architecture

Network Design & Data Flow

All three VMs use a dual-NIC configuration: Adapter 1 (Bridged) provides internet access via DHCP, while Adapter 2 (Host-only) creates a stable private lab network with static IPs. This separation ensures the detection pipeline remains functional regardless of host network changes — a design principle borrowed from production segmented environments.

HOST-ONLY NETWORK — 192.168.56.0/24

Endpoint

Windows 11

192.168.56.103

Sysmon + Wazuh Agent

→

SIEM

Wazuh

192.168.56.102

Manager + Indexer + Dashboard

→

Case Mgmt

TheHive

192.168.56.101

Docker Compose (StrangeBee)

Agent → 1514/1515 → Wazuh | Wazuh → API (9000) → TheHive

Why this topology matters: Bridged networking alone would break inter-VM communication whenever the host switches Wi-Fi networks. The host-only adapter guarantees that the detection pipeline — agent enrollment, log forwarding, API calls to TheHive — remains stable across reboots and location changes.

VM	Host-Only IP	Services / Ports	Resources
Windows 11	192.168.56.103	Sysmon64, Wazuh Agent	6-8 GB RAM, 2-4 vCPU, 60-80 GB
Wazuh	192.168.56.102	1514, 1515, 443 (Dashboard)	12-14 GB RAM, 4-6 vCPU, 80 GB
TheHive	192.168.56.101	9000 (UI/API), Cassandra, Elasticsearch	12-14 GB RAM, 4-6 vCPU, 80 GB

Environment Setup

Platform Preparation & Networking

1Hypervisor & Host-Only Network

VirtualBox with the Extension Pack (version-matched) serves as the hypervisor. A dedicated host-only network (vboxnet0) with DHCP disabled provides the stable lab backbone.

VirtualBox > Tools > Network
# Host-only network configuration
IPv4 Address:  192.168.56.1
IPv4 Netmask:  255.255.255.0
DHCP Server:   Disabled

2VM Networking — Dual Adapter Configuration

Every VM gets two adapters. This is the single most important configuration to get right — it determines whether the lab can survive a host network change.

All VMs — Adapter Settings
# Adapter 1 — Internet access
Attached to:  Bridged Adapter
Promiscuous:  Allow All
Cable:        Connected

# Adapter 2 — Stable lab network
Attached to:  Host-only Adapter (vboxnet0)
Cable:        Connected

3Static IP Assignment (Netplan)

Ubuntu VMs use Netplan for interface configuration. The bridged adapter stays on DHCP; the host-only adapter gets a static address that every other component references.

Wazuh VM — /etc/netplan/50-cloud-init.yaml
network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      addresses: [192.168.56.102/24]
      optional: true

Apply & Verify
sudo netplan try
sudo netplan apply
ip -br a     # Confirm both interfaces are UP with correct IPs

Netplan Gotcha

Netplan is indentation-sensitive and requires spaces — not tabs. A single tab character will cause netplan apply to fail silently or produce malformed configuration.

4Connectivity Validation

Before installing any services, verify full mesh connectivity across the host-only network. This eliminates networking as a variable for all subsequent troubleshooting.

From any Ubuntu VM
ping -c 2 192.168.56.101   # TheHive
ping -c 2 192.168.56.102   # Wazuh
ping -c 2 192.168.56.103   # Windows

SIEM Deployment

Wazuh — Manager, Indexer & Dashboard

Wazuh serves as the central nervous system of this lab. A single-node deployment bundles the Manager (receives and decodes agent events), the Indexer (stores and indexes for search), and the Dashboard (provides visual investigation interface). In production, these would be distributed across separate nodes — understanding the monolithic deployment first clarifies each component's role.

Installation

Wazuh VM (Ubuntu Server)
sudo apt update
sudo apt -y install curl unzip apt-transport-https lsb-release gnupg

# Download and run the all-in-one installer
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

# Ubuntu 24.04: Add --ignore-check if OS compatibility warning appears
sudo bash ./wazuh-install.sh -a --ignore-check

Service Validation

Every service must show active, and the agent enrollment ports must be listening. This is not optional — skipping validation here creates phantom issues later.

Post-Install Checks
sudo systemctl is-active wazuh-manager    # → active
sudo systemctl is-active wazuh-indexer     # → active
sudo systemctl is-active wazuh-dashboard   # → active

# Verify agent enrollment and data ports are listening
sudo ss -tulpen | egrep ':1514|:1515'

Dashboard Access

Retrieve the auto-generated admin credentials and confirm Dashboard is reachable over HTTPS.

Retrieve Credentials
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

# Access Dashboard
https://192.168.56.102

Case Management

TheHive 5.x — Docker Compose Deployment

TheHive provides the investigation layer. In a production SOC, analysts receive SIEM alerts and promote them to structured cases with evidence, investigation notes, and response actions. This lab uses TheHive's Docker Compose stack (StrangeBee) to mirror that workflow — Cassandra handles storage, Elasticsearch powers search, and the TheHive application manages cases through its REST API.

Docker Engine Installation

TheHive VM — Docker Setup
sudo apt update && sudo apt -y upgrade
sudo apt install -y ca-certificates curl gnupg git jq

# Add Docker GPG key and repository
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Install Docker Engine + Compose plugin
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
sudo usermod -aG docker $USER

TheHive Stack Deployment

Deploy StrangeBee Docker Stack
mkdir -p ~/docker && cd ~/docker
git clone https://github.com/StrangeBeeCorp/docker.git
cd docker/prod1-thehive

docker compose pull
docker compose up -d
docker compose ps       # All containers should show "Up"

First Startup

Cassandra and Elasticsearch initialization can take 2-5 minutes on first boot. If TheHive shows unhealthy, check docker logs cassandra before assuming misconfiguration.

Endpoint Configuration

Windows 11 — Sysmon & Wazuh Agent

The Windows 11 VM is the telemetry source. Sysmon generates high-fidelity process, network, and file system events that go beyond standard Windows Event Logs. The Wazuh Agent forwards both Sysmon and native event channels to the Manager for centralized analysis.

Sysmon Installation

Sysmon extends Windows auditing with process creation chains, network connections, DNS queries, and file hash logging — critical telemetry for threat detection.

PowerShell (Admin)
cd C:\Tools\Sysmon
.\Sysmon64.exe -accepteula -i

# Verify Sysmon service is running
Get-Service Sysmon64 | Select Name, Status, StartType

Production Note

In production, Sysmon is deployed with a tuned configuration file (e.g., SwiftOnSecurity/sysmon-config) to filter noise and focus on high-value events. The default config is acceptable for lab validation.

Wazuh Agent Installation

The agent handles secure enrollment with the Manager and continuous log forwarding across the host-only network.

PowerShell (Admin)
# After MSI install, set Manager IP
Manager IP: 192.168.56.102

# Verify agent service + connectivity
Get-Service wazuhsvc | Select Name, Status, StartType
Test-NetConnection 192.168.56.102 -Port 1514
Test-NetConnection 192.168.56.102 -Port 1515

Detection Workflow

End-to-End Validation — Logs to Case

The validation sequence proves that every link in the chain works: the agent is enrolled, Sysmon events are reaching Wazuh, custom events are being ingested, and TheHive can receive alerts via API. This is the difference between "I installed the tools" and "I built a working pipeline."

1Confirm Agent Enrollment

Wazuh VM
sudo /var/ossec/bin/agent_control -lc
# Should list the Windows agent as Active

2Verify Sysmon Event Ingestion

Wazuh VM — archives.json
sudo tail -n 200 /var/ossec/logs/archives/archives.json | \
  grep '"id":"001"' | tail -n 5

3Application Log Injection Test

Create a synthetic event on Windows and confirm it arrives in Wazuh — proving bidirectional telemetry flow.

Windows 11 — Create Test Event
eventcreate /T INFORMATION /ID 1000 /L APPLICATION /SO WazuhLab \
  /D "Wazuh test: Application log ingestion verified"

Wazuh VM — Confirm Receipt
sudo tail -n 400 /var/ossec/logs/archives/archives.json | \
  grep '"channel":"Application"' | grep 'Wazuh test'

4TheHive API Integration

Validate API connectivity and push a test alert from the Wazuh VM to TheHive.

API Health Check
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer <API_KEY>" \
  "http://192.168.56.101:9000/api/status"
# Expected: 200

Create Test Alert
curl -s -X POST "http://192.168.56.101:9000/api/alert" \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "external",
    "source": "wazuh",
    "sourceRef": "SOC-LAB-001",
    "title": "Test Alert — Pipeline Validation",
    "description": "End-to-end validation alert",
    "severity": 2
  }'

5Alert Promotion to Case

In TheHive UI: open the alert → Create Case → Empty Case → confirm. This completes the full detection-to-case lifecycle — the same workflow a SOC analyst executes during real incident triage.

✓ Success Criteria — Pipeline Complete

✓ Sysmon64 and wazuhsvc services running on Windows endpoint

✓ Wazuh Dashboard shows Windows agent as Active

✓ archives.json contains Sysmon events and custom Application test event

✓ TheHive /api/status returns HTTP 200 with valid API key

✓ Test alert visible in TheHive and successfully promoted to a case

Framework Mapping

MITRE ATT&CK — Detection Coverage

This lab's telemetry stack provides visibility into the following MITRE ATT&CK techniques. While the lab environment generates benign events, the same detection pipeline would surface indicators of these techniques in a real environment.

T1059 Execution Command and Scripting Interpreter — Sysmon Event ID 1 (Process Creation) captures process execution chains including PowerShell, cmd.exe, and script interpreters.

T1053 Persistence Scheduled Task/Job — Sysmon monitors process creation that includes schtasks.exe and at.exe invocations.

T1071 C2 Application Layer Protocol — Sysmon Event ID 3 (Network Connection) logs outbound connections with destination IPs, ports, and process context.

T1547 Persistence Boot or Logon Autostart Execution — Sysmon Event ID 13 (Registry Value Set) captures modifications to Run/RunOnce keys.

T1070 Defense Evasion Indicator Removal — Wazuh monitors Windows Security logs for Event ID 1102 (audit log cleared), a key anti-forensic indicator.

T1027 Defense Evasion Obfuscated Files — Sysmon Event ID 7 (Image Loaded) and Event ID 11 (File Created) provide file-level visibility for DLL sideloading and suspicious drops.

Operational Procedures

Daily Runbook & Troubleshooting

Start Order

Start VMs in dependency order to avoid agent enrollment failures and API timeouts:

1 Wazuh (SIEM must be listening before agents connect)

2 TheHive (API must be available for alert forwarding)

3 Windows 11 (agent connects to Manager on boot)

Common Issues & Fixes

Host-only interface DOWN after reboot: Check VirtualBox "Cable Connected" checkbox and run sudo ip link set enp0s8 up && sudo netplan apply.

TheHive container crash: Usually insufficient RAM or vCPU. Increase resources and check docker logs cassandra for root cause.

API permission error: Ensure the API key belongs to a user with manageAlert/create permission in the correct organization.

Tools & Technologies

Technology Stack

Tool	Role	Category
Oracle VirtualBox	Type-2 hypervisor for lab environment	Infrastructure
Windows 11	Endpoint OS — telemetry source	Endpoint
Ubuntu Server 24.04 LTS	Server OS for Wazuh and TheHive VMs	Infrastructure
Sysmon (Sysinternals)	Advanced endpoint telemetry — process, network, file, registry	Telemetry
Wazuh 4.7	SIEM — log ingestion, indexing, dashboard, alerting	Detection
TheHive 5.x	Case management — alert triage, investigation, response tracking	Response
Docker Compose	Container orchestration for TheHive stack	Infrastructure

Reflections

Lessons Learned & Key Takeaways

Network Isolation Is the Foundation

The dual-NIC design was the single most impactful architectural decision. It taught me why production SOC environments use dedicated management networks — a SIEM that loses connectivity to its agents every time someone changes Wi-Fi is not a SIEM at all.

Validation Before Progression

Treating each step as a checkpoint — with explicit pass/fail criteria — eliminated cascading failures. When TheHive API calls failed, I knew networking and Wazuh ingestion were already verified, which immediately narrowed the problem space to API keys and permissions.

Telemetry Quality > Quantity

Sysmon's process creation events provided more investigative value than the entire Windows Security log. Understanding which telemetry sources map to which detection use cases is a prerequisite for effective alert engineering.

Case Management Changes Thinking

Promoting an alert to a case forces structured thinking — what is the hypothesis? What evidence supports it? What is the next investigative step? This is fundamentally different from just reading a SIEM dashboard.

Roadmap

Future Improvements

DETECTION

Write custom Wazuh rules targeting specific Sysmon Event IDs — process injection (Event ID 8), named pipe creation (Event ID 17), and DNS queries (Event ID 22) — to build a focused detection rule library.

AUTOMATION

Integrate Shuffle SOAR between Wazuh and TheHive for automated alert enrichment — pull VirusTotal hash lookups and auto-create TheHive cases from high-severity Wazuh alerts.

ADVERSARY SIM

Deploy Atomic Red Team on the Windows endpoint to execute MITRE ATT&CK techniques and validate detection coverage against known attack patterns.

THREAT INTEL

Add MISP integration for IOC ingestion, enabling correlation of lab-generated events against known threat intelligence feeds.