Windows EventID 4624 gezielt filtern: Erfolgreiche RDP-Anmeldungen (LogonType 10) sauber mit Wazuh erfassen

von

Einleitung

Erfolgreiche Windows-Anmeldungen (EventID 4624) gehören zu den zentralen Telemetriedaten in Wazuh-Umgebungen. Gleichzeitig erzeugen sie ein enormes Datenvolumen, da nahezu jede lokale, Netzwerk- oder Dienstanmeldung dieses Event auslöst. Für viele Security- und SOC-Use-Cases sind jedoch nur bestimmte Anmeldearten relevant – insbesondere Remote Desktop (RDP), das über LogonType 10 abgebildet wird. Dieser Artikel zeigt, wie sich EventID 4624 bereits auf Agent-Seite so filtern lässt, dass ausschließlich erfolgreiche RDP-Anmeldungen gesammelt werden – und ordnet diese Entscheidung auch aus forensischer Sicht ein.

Ausgangslage / Problemstellung

In einer Windows-Umgebung erzeugt Wazuh zahlreiche Alerts zu erfolgreichen Anmeldungen mit EventID 4624. Diese werden unter anderem durch unterschiedliche Rules ausgelöst (z. B. Rule IDs 92653 und 92657), die verschiedene Logon-Typen abdecken.

Das operative Ziel ist klar:

  • Relevant: Erfolgreiche RDP-Anmeldungen (LogonType 10)
  • Nicht relevant: Lokale Anmeldungen, Netzwerk-Logons, Service-Logons etc.

Anstatt diese Unterscheidung erst auf Rule- oder Alert-Ebene zu treffen, soll die Datenerhebung bereits an der Quelle eingeschränkt werden – zentral über die Shared Agent Configuration.

Technische Analyse

Windows schreibt erfolgreiche Anmeldungen mit EventID 4624 in das Security Event Log. Der konkrete Anmeldetyp wird im Abschnitt EventData über das Feld LogonType definiert:

  • 2 – Interaktive Anmeldung (lokal)
  • 3 – Netzwerk
  • 5 – Service
  • 7 – Unlock
  • 10 – RemoteInteractive (RDP)

Wazuh sammelt Windows-Events über den eventchannel-Mechanismus. Dabei kann die Windows Event Log API direkt per XPath-Query gefiltert werden. Diese Filter greifen vor der Übertragung an den Manager und sind damit:

  • performanter als Rule-Ignoring
  • konsistenter über große Agent-Gruppen
  • ideal zur Reduktion von Lograuschen

Entscheidend ist eine syntaktisch korrekte XPath-Abfrage, die sowohl auf System/EventID als auch auf EventData/Data[@Name='LogonType'] zugreift.

Lösung / Best Practices

Die saubere Lösung besteht darin, den bestehenden Security-Eventchannel so zu konfigurieren, dass nur EventID 4624 mit LogonType 10 gesammelt wird.

Dies erfolgt zentral über die Shared Agent Configuration:

Pfad auf dem Manager:

/var/ossec/etc/shared/<groupname>/agent.conf

Beispielkonfiguration:

<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
  <query>
    Event[
      System/EventID = 4624 and
      EventData/Data[@Name='LogonType'] = 10
    ]
  </query>
</localfile>

Wichtige Hinweise:

  • Die XPath-Abfrage ist strikt Windows-konform und feldsensitiv.
  • LogonType muss exakt so benannt sein, wie Windows es im EventData-Block liefert.
  • Die Konfiguration greift nur für Agents, die dieser Gruppe zugewiesen sind.
  • Nach der Änderung ist ein Neustart des Wazuh-Agents erforderlich.

Das Ergebnis: Es werden ausschließlich erfolgreiche RDP-Anmeldungen gesammelt und an den Manager gesendet – und damit auch nur die relevanten RDP-bezogenen Rules ausgelöst.

Lessons Learned / Best Practices

  • Eventchannel-Filtering ist der effizienteste Ort zur Reduktion von Windows-Lograuschen.
  • XPath-Queries erlauben sehr feingranulare Filterung auf Feld-Ebene.
  • Weniger gesammelte Events bedeuten:
    • geringere Agent- und Netzwerklast
    • weniger Decoder- und Rule-Ausführungen
    • klarere Alerts für das SOC
  • RDP-Zugriffe (LogonType 10) sollten grundsätzlich separat betrachtet werden, da sie ein erhöhtes Angriffsrisiko darstellen.
  • Shared Agent Configurations sind ideal, um solche Filter konsistent über viele Systeme auszurollen.

Forensischer Hinweis (wichtig):
Das konsequente Ausfiltern erfolgreicher Anmeldungen aus anderen Logon-Kategorien (z. B. LogonType 2 oder 3) reduziert zwar das Datenvolumen, hat aber einen direkten Einfluss auf die forensische Tiefe im Incident-Fall. Bei einem erfolgreichen Angriff stehen dann weniger Kontextinformationen zur Verfügung, um laterale Bewegungen, vorbereitende Zugriffe oder Missbrauch legitimer Anmeldewege nachzuvollziehen. In Umgebungen mit erhöhten Compliance- oder Forensik-Anforderungen sollte daher sorgfältig abgewogen werden, ob solche Events vollständig verworfen oder alternativ mit längeren Retention-Zeiten, reduzierter Alerting-Stufe oder separaten Indizes aufbewahrt werden.

Fazit

Wer in Wazuh nur wirklich sicherheitsrelevante erfolgreiche Anmeldungen auswerten möchte, sollte EventID 4624 nicht pauschal sammeln. Durch gezielte Eventchannel-Filterung auf LogonType 10 lassen sich ausschließlich erfolgreiche RDP-Anmeldungen erfassen – effizient, skalierbar und architektonisch sauber. Gleichzeitig gilt: Jede Reduktion an der Quelle ist eine bewusste Designentscheidung. Weniger Daten bedeuten klarere Signale im Alltag, aber auch weniger forensisches Material im Ernstfall. Genau diese Balance sauber zu definieren, ist ein zentraler Bestandteil eines reifen Wazuh-Betriebskonzepts.

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/p1768673506913689