Windows EventID 4673 gezielt unterdrücken: Saubere Eventchannel-Filterung in Wazuh

von

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 Agent-Seite gefiltert werden – ohne lokale Ignore-Rules und ohne unnötige Last auf Manager und Indexer.

Ausgangslage / Problemstellung

In einer Windows-Umgebung erzeugt der Wazuh-Agent eine große Anzahl an Alerts mit den EventIDs 4673, 4674, 4957 und 5719 aus dem Security-Eventlog. Ziel ist es, diese Events gar nicht erst zu sammeln, sondern bereits bei der Eventchannel-Abfrage auszuschließen.

Der erste Ansatz besteht darin, die bestehende localfile-Konfiguration in der Shared Configuration (agent.conf) um eine XPath-Query zu erweitern, die bestimmte EventIDs ausschließt. Trotz scheinbar korrekter Syntax greift der Filter jedoch nicht – die Events werden weiterhin gesammelt und verarbeitet.

Technische Analyse

Der Kern des Problems liegt in der XPath-Syntax, die Wazuh für eventchannel-Logs verwendet. Die Query wird direkt an die Windows Event Log API übergeben und muss daher streng dem XPath-Standard entsprechen.

Ein häufiger Fehler ist die Nutzung von Konstrukten wie:

not(EventID=4673)

Innerhalb des Event/System-Scopes ist dies syntaktisch zwar naheliegend, wird aber von der Event Log API nicht korrekt interpretiert. Stattdessen erwartet Windows explizite Vergleichsoperatoren (!=) pro EventID.

Zusätzlich ist zu beachten:

  • Alle Bedingungen müssen logisch korrekt mit and verknüpft sein.
  • Fehlende Operatoren oder Leerzeichen führen dazu, dass die gesamte Query ignoriert wird.
  • Der Filter greift nur nach einem Neustart des Wazuh-Agents, da Eventchannel-Subscriptions persistent sind.
  • Die Änderung muss im aktiven localfile-Block erfolgen, der das Security-Log tatsächlich abonniert (Standardblock oder explizit überschrieben).

Architektonisch ist dieser Ansatz deutlich effizienter als Rule-Ignoring auf Manager-Seite, da die Events nie übertragen, dekodiert oder indexiert werden.

Lösung / Best Practices

Die korrekte Lösung besteht darin, die EventIDs explizit mit != auszuschließen und den bestehenden Security-Block entsprechend zu erweitern.

Beispiel einer funktionierenden Konfiguration:

<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
  <query>
    Event/System[
      EventID != 5145 and
      EventID != 5156 and
      EventID != 5447 and
      EventID != 4656 and
      EventID != 4658 and
      EventID != 4663 and
      EventID != 4660 and
      EventID != 4670 and
      EventID != 4690 and
      EventID != 4703 and
      EventID != 4907 and
      EventID != 5152 and
      EventID != 5157 and
      EventID != 4673 and
      EventID != 4957 and
      EventID != 4674 and
      EventID != 5719
    ]
  </query>
</localfile>

Wichtige Schritte:

  1. Bestehenden Security-Block prüfen und gezielt erweitern.
  2. Auf saubere XPath-Syntax achten (kein not(), keine impliziten Vergleiche).
  3. Konfiguration über agent.conf oder lokal ausrollen.
  4. Wazuh-Agent neu starten, um die Eventchannel-Subscription neu aufzubauen.

Lessons Learned / Best Practices

  • Eventchannel-Filterung ist der effizienteste Ort zur Reduktion von Lograuschen.
  • XPath-Queries müssen strikt Windows-konform sein, nicht nur logisch korrekt.
  • Kleine Syntaxfehler führen dazu, dass die gesamte Query wirkungslos bleibt.
  • Weniger Events auf Agent-Seite bedeuten:
    • geringere Netzwerkbelastung
    • weniger Decoder- und Rule-Ausführungen
    • geringere Indexgröße
    • bessere Signal-to-Noise-Ratio im SOC
  • Änderungen an Eventchannel-Abos erfordern immer einen Agent-Restart.

Fazit

Das gezielte Unterdrücken von Windows-EventIDs wie 4673 sollte nicht über Ignore-Rules, sondern direkt über eine saubere Eventchannel-Query erfolgen. Mit korrekter XPath-Syntax und konsequenter Filterung auf Agent-Seite lässt sich das Alert-Rauschen drastisch reduzieren – effizient, skalierbar und architektonisch sauber. Für produktive Wazuh-Umgebungen ist dies ein zentraler Baustein für nachhaltigen Betrieb.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1768522871053349