SOC Detection & Incident Response Lab

A practical blue-team portfolio project demonstrating an end-to-end SOC analyst workflow across Windows endpoint, Active Directory, Linux, and network telemetry:

telemetry → centralized SIEM → detection → triage → investigation → disposition → tuning → regression validation

Scope: isolated personal training environment. All security activity documented here was generated as authorized controlled simulation. No employer, production, or third-party system was tested.

Technical Report

SOC Detection & Incident Response Lab v3.0 — Technical Report (PDF)

A concise technical report covering the validated architecture, detection and investigation highlights, detection-as-code regression work, analyst automation, engineering principles, and project closure status.

What This Project Demonstrates

• Centralized Windows, Active Directory, Linux, and Suricata telemetry in Splunk Enterprise.
• Detection engineering from observed event semantics rather than assumed field mappings.
• Cross-source investigation across endpoint, identity, host, and network evidence.
• Separation of detection signal from analyst verdict.
• False-positive analysis, bounded lab thresholds, tuning, and documented disposition.
• Detection-as-code with an authoritative Splunk implementation, Sigma portability representation, and rerunnable regression tests.
• Small analyst automation that converts exported SIEM evidence into a chronological incident timeline without automating the security verdict.

Validated Lab Architecture

flowchart TB
    subgraph MGMT["VMnet8 — 192.168.183.0/24 Management / SIEM"]
        W["WIN11-SOC-01<br/>Windows 11<br/>192.168.183.128"]
        DC["DC01<br/>Windows Server 2022<br/>AD DS / DNS<br/>192.168.183.10"]
        S["SPLUNK-SIEM-01<br/>Splunk Enterprise 10.4.1<br/>192.168.183.129"]
        L["LINUX01<br/>Ubuntu 24.04.4<br/>192.168.183.131"]
        N["NET-SENSOR01<br/>Ubuntu 24.04.4<br/>Suricata 8.0.6<br/>192.168.183.132"]
    end

    subgraph MON["VMnet2 — 10.77.0.0/24 Isolated Monitored Network"]
        LM["LINUX01 ens37<br/>10.77.0.10"]
        NM["NET-SENSOR01 ens37<br/>10.77.0.1<br/>Routed IDS path"]
    end

    W -->|"Domain authentication"| DC
    W -->|"Security / PowerShell / Sysmon"| S
    DC -->|"Windows Security"| S
    L -->|"auth.log / syslog"| S
    L --- LM
    N --- NM
    LM -->|"Selected bounded test traffic"| NM
    NM -->|"Suricata EVE"| N
    N -->|"Splunk UF / TCP 9997"| S

    S --> D["Detection / Correlation"]
    D --> I["Analyst Triage & Investigation"]
    I --> R["Disposition / Tuning / Reporting"]

Loading

The monitored network uses a deterministic dual-homed routed IDS design. Selected LINUX01 test traffic is explicitly routed through NET-SENSOR01 so sensor visibility is proven rather than assumed from passive VMware mirroring.

Core Technology

Area	Validated components
SIEM	Splunk Enterprise 10.4.1, soc_lab, SPL
Endpoint	Windows 11, Windows Security, PowerShell Operational, Sysmon
Identity	Windows Server 2022, Active Directory DS, DNS, Kerberos
Linux	Ubuntu Server 24.04.4, OpenSSH, auth.log, syslog
Network	Suricata 8.0.6, EVE JSON, AF_PACKET, routed sensor path
Collection	Splunk Universal Forwarder 10.4.1
Detection-as-Code	Sigma CLI 3.1.0, pySigma Splunk backend, Python regression harness
Automation	Python Splunk CSV → Markdown investigation-timeline utility
Platform	VMware Workstation

Selected Validated Detection / Investigation Chains

Windows Endpoint

• DET-001 — Multiple Failed Logons
• DET-002 — Encoded PowerShell Execution
• DET-003 — PowerShell Spawned Command Shell

These foundational cases correlate Windows Security, PowerShell, and Sysmon telemetry and are preserved with public case-study documentation.

Identity / Active Directory

• DET-004 — Kerberos Pre-Authentication Failure Cluster

  • Three controlled Event ID 4771 failures.
  • Account, client address, failure code, and timing validated in Splunk.
  • Lab threshold is explicitly not presented as a production password-spray threshold.

• DET-006 — Monitored AD Security Group Membership Change

  • Event IDs 4729 and 4728 for a reversible remove-and-restore cycle.
  • Block-aware _raw parsing separates actor, changed member, target group, and action.
  • The monitored lab group is not presented as inherently privileged.

Linux

• DET-007 — Repeated SSH Password Failures Against an Invalid User
  • Exactly three controlled failed-password events against a nonexistent test identity.
  • Groups by host, target user, and source IP in a fixed five-minute Splunk bucket.
  • Surrounding auth.log context was reviewed before benign controlled disposition.

Authoritative executable SPL:

detections/splunk/det007_linux_ssh_invalid_user_burst.spl

Sigma portability representation:

detections/sigma/det007_linux_ssh_invalid_user_burst.yml

Host / Network Correlation

• DET-008 — Cross-Source Host/Network Routed-Flow Correlation
  • Correlated an authorized LINUX01 route change with a Suricata SID 1000001 network alert and immediate route cleanup.
  • Final validated order: route replace → Suricata alert → route delete.
  • Demonstrates correlation between administrative host intent and sensor-observed network behavior.

Detection-as-Code and Regression

DET-007 is preserved as an exact Splunk implementation before portability work.

A deterministic Python regression harness validates five cases:

1. Three matching failures in one fixed five-minute bucket trigger.
2. Two failures do not trigger.
3. Events split across adjacent fixed buckets do not trigger.
4. Different usernames are not incorrectly combined.
5. Unrelated auth.log records are ignored.

python3 scripts/test_det007.py

Validated result:

DET-007 regression: 5/5 PASS

Sigma Equivalence Finding

The Sigma event_count representation preserves the broad:

event selection → 5-minute bin → grouping → count >= 3

structure. However, the generated Splunk query does not reproduce the validated _raw rex extraction that creates Target_User, Source_IP, and Source_Port.

Therefore:

The handcrafted Splunk SPL remains the authoritative executable implementation. Sigma is retained as a maintainable interoperability representation, not claimed as a drop-in equivalent.

This distinction is intentional: portability must not silently change detection semantics.

Analyst Automation

scripts/splunk_export_to_timeline.py converts an exported Splunk CSV into a chronological Markdown investigation timeline.

python3 scripts/splunk_export_to_timeline.py \
  tests/analyst_cases/inc007_export.csv \
  -o generated/inc007_investigation_timeline.md \
  --title "INC-007 Investigation Timeline"

Regression validation:

python3 scripts/test_splunk_timeline.py

Validated result:

Splunk timeline utility regression: 5/5 PASS

The utility deliberately does not determine maliciousness, severity, confidence, escalation, or disposition. It structures evidence for reporting and handover while keeping security judgment with the analyst.

Example output:

generated/inc007_investigation_timeline.md

Foundational Public Incident Reports

Incident	Trigger	Final disposition
INC-001	DET-001	Benign / Controlled Simulation
INC-002	DET-002	Benign / Controlled Simulation
INC-003	DET-003	Benign / Controlled Simulation

These reports preserve the original Windows-focused project baseline. Version 3.0 expands the same lab rather than replacing that validated evidence.

Repository Structure

soc-home-lab/
├── README.md
├── detections/
│   ├── DET-001-multiple-failed-logons.md
│   ├── DET-002-encoded-powershell.md
│   ├── DET-003-powershell-spawned-command-shell.md
│   ├── sigma/
│   │   └── det007_linux_ssh_invalid_user_burst.yml
│   └── splunk/
│       └── det007_linux_ssh_invalid_user_burst.spl
├── incidents/
│   ├── INC-001-multiple-failed-logons.md
│   ├── INC-002-suspicious-powershell.md
│   └── INC-003-suspicious-process-execution.md
├── scripts/
│   ├── splunk_export_to_timeline.py
│   ├── test_det007.py
│   └── test_splunk_timeline.py
├── tests/
│   ├── analyst_cases/
│   │   └── inc007_export.csv
│   └── detection_cases/
│       └── det007_cases.json
├── generated/
│   ├── det007_sigma_splunk.spl
│   └── inc007_investigation_timeline.md
└── docs/
    ├── architecture.md
    └── lab-environment.md

Engineering Principles

• Evidence before claims.
• Detection signals are investigation triggers, not verdicts.
• Source generation, collection, searchability, field interpretation, and analyst use are validated separately.
• Raw field behavior is inspected before detection logic assumes normalized fields.
• Cross-source correlation is preferred where it materially improves confidence.
• Lab thresholds are not presented as production recommendations.
• Failed experiments and engineering trade-offs are documented instead of hidden.
• Automation structures analyst work but does not replace analyst judgment.
• Detection changes should be regression-tested for semantic drift.

Project Status

Core SOC Detection & Incident Response Lab v3.0: COMPLETE / VALIDATED.

Validated capability areas:

• Windows endpoint telemetry
• Active Directory / identity telemetry
• Linux authentication and system telemetry
• Suricata network visibility
• Cross-source investigation
• Detection-as-code and regression validation
• Analyst workflow automation

Cloud-security expansion is intentionally optional and outside the core v3.0 definition of done.