Project 06 — Dockerized SOC Simulation Lab

Overview

One of the best SOC/Engineering exercises I've done: a 3-day weekend project. I built a Dockerized SOC simulation lab with four distinct components, all spun up with a single command: docker compose up.

After that, the focus shifts entirely to analysis in Splunk — queries, detections, and event correlation. Because each simulation generates unique telemetry with new IPs, hostnames, usernames, and randomized behavior, no two runs are the same.

Project Demo

Video — SOC Simulation Lab full walkthrough demo

Fig 1 — SOC Simulation Lab — full architecture overview

Lab Architecture — 4 Components

The lab is composed of four isolated containers, each on a dedicated subnet, mimicking a realistic segmented corporate network:

Splunk Server — Network: 192.168.1.0/24
Orchestrator — Networks: 192.168.1.0/24, 192.168.10.0/24, 192.168.100.0/24
Corporate Workstation — Network: 192.168.10.0/24
Actor System — Network: 192.168.100.0/24

Fig 2 — Network segmentation across the four lab containers

Engine Lifecycle

Splunk Server

Configured via a customized deployment server. Universal Forwarders dynamically connect and pull centralized configuration patterns automatically upon container spin-up — no manual configuration required after initial setup.

Orchestrator

The brain of the engine. It manages three distinct subnets, handles dynamic IP allocations, and injects randomized hostnames and usernames for both the Corporate Workstation and the Actor System. It powers a dashboard displaying:

Active and historical session pairings
Actor-to-target mappings
Live round timers

Fig 3 — Orchestrator dashboard showing active session pairings and live round timers

Corporate Workstation

Tracks real-time telemetry. Features a preinstalled Universal Forwarder capturing:

SSH auth logs — successful and failed authentication events
iptables firewall events — inbound connection attempts and port scans

Actor System

Randomly selects one of two behavior profiles at startup, making each simulation round unique and unpredictable:

✅ Normal Behavior (50%): Simulates a user mistake by testing one random port, then performs a successful SSH login using valid credentials generated by the Orchestrator.
⚠️ Threat Behavior (50%): Runs an Nmap scan against the Corporate Workstation (100 random ports), then performs 10 SSH attempts with random credentials to simulate brute-force activity.

Fig 4 — Actor System behavior profiles — normal vs. threat simulation

Splunk Analysis

With the lab generating unique telemetry on every run, the analysis phase in Splunk focuses on:

Writing SPL queries to detect brute-force SSH attempts
Correlating iptables firewall events with authentication logs
Identifying Nmap port scan signatures in network telemetry
Building detections that hold up across different IPs, hostnames, and usernames

Fig 5 — Splunk SIEM — event correlation and detection queries

Ethical Disclaimer

This project was built and executed entirely within an isolated, local virtual home lab environment strictly for educational and defensive detection engineering purposes. All simulated attack activity was confined to containers with no external network connectivity.