Thomas.will: Die Seite wurde neu angelegt: „=Wazuh Proof-of-Concept – Sammlung= Diese Seite bündelt sechs native Wazuh-POCs für das Lab. Jeder POC folgt demselben Bogen: '''Config → Angriff → Ale…“

2026-06-26T14:06:13Z

Die Seite wurde neu angelegt: „=Wazuh Proof-of-Concept – Sammlung= Diese Seite bündelt sechs native Wazuh-POCs für das Lab. Jeder POC folgt demselben Bogen: '''Config → Angriff → Ale…“

Neue Seite

=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.

{| class="wikitable"
! 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
<pre>
<syscheck>
<directories check_all="yes" report_changes="yes" realtime="yes">/root</directories>
</syscheck>
</pre>
;Agent neu starten
* systemctl restart wazuh-agent

====Angriff auslösen====
;Datei anlegen und ändern
<syntaxhighlight lang="bash">
echo "test" > /root/fim-test.txt
echo "geaendert" >> /root/fim-test.txt
rm /root/fim-test.txt
</syntaxhighlight>

====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
<pre>
<wodle name="syscollector">
<interval>10m</interval>
<packages>yes</packages>
</wodle>
</pre>
;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
<syntaxhighlight lang="bash">
for i in $(seq 1 10); do echo "falsch$i"; done > bad-passwords.txt
hydra -l kit -P bad-passwords.txt ssh://<ubuntu-ip>
</syntaxhighlight>

====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)
<pre>
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>5712</rules_id>
<timeout>60</timeout>
</active-response>
</pre>
;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
<pre>
<localfile>
<log_format>apache</log_format>
<location>/var/log/apache2/access.log</location>
</localfile>
</pre>
;Agent neu starten
* systemctl restart wazuh-agent

====Angriff von Kali====
;SQLi-Pattern per curl absetzen
<syntaxhighlight lang="bash">
curl -XGET "http://<vulnsite-ip>/users/?id=SELECT+*+FROM+users"
</syntaxhighlight>

====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'')
<pre>
<syscheck>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
</syscheck>
</pre>
;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
<syntaxhighlight lang="bash">
hydra -l administrator -P bad-passwords.txt rdp://<win11-ip>
</syntaxhighlight>
;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''
<pre>
<integration>
<name>virustotal</name>
<api_key>DEIN_VT_API_KEY</api_key>
<rule_id>550,554</rule_id>
</integration>
</pre>
;FIM auf einen Download-Ordner der win11 setzen (siehe 6a, anderer Pfad)
;Angriff: EICAR-Testdatei ablegen
<syntaxhighlight lang="powershell">
'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' | Out-File C:\downloads\eicar.com
</syntaxhighlight>
;Kontrolle
* Dashboard → ''Threat Hunting'', Filter ''rule.groups:virustotal''
* VirusTotal flaggt die Datei, Active Response entfernt sie

[[Kategorie:WAZUH]]

Wazuh POCs - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „=Wazuh Proof-of-Concept – Sammlung= Diese Seite bündelt sechs native Wazuh-POCs für das Lab. Jeder POC folgt demselben Bogen: '''Config → Angriff → Ale…“