Slack

Einleitung Die Qualität und Aktualität von Vulnerability-Daten ist ein zentraler Erfolgsfaktor für jede SIEM- und Vulnerability-Management-Strategie. In Wazuh übernimmt diese Rolle die Cyber Threat Intelligence (CTI), die CVEs, Schwachstellen-Metadaten und zugehörige Informationen bereitstellt. In der Community taucht regelmäßig die Frage auf, wie aktuell diese Daten tatsächlich sind, wie oft neue CVEs verfügbar werden und warum hier weiterlesen

Einleitung Brute-Force- und Password-Spraying-Angriffe laufen selten „sauber“ auf einem einzigen System. In realen SIEM-Szenarien verteilen sich fehlgeschlagene Anmeldungen über verschiedene Hosts, Dienste und Logquellen – oft mit identischem Quell-IP-Adressraum oder identischem Benutzernamen. Wazuh kann solche Muster grundsätzlich über Frequenz-/Zeitfenster-Regeln korrelieren. In der Praxis scheitern entsprechende Custom Rules jedoch häufig daran, dass die Korrelation nicht auf hier weiterlesen

Ursachenanalyse und saubere Lösung bei Distributed / All-in-One Deployments Einleitung Beim Deployment des Wazuh Dashboards nach offizieller Anleitung kann es zu einer verwirrenden Situation kommen: Dieser Artikel erklärt: 1. Ausgangssituation Setup Beobachtungen 2. Wichtige Hintergrundinfo: Wann wird wazuh.yml erstellt? Die Datei wazuh.yml wird nicht während der Paketinstallation erzeugt. 📌 Sie wird erst automatisch generiert, wenn: hier weiterlesen

Custom Decoder & Rules korrekt umsetzen (inkl. typischer Stolperfallen) Einleitung Viele Organisationen betreiben CMS-basierte Webanwendungen wie Drupal und stehen vor der Herausforderung, End-of-Life-Versionen (EOL) zuverlässig zu erkennen.Wazuh bietet dafür alle notwendigen Bausteine – Logsammlung, Decoder und Regeln – allerdings mit einigen syntaktischen und logischen Feinheiten. Dieser Artikel zeigt anhand eines realen Community-Falls: 1. Ausgangssituation & hier weiterlesen

Einleitung HTTP-Access-Logs sind in Wazuh häufig der Einstiegspunkt für Web- und AppSec-Korrelationen: Brute-Force, Scans, verdächtige User-Agents, Exploit-Versuche und Policy-Verstöße werden oft erst durch sauber extrahierte Felder wirklich auswertbar. In der Praxis scheitert die Erweiterung bestehender Decoder jedoch oft an einem Detail: der Decoder-Pipeline und der Art, wie Wazuh Parent-, Child- und „Sibling“-Decoder auswertet. Dieser Beitrag hier weiterlesen

Einleitung UniFi UDM Pro (inkl. IDS/IPS-Daemon) produziert Syslog-Events, die in Wazuh oft zunächst nur als generische Syslog-Meldungen landen. Ohne passende Decoder fehlen strukturierte Felder wie srcip, dstip, dstport oder protocol – und damit auch die Basis für belastbare Regeln und Threat-Hunting-Queries. In diesem Beitrag geht es darum, UDM-Logs in eine eigene Logdatei (z. B. UDMPrologs.log) hier weiterlesen

Einleitung Die Integration von Threat Intelligence aus MISP in Wazuh ist ein typischer „nächster Schritt“, sobald Detection und Alerting stabil laufen: Indicators aus einem (privaten) TAXII-Feed landen in MISP, und Wazuh soll bei passenden Observables (Hashes, IPs, Domains, URLs) automatisch anreichern und zusätzliche Alerts erzeugen. In produktiven, verteilten Wazuh-Architekturen entsteht dabei schnell ein Skalierungsproblem: Wenn hier weiterlesen

Einleitung Beim Umzug einer Wazuh All-in-One-Installation auf neue Server ist die häufigste und sinnvollste Designentscheidung: Rollen trennen (Indexer/Dashboard getrennt vom Manager) und – sobald Last oder Verfügbarkeit relevant werden – den Wazuh-Manager als Cluster betreiben. Das reduziert Ressourcenkonkurrenz, vereinfacht Skalierung und schafft eine Grundlage für stabile Agent-Konnektivität. Dieser Beitrag ordnet die typischen Fragen aus der hier weiterlesen

Einleitung In produktiven SIEM-Umgebungen mit Wazuh ist ein präzises Alert-Tuning essenziell. Gerade auf Windows-Systemen entstehen regelmäßig Events, die sicherheitsrelevant erscheinen, in der Praxis jedoch legitime Systemprozesse darstellen. Ein typisches Beispiel sind temporäre Dateien mit dem Präfix __PSScriptPolicyTest_, die im Zusammenhang mit PowerShell-Ausführungsrichtlinien erzeugt werden. Wenn diese Dateien durch Windows Event Logs erfasst werden, können mehrere hier weiterlesen

Einleitung Ein klassisches Troubleshooting-Szenario in produktiven Wazuh-Umgebungen: Syslog ist korrekt konfiguriert, Logs erscheinen in archives.json, Decoder- und Rule-Tests funktionieren – aber im Wazuh Dashboard (Discover) sind keine Events sichtbar. In vielen Fällen liegt das Problem nicht an Decodern oder Filebeat-Modulen, sondern am Wazuh Indexer selbst: Der Cluster hat das Maximum an offenen Shards erreicht und hier weiterlesen

Einleitung Bei Wazuh-Integrationen rund um Microsoft 365 (Office 365 Audit Logs) und Microsoft Graph entstehen Probleme oft nicht im „Abrufen“ der Daten, sondern in der Indexierung: Filebeat liefert Events an den Indexer, doch einzelne Felder passen nicht zum erwarteten Mapping. Das Resultat sind mapper_parsing_exception-Fehler, verworfene Dokumente und am Ende „fehlende Alerts“, obwohl der Manager eigentlich hier weiterlesen

Einleitung Wenn Wazuh Dashboard in Modulen wie Threat Hunting, Vulnerabilities und Inventory „No data“ anzeigt, obwohl die zugehörigen wazuh-states-*-Indizes im Indexer nachweislich Dokumente enthalten, liegt das Problem fast nie an der Datenerhebung. In der Praxis sind es typischerweise Kommunikations- und Integrationsprobleme zwischen Dashboard ↔ Indexer (OpenSearch) und Dashboard ↔ Wazuh API – besonders häufig im hier weiterlesen

Einleitung Windows-Security-Logs gehören zu den wichtigsten Datenquellen in Wazuh-basierten SIEM-Umgebungen. Gleichzeitig erzeugen sie häufig ein hohes Grundrauschen, insbesondere durch EventIDs mit geringer sicherheitsrelevanter Aussagekraft im jeweiligen Kontext. Ein typisches Beispiel ist EventID 4673 („A privileged service was called“), die in vielen Umgebungen massenhaft auftritt. Dieser Artikel zeigt, wie solche Events korrekt und nachhaltig bereits auf hier weiterlesen

Einleitung DNS-Telemetrie aus Windows-Endpoints ist für Threat Hunting und Incident Response extrem wertvoll: Sie liefert Domänenabfragen, Antwortcodes und Auflösungsfehler direkt vom Client und ergänzt klassische Netzwerk- oder Proxy-Logs. In Wazuh wird diese Datenquelle häufig über den Windows-Eventchannel Microsoft-Windows-DNS-Client/Operational angebunden. Ein typisches Praxisproblem: Die Events sind zwar auf dem Wazuh-Manager in den Archiven sichtbar, erscheinen aber hier weiterlesen

Einleitung VMware® vSphere erzeugt teils sehr verbose Syslog-Ereignisse – insbesondere bei bestimmten Audit-, API-, Hostd-/Vpxa- oder Security-relevanten Events. In SIEM-Pipelines, die vSphere → Rsyslog → Wazuh führen, tritt dann häufig ein scheinbar „mysteriöses“ Verhalten auf: Wazuh meldet „Too big message size“, kürzt Events, Decoder greifen nicht mehr sauber – und im Dashboard fehlt die erwartete hier weiterlesen

Einleitung Eine hohe Event-Drop-Rate ist eines der kritischsten Symptome in einer Wazuh-Umgebung. Sie bedeutet nicht nur verlorene Logs, sondern potenziell verpasste Sicherheitsereignisse, unvollständige Korrelationen und eingeschränkte Forensik. Gerade in Umgebungen mit vielen Agents, Firewalls oder stark loggenden Anwendungen stößt der Wazuh-Manager schnell an seine Grenzen. Dieser Artikel erklärt, wie Event Drops entstehen, wie man sie hier weiterlesen