HTSOC — Integrated SOC System for Event Monitoring, Detection, and Investigation

HTSOC is a self-built Security Operations Center system in a lab environment. The system combines log collection, detection with Splunk, alert/case management with TheHive, Observable analysis with Cortex, IOC lookup with MISP or VirusTotal, and orchestrates notifications via n8n and Telegram.

CVE-2024-4577 is just a use case used to validate multi-layer detection capability; the entire project is not limited to a single CVE.

Table of Contents

• Objectives
• Overall Architecture
• Components
• Processing Flow
• Detection Capabilities
• Repository Structure
• Deployment
• Testing and Evaluation
• Live System Inventory
• Operations Runbook
• Testing Checklist

Objectives

The system simulates a complete SOC workflow:

1. Collect telemetry from Linux, Windows, Apache, and Sysmon.
2. Normalize logs into Splunk by index/sourcetype.
3. Detect suspicious behavior using SPL, correlation searches, allowlists, and risk scoring.
4. Generate alerts with Observables for analysts to continue investigating.
5. Manage alerts/cases in TheHive.
6. Allow analysts to select each Observable to run the appropriate analyzer in Cortex.
7. Look up internal IOCs via MISP or external sources via VirusTotal.
8. Send alerts and analysis results to Telegram.
9. Measure MTTD, MTTN, MTTR, false positive, and duplicate rate.

Overall Architecture

flowchart LR
    K[Kali or test source] --> W[Windows/XAMPP + Apache/PHP-CGI]
    L[Linux endpoint] --> F[Universal Forwarder]
    W --> A[Apache access/error log]
    W --> S[Windows Security + Sysmon]
    A --> F
    S --> F
    F --> SP[Splunk]
    L --> F
    SP -->|Alert webhook| TH[TheHive]
    TH -->|Alert + Observable| N[n8n]
    N --> T[Telegram]
    N -->|Analyzer selected by analyst| C[Cortex]
    C --> M[MISP]
    C --> V[VirusTotal]
    M --> N
    V --> N
    N --> T

Reference Lab Topology

The addresses above are for lab use only. When redeploying, replace them with environment variables and do not expose services to the Internet.

Components

Data Collection Layer

• Apache logs source IP, HTTP method, URI, status, and User-Agent.
• Windows Security logs logins, process creation, services, and privilege changes.
• Sysmon adds process chains, command lines, ProcessGuid, file, registry, and network evidence.
• Linux auth/syslog logs authentication activity and Linux system events.
• Universal Forwarder forwards logs to Splunk according to defined inputs/sourcetypes.

Splunk Detection Layer

Splunk is the detection hub of the system. The searches cover brute force login, suspicious NTLM network logon, high-privilege group changes, lateral movement via SMB, new Windows service creation, encoded PowerShell, and PHP-CGI argument injection.

Investigation Management Layer

TheHive receives alerts from Splunk, displays severity/source/title, stores Observables, and allows analysts to convert alerts into cases. Cortex receives Observables from TheHive to run analyzers. MISP and VirusTotal are two parallel analysis options, not required to run sequentially.

Orchestration Layer

n8n receives webhooks from TheHive and sends the initial SOC alert to Telegram. When an analyst clicks an Observable, n8n then processes the callback, determines the analyzer, creates a Cortex job, waits for the report, and sends the result to Telegram. The update_id, callback_query_id, suppression, and job ID mechanisms help avoid duplicate runs.

Processing Flow

Alert Flow

Log generated
  → Universal Forwarder
  → Splunk search/correlation
  → TheHive alert
  → n8n webhook
  → Telegram SOC Alert

Observable Analysis Flow

Analyst clicks Observable on Telegram
  → Telegram callback
  → n8n replies to callback immediately
  → retrieves Observable from TheHive
  → checks Observable type and analyzer
  → Cortex creates job
  → n8n waits and retrieves report
  → Telegram sends result

n8n does not automatically run all Observables as soon as an alert arrives. Analyzers are only run when selected by the analyst, thereby reducing cost, reducing duplicate notifications, and maintaining control over the investigation.

Detection Capabilities

Baseline Detections

Baseline detections are located in config/splunk/core-savedsearches.conf, with exclusion lookups for legitimate activity:

CVE-2024-4577 Use Case

This use case has two layers:

• Phase 1 analyzes Apache URIs, performs multi-layer decoding, and looks for combinations of PHP endpoints, abnormal encoding, the -d option, sensitive PHP INI names, or php://input. This is a suspicious signal.
• Phase 2 correlates with Windows Security/Sysmon within a limited time window. Suspicious child processes created by php-cgi.exe are strong evidence; file/registry/network are supporting evidence.

Sigma-format rule metadata is located at detections/sigma/cve-2024-4577-php-cgi-argument-injection.yml. The search executed in Splunk is located at config/splunk/install-cve-detections.ps1.

Repository Structure

config/
├── forwarder/       Windows and Linux input/output configuration
├── misp/             simulated IOCs for internal lookup
├── n8n/              TheHive–Telegram–Cortex workflow templates
├── splunk/           saved searches, lookups, and correlation scripts
└── sysmon/           Windows telemetry configuration
deploy/              Docker Compose template with secrets removed
detections/
└── sigma/            vendor-independent rule metadata
scripts/
├── splunk/           update searches via API
├── validation/       readiness checks
└── windows/          install telemetry on lab target machine
docs/                 operations documentation and Telegram callback

The mapping between source and live system is in the system inventory. The real n8n workflow manifest with secrets removed is at config/n8n/live-workflow-manifest.json; the small import template file is kept separately for safely building a new lab.

Deployment

Docker Stack

cp deploy/docker-compose.soc.example.yml deploy/docker-compose.yml
cp .env.example .env
# Fill in secrets using a secret manager or a local .env file.
docker compose -f deploy/docker-compose.yml config
docker compose -f deploy/docker-compose.yml up -d
docker compose -f deploy/docker-compose.yml ps

The Compose template deploys TheHive, Cortex, MISP, Cassandra, Elasticsearch, MinIO, Redis, and MISP modules. n8n is currently operated as a host service with workflow configuration at config/n8n/.

Windows and Splunk

# PowerShell Administrator on Windows lab
.\scripts\windows\install-lab-telemetry.ps1

# On the Splunk machine, do not write passwords into source code
$env:SPLUNK_PASSWORD = '<local-secret>'
.\config\splunk\install-cve-detections.ps1
python .\scripts\splunk\update-correlation-searches.py

# Check readiness
.\scripts\validation\check-system-readiness.ps1

n8n, TheHive, Cortex, and MISP

1. Import the workflow template into n8n.
2. Create dedicated credentials for TheHive, Cortex, and Telegram.
3. Configure the TheHive webhook to point to n8n.
4. Verify Cortex has the corresponding MISP/VirusTotal analyzers.
5. Import sample IOCs into the internal MISP event if needed.

Callback details are in docs/telegram-callback-setup.md.

Testing and Evaluation

Testing is performed bottom-up:

1. Apache/Sysmon generate logs.
2. Forwarder forwards logs to Splunk.
3. Splunk returns detection results with the correct index/sourcetype.
4. TheHive receives the alert and Observables.
5. n8n receives the webhook once.
6. Telegram receives the SOC alert.
7. Callback creates exactly one Cortex job.
8. Telegram receives the MISP or VirusTotal report.

Metrics used in the lab: MTTD from event to Splunk detection, MTTN from alert to Telegram notification, MTTR from alert receipt to triage/case closure, False Positive Rate, and Duplicate rate.