Wazuh POCs

Wazuh Proof-of-Concept – Sammlung

Diese Seite bündelt sechs native Wazuh-POCs für das Lab. Jeder POC folgt demselben Bogen: Config → Angriff → Alert → Dashboard. Der Suricata-NIDS-POC ist separat dokumentiert. Angreifer ist durchgehend die Kali.

Wichtig: Vor jedem POC einen VM-Snapshot ziehen — so starten alle Tests aus einem sauberen Zustand und stören sich nicht gegenseitig.

POC	Ziel-Host (Agent)	Angreifer
FIM	ubuntu	— (lokale Änderung)
Vulnerability Detection	ubuntu	— (altes Paket)
Brute-Force SSH	ubuntu	Kali (hydra)
Active Response	ubuntu	Kali
SQL Injection	VulnSite	Kali (curl)
Windows (3 Varianten)	win11	je nach Variante

POC 1: File Integrity Monitoring

Wazuh überwacht ein Verzeichnis und meldet Anlegen, Ändern und Löschen von Dateien.

Agent konfigurieren (ubuntu)

In /var/ossec/etc/ossec.conf den syscheck-Block ergänzen

<syscheck>
  <directories check_all="yes" report_changes="yes" realtime="yes">/root</directories>
</syscheck>

Agent neu starten

• systemctl restart wazuh-agent

Angriff auslösen

Datei anlegen und ändern

echo "test" > /root/fim-test.txt
echo "geaendert" >> /root/fim-test.txt
rm /root/fim-test.txt

Kontrolle

• Dashboard → Threat Hunting, Filter rule.id:(550 OR 554)
• 554 = Datei angelegt, 550 = Datei geändert. report_changes zeigt zusätzlich das Diff.

POC 2: Vulnerability Detection

Der Agent inventarisiert installierte Pakete (Syscollector), der Manager gleicht gegen den CVE-Feed ab.

Scan-Intervall verkürzen (ubuntu)

Standard ist 1h — für den Kurs auf 10m runter, sonst zu lange Wartezeit.

In /var/ossec/etc/ossec.conf den wodle-Block anpassen

<wodle name="syscollector">
  <interval>10m</interval>
  <packages>yes</packages>
</wodle>

Agent neu starten

• systemctl restart wazuh-agent

Schwachstelle einbauen

Bewusst veraltetes Paket installieren (Beispiel)

• apt install -y --allow-downgrades <altes-paket>=<verwundbare-version>
• Nach ca. 10 Minuten läuft ein neuer Scan

Kontrolle

• Dashboard → Vulnerability Detection → Inventory — die CVEs des Hosts erscheinen

Schwachstelle wieder schließen (zeigt das Auflösen)

• apt remove -y <altes-paket>
• Nach dem nächsten Scan verschwindet der Eintrag

POC 3: Brute-Force SSH

Wazuh korreliert mehrere fehlgeschlagene Logins zu einem Brute-Force-Alert (Rules out-of-the-box).

Voraussetzung

• SSH auf der ubuntu aktiv, Agent läuft

Angriff von Kali

Passwortliste anlegen und hydra laufen lassen

for i in $(seq 1 10); do echo "falsch$i"; done > bad-passwords.txt
hydra -l kit -P bad-passwords.txt ssh://<ubuntu-ip>

Kontrolle

• Dashboard → Threat Hunting, Filter rule.id:(5551 OR 5712)
• 5551 = mehrere Auth-Fehler, 5712 = SSHD Brute-Force erkannt

POC 4: Active Response – Angreifer blocken

Baut direkt auf POC 3 auf: nach erkanntem Brute-Force blockt der Manager die Quell-IP per firewall-drop.

Manager konfigurieren

In /var/ossec/etc/ossec.conf auf dem Wazuh-Manager (nicht dem Agent)

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712</rules_id>
  <timeout>60</timeout>
</active-response>

Manager neu starten

• systemctl restart wazuh-manager

Angriff wiederholen

• hydra-Angriff aus POC 3 erneut von Kali starten

Kontrolle

• Dashboard → Threat Hunting, Filter rule.groups:active_response
• Auf der ubuntu: die Kali-IP ist für 60s in iptables geblockt (iptables -L)

POC 5: SQL Injection

Wazuh erkennt SQLi durch Analyse des Apache-Access-Logs. Das ist die Brücke zur späteren WAF-Anbindung: hier sieht Wazuh den Angriff am Webserver, später blockt Coraza ihn davor.

Agent konfigurieren (VulnSite)

In /var/ossec/etc/ossec.conf das Apache-Log einbinden

<localfile>
  <log_format>apache</log_format>
  <location>/var/log/apache2/access.log</location>
</localfile>

Agent neu starten

• systemctl restart wazuh-agent

Angriff von Kali

SQLi-Pattern per curl absetzen

curl -XGET "http://<vulnsite-ip>/users/?id=SELECT+*+FROM+users"

Kontrolle

• Dashboard → Threat Hunting, Filter rule.id:31103
• 31103 = SQLi-Versuch, 31106 = erfolgreiche SQLi (liefert Daten zurück)

POC 6: Windows (drei Varianten)

Agent auf win11. Such dir eine Variante aus — alle drei sind ohne Custom-Rules lauffähig.

6a: FIM Windows-Registry (Persistence)

Überwacht den Autostart-Run-Key — klassische Malware-Persistence.

In der Agent-ossec.conf (Windows

C:\Program Files (x86)\ossec-agent\ossec.conf)

<syscheck>
  <windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
</syscheck>

Agent-Dienst neu starten (PowerShell als Admin)

• Restart-Service WazuhSvc

Angriff

Run-Key setzen

• reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v evil /t REG_SZ /d "C:\temp\evil.exe"
• Kontrolle: Dashboard → Threat Hunting, Filter rule.groups:syscheck_entry_modified

6b: Brute-Force RDP

Wazuh korreliert Windows-Logon-Fehler (Event-ID 4625) zum Brute-Force-Alert.

Angriff von Kali

hydra -l administrator -P bad-passwords.txt rdp://<win11-ip>

Kontrolle

• Dashboard → Threat Hunting, Filter rule.groups:authentication_failures
• Die korrelierte Windows-Brute-Force-Rule feuert nach mehreren 4625-Events

6c: VirusTotal + Active Response (EICAR)

FIM erkennt eine neue Datei, VirusTotal prüft den Hash, Active Response löscht sie automatisch.

Voraussetzung: Manager braucht Internet und einen VirusTotal-API-Key

In der Manager-ossec.conf

<integration>
  <name>virustotal</name>
  <api_key>DEIN_VT_API_KEY</api_key>
  <rule_id>550,554</rule_id>
</integration>

FIM auf einen Download-Ordner der win11 setzen (siehe 6a, anderer Pfad)

Angriff

EICAR-Testdatei ablegen

'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' | Out-File C:\downloads\eicar.com

Kontrolle

• Dashboard → Threat Hunting, Filter rule.groups:virustotal
• VirusTotal flaggt die Datei, Active Response entfernt sie