Home SOC: Threat Detection Lab mit Wazuh + Suricata

Ein selbst gehostetes Security Operations Center-Labor, das darauf ausgelegt ist, echte Angriffstechniken gegen ein absichtlich verwundbares Ziel zu erkennen, mit Wazuh als SIEM und Suricata als netzwerkbasiertem IDS-Sensor. Entwickelt, um Detection-Engineering-Fähigkeiten zu demonstrieren – nicht nur Tool-Bereitstellung.

Überblick

Moderne SOC-Arbeit ist nicht einfach „SIEM installieren und Dashboard beobachten.“ Es geht darum zu verstehen, warum eine Erkennungslücke existiert, und zu wissen, wie man sie schließt. Dieses Labor simuliert eine kleine, realistische Umgebung: eine Angreifer-Box, ein Legacy-/verwundbares Ziel ohne native Protokollierungsunterstützung und einen SIEM-Stack, der um diese Einschränkung herum arbeiten muss – mithilfe von Sichtbarkeit auf Netzwerkebene statt Host-Agenten.

Zentrale Architekturentscheidung: Das Ziel (Metasploitable 2) läuft auf einem Betriebssystem, das zu alt ist, um einen modernen Wazuh-Agenten oder sogar einen Syslog-Forwarder mit Internetzugriff zu unterstützen. Statt dies als Hindernis zu betrachten, setzt das Projekt auf vollständige netzwerkbasierte Erkennung über Suricata – ein realistisches Muster für Legacy-, IoT- oder OT-Assets, die nicht direkt instrumentiert werden können.

Architektur

┌─────────────┐         attacks          ┌──────────────────────┐
│   Kali VM   │ ────────────────────────▶│   Metasploitable 2   │
│ (attacker + │                           │  (unmonitored victim, │
│  Suricata   │                           │   no agent, no       │
│  sensor +   │                           │   internet access)   │
│  Wazuh agent│                           └──────────────────────┘
└──────┬──────┘
       │ eve.json (Suricata alerts/events)
       │ forwarded via Wazuh agent
       ▼
┌─────────────────────┐
│   Wazuh Manager      │
│   (Amazon Linux 2023)│
│   Indexer + Dashboard│
└─────────────────────┘

Alle drei VMs laufen auf VirtualBox und sind als NAT-Netzwerk im 192.168.0.0/24-Bereich verbunden.

Warum Suricata auf der Angreifer-Box läuft

Suricata benötigt Sichtbarkeit auf den Datenverkehr zwischen Angreifer und Ziel. Es gibt zwei Optionen: eine dedizierte Sensor-VM mit einer Promiscuous-/gespiegelten Schnittstelle oder der Betrieb des Sensors auf einem der beiden Hosts, die bereits im Verkehrspfad liegen. Da der Wazuh-Manager (Amazon Linux 2023) keine EPEL-Unterstützung bietet und die Installation von Suricata unpraktikabel machte, und das Ziel keinerlei Agenten ausführen kann, läuft Suricata direkt auf der Kali-Box. Das bedeutet, dass der Sensor 100 % des Angriffsverkehrs auf seiner eigenen Schnittstelle sieht – ohne Promiscuous-Modus oder Span-Port – und seine Ereignisse über den bereits auf Kali registrierten Wazuh-Agenten an den Manager sendet.

Erkennungen

1. Aufklärung – Nmap-Scan-Erkennung

Angriff:

nmap -sV -A 192.168.0.138

Erkennung: Der Emerging-Threats-Regelsatz von Suricata kennzeichnete in Echtzeit mehrere Scan-bezogene und Protokoll-Anomalie-Signaturen, als der Scan jeden offenen Port berührte, einschließlich des Datenverkehrs auf Metasploitables freigelegtem UnrealIRCd-Dienst (ET CHAT IRC USER command).

Ergebnis: 132+ IDS-Ereignisse wurden generiert und innerhalb von Sekunden nach Abschluss des Scans in der Threat-Hunting-Ansicht von Wazuh korrekt unter den Regelgruppen ids, suricata klassifiziert.

2. Ausnutzung – vsftpd 2.3.4 Backdoor (CVE-2011-2523)

Angriff:

msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
msf6 > set RHOSTS 192.168.0.138
msf6 > set LHOST 192.168.0.200
msf6 > run

Das vsftpd 2.3.4 von Metasploitable enthält eine Hintertür, die durch eine fehlerhaft formatierte FTP-Anmeldungszeichenfolge ausgelöst wird und eine Root-Shell auf TCP-Port 6200 erzeugt. Der Exploit landete sauber und lieferte eine Meterpreter-Sitzung als root.

Erkennung: Die Suricata-Signatur GPL ATTACK_RESPONSE id check returned root (SID 2100498) wurde 11 Sekunden nach dem Spawnen der Shell ausgelöst und erkannte den Klartext-String uid=0(root) in der Befehlsausgabe der Shell, als dieser über Port 6200 übertragen wurde.

"signature": "GPL ATTACK_RESPONSE id check returned root",
"signature_id": 2100498,
"src_ip": "192.168.0.138",
"src_port": 6200,
"dest_ip": "192.168.0.200",
"direction": "to_client"

Warum das wichtig ist: Dies ist eine Bestätigung auf Netzwerkebene für eine erfolgreiche Root-Kompromittierung eines Assets ohne jegliche hostbasierte Protokollierung – genau das Szenario, für das die Architektur entwickelt wurde.

3. Credential-Angriff – FTP-Brute-Force (MITRE ATT&CK T1110)

Angriff:

hydra -l msfadmin -P /tmp/quicklist.txt -t 4 ftp://192.168.0.138

Hydra versuchte mehrere FTP-Anmeldungen in schneller Folge und identifizierte nach mehreren fehlgeschlagenen Versuchen korrekt das gültige Anmeldedatenpaar msfadmin:msfadmin.

Erkennungsstatus: Der FTP-Protokollparser von Suricata erfasste jeden einzelnen USER/PASS-Befehl und Server-Antwortcode in eve.json (event_type: ftp), nachweislich vorhanden im rohen Ereignisarchiv des Managers:

{"event_type":"ftp","src_ip":"192.168.0.200","dest_ip":"192.168.0.138",
 "dest_port":21,"ftp":{"command":"PASS","command_data":"root",
 "completion_code":["530"],"reply":["Login incorrect."]}}

Der Standard-Regelsatz von Suricata enthält keine dedizierte Signatur für FTP-Brute-Forcing, da es sich um ein Protokollmuster handelt und nicht um einen bekannten Schad-String. Eine benutzerdefinierte Wazuh-Korrelationsregel wurde entwickelt, um diese Lücke zu schließen:

<group name="suricata,ftp,brute_force,">
  <rule id="100100" level="5">
    <if_sid>86600</if_sid>
    <field name="event_type">^ftp$</field>
    <field name="data.ftp.command">^PASS$</field>
    <description>Suricata: FTP password attempt detected on $(data.dest_ip)</description>
  </rule>

  <rule id="100101" level="10" frequency="4" timeframe="60">
    <if_matched_sid>100100</if_matched_sid>
    <description>Suricata: Possible FTP brute force attack detected - multiple password attempts within 60 seconds</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

Status: in Bearbeitung – die zugrunde liegenden Ereignisdaten erreichen nachweislich den Manager, und die Regelsyntax wurde über wazuh-logtest validiert, aber die Korrelationsregel (100101) feuert noch nicht zuverlässig Ende-zu-Ende. Nächster Debugging-Schritt ist die Bestätigung des Decoder-Feldpfads, der verschachtelten Suricata-FTP-Feldern zur Parse-Zeit zugewiesen wird, über wazuh-logtest gegen eine Live-Stichprobe. Wird unten als zukünftige Arbeit erfasst.

Erkenntnisse

• Legacy-Ziele verändern deine Architektur, nicht nur deine Befehle. Die veraltete Toolchain von Metasploitable 2 schloss einen modernen Wazuh-Agenten und sogar einfaches Syslog-Forwarding aus (kein rsyslog, kein Internetzugriff). Statt einen hostbasierten Ansatz zu erzwingen, wechselte das Projekt zur netzwerkbasierten Erkennung – vermutlich ein realistischeres Muster für reale Legacy-/IoT-Assets.
• Paket-Ökosysteme sind nicht austauschbar. Die Amazon-Linux-2023-Basis des Wazuh-Managers unterstützt kein klassisches EPEL, was eine direkte Suricata-Installation dort blockierte. Die Verlagerung des Sensors auf die Debian-basierte Kali-Box, die bereits im Verkehrspfad lag, umging das Problem vollständig.
• Standard-IDS-Regelsätze sind signaturbasiert, nicht verhaltensbasiert. Suricata erwischte den vsftpd-Exploit sofort, weil eine bekannte Signatur dafür existierte, hatte aber nichts für FTP-Brute-Forcing, weil das ein Muster ist, kein statischer String. Dies ist die eigentliche Rechtfertigung dafür, benutzerdefinierte Korrelationsregeln in einem SIEM zu schreiben, anstatt sich allein auf Out-of-the-Box-IDS-Inhalte zu verlassen.
• archives.log/archives.json sind standardmäßig nicht aktiviert (logall/logall_json stehen standardmäßig auf no) und sind unerlässlich zum Debuggen, was ein SIEM tatsächlich empfangen hat, im Gegensatz zu dem, wofür es sich entschieden hat, Warnungen auszugeben.

Zukünftige Arbeiten

• Debuggen der FTP-Brute-Force-Korrelationsregel (100100/100101) Ende-zu-Ende abschließen
• UnrealIRCd-Backdoor-Ausnutzung (CVE-2010-2075) als vierte Erkennung hinzufügen, da Suricata bereits IRC-Datenverkehr auf dem Ziel kennzeichnet
• Samba-usermap_script-RCE (CVE-2007-2447) als fünfte Technik hinzufügen
• Hochschwere Warnungen an TheHive oder Shuffle anbinden, um automatisch Fälle zu erstellen
• Active-Response hinzufügen, um die Angreifer-IP bei wiederholten Brute-Force-Erkennungen automatisch zu blockieren

Verwendete Tools

• Wazuh 4.14.6 – SIEM (Manager, Indexer, Dashboard)
• Suricata 8.0.5 – Netzwerk-IDS
• Metasploit Framework / Hydra / Nmap – Angriffssimulation
• VirtualBox – Labor-Virtualisierung

MITRE-ATT&CK-Zuordnung