Reproduzierbares SOC-Lab für die Erkennung und Reaktion auf CVE-2024-4577
HTSOC ist ein selbst aufgebautes Security Operations Center in einer Laborumgebung. Das System kombiniert Log-Erfassung, Erkennung mit Splunk, Alert-/Case-Verwaltung mit TheHive, Observable-Analyse mit Cortex, IOC-Abfrage mit MISP oder VirusTotal und orchestriert Benachrichtigungen über n8n und Telegram.
CVE-2024-4577 ist nur ein Use Case zur Validierung der mehrschichtigen Erkennungsfähigkeit; das gesamte Projekt ist nicht auf eine einzelne CVE beschränkt.
Das System simuliert einen vollständigen SOC-Prozess:
flowchart LR
K[Kali oder Testquelle] --> 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 -->|Vom Analysten gewählter Analyzer| C[Cortex]
C --> M[MISP]
C --> V[VirusTotal]
M --> N
V --> N
N --> T| Komponente | Rolle | Referenzadresse |
|---|---|---|
| Kali | autorisierte Test-Traffic-Quelle | 192.168.10.132 |
| Windows/XAMPP | Zielmaschine Apache/PHP-CGI und Sysmon | 192.168.10.130:8080 |
| Splunk | Erfassung, Suche, Korrelation und Alerting | 192.168.10.128 |
| TheHive | Verwaltung von Alerts, Cases und Observables | 192.168.10.133:9000 |
| Cortex | Ausführung von Analyzern | 192.168.10.133:9001 |
| MISP | interner IOC-Speicher | 192.168.10.133:443 |
| n8n | Webhook-/Callback-Automatisierung | 192.168.10.133:5678 |
Die obigen Adressen gelten nur für das Labor. Bei einer erneuten Bereitstellung durch Umgebungsvariablen ersetzen und Dienste nicht im Internet exponieren.
Splunk ist das Detection-Zentrum des Systems. Die Suchen decken Brute-Force-Logins, verdächtige NTLM-Netzwerk-Logons, Änderungen an privilegierten Gruppen, Lateral Movement über SMB, Erstellung neuer Windows-Dienste, verschlüsseltes PowerShell und PHP-CGI-Argument-Injection ab.
TheHive empfängt Alerts von Splunk, zeigt Severity/Quelle/Titel an, speichert Observables und ermöglicht Analysten, Alerts in Cases umzuwandeln. Cortex empfängt Observables von TheHive, um Analyzer auszuführen. MISP und VirusTotal sind zwei parallele Analyseoptionen, die nicht zwingend sequenziell ausgeführt werden.
n8n empfängt Webhooks von TheHive und sendet den initialen SOC-Alert an Telegram. Erst wenn ein Analyst ein Observable anklickt, verarbeitet n8n den Callback, bestimmt den Analyzer, erstellt einen Cortex-Job, wartet auf den Report und sendet das Ergebnis an Telegram. Die Mechanismen update_id, callback_query_id, Suppression und Job-ID verhindern doppelte Ausführungen.
Log entsteht
→ Universal Forwarder
→ Splunk-Suche/Korrelation
→ TheHive-Alert
→ n8n-Webhook
→ Telegram SOC Alert
Analyst klickt Observable in Telegram
→ Telegram-Callback
→ n8n antwortet sofort auf Callback
→ Observable von TheHive abrufen
→ Observable-Typ und Analyzer prüfen
→ Cortex erstellt Job
→ n8n wartet und ruft Report ab
→ Telegram sendet Ergebnis
n8n führt nicht automatisch alle Observables sofort beim Eintreffen des Alerts aus. Analyzer werden nur ausgeführt, wenn der Analyst sie auswählt. Dadurch werden Kosten gesenkt, doppelte Benachrichtigungen reduziert und die Kontrolle über die Untersuchung behalten.
Die Basis-Detections befinden sich in config/splunk/core-savedsearches.conf, einschließlich Lookups zum Ausschluss legitimer Aktivitäten:
| Detection | Hauptdaten | Ziel |
|---|---|---|
| Brute Force Login | Windows Event ID 4625 | mehrere fehlgeschlagene Anmeldungen innerhalb eines Zeitfensters |
| Suspicious NTLM Logon | Windows Event ID 4624 | ungewöhnlicher Network Logon Type 3 mit NTLM |
| Privileged Group Change | Event ID 4732/4728/4756 | Hinzufügen von Konten zu privilegierten Gruppen |
| Lateral Movement SMB | Event ID 4624 | eine Quelle greift ungewöhnlich auf viele Hosts zu |
| New Windows Service | Event ID 7045 | Erstellung neuer Dienste außerhalb der Allowlist |
| Encoded PowerShell | Event ID 4688 | PowerShell mit -enc oder -EncodedCommand |
Dieser Use Case hat zwei Ebenen:
Sigma-förmige Regel-Metadaten befinden sich unter detections/sigma/cve-2024-4577-php-cgi-argument-injection.yml. Die in Splunk ausgeführte Suche befindet sich unter config/splunk/install-cve-detections.ps1.
config/
├── forwarder/ Windows- und Linux-Input/Output-Konfiguration
├── misp/ simulierte IOCs für interne Abfragen
├── n8n/ Workflow-Vorlagen TheHive–Telegram–Cortex
├── splunk/ Saved Searches, Lookups und Korrelationsskripte
└── sysmon/ Windows-Telemetriekonfiguration
deploy/ Docker-Compose-Vorlage ohne Secrets
detections/
└── sigma/ vendorunabhängige Regel-Metadaten
scripts/
├── splunk/ Suchaktualisierung über API
├── validation/ Readiness-Prüfungen
└── windows/ Telemetrieinstallation für Lab-Zielmaschinen
docs/ Betriebsdokumentation und Telegram-Callback
Der Abgleich zwischen Quelle und Live-System befindet sich im Systeminventar. Das echte, von Secrets bereinigte n8n-Workflow-Manifest liegt unter config/n8n/live-workflow-manifest.json; die kleine Import-Vorlagendatei wird separat aufbewahrt, um ein neues Labor sicher aufzubauen.
cp deploy/docker-compose.soc.example.yml deploy/docker-compose.yml
cp .env.example .env
# Secrets mit Secret Manager oder lokaler .env-Datei ausfüllen.
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
Die Compose-Vorlage stellt TheHive, Cortex, MISP, Cassandra, Elasticsearch, MinIO, Redis und MISP-Module bereit. n8n wird derzeit als Host-Dienst betrieben, die Workflow-Konfiguration liegt unter config/n8n/.
# PowerShell als Administrator auf Windows-Lab
.\scripts\windows\install-lab-telemetry.ps1
# Auf der Splunk-Maschine, kein Passwort in Quellcode schreiben
$env:SPLUNK_PASSWORD = '<lokales-geheimnis>'
.\config\splunk\install-cve-detections.ps1
python .\scripts\splunk\update-correlation-searches.py
# Readiness prüfen
.\scripts\validation\check-system-readiness.ps1
Details zum Callback finden sich in docs/telegram-callback-setup.md.
Tests erfolgen in Bottom-up-Reihenfolge:
Im Labor verwendete Kennzahlen: MTTD vom Ereignis bis zur Splunk-Erkennung, MTTN vom Alert bis zur Telegram-Benachrichtigung, MTTR vom Alert-Eingang bis zum Triage/Case-Abschluss, False Positive Rate und Duplicate Rate.