Windows Event Forwarding (WEF): Ereignisse agentenlos zentral sammeln

Kurzfassung: Windows Event Forwarding (WEF) ist die agentenlose Art, Windows-Ereignisse zentral zu sammeln: Die Windows-Systeme schicken ausgewählte Ereignisse selbsttätig an einen Sammelserver, ganz ohne zusätzliche Software. Das ist kostenlos, in Windows eingebaut und deshalb der günstigste Weg, die wichtigen Sicherheitsereignisse von den Endpunkten wegzubekommen, bevor ein Angreifer sie löscht. Der Kern ist das Abonnement (Subscription), das festlegt, welche Ereignisse gesammelt werden. Mit einem gepflegten Abonnement, das sich an den wichtigen Event-IDs orientiert, liefert WEF die Grundlage für die Erkennung, entweder direkt oder als Vorstufe zur Weiterleitung ins SIEM.

Windows Event Forwarding ist die Antwort auf eine Frage, die in fast jedem Erkennungsbeitrag dieser Seite auftaucht: Wie bekomme ich die Windows-Ereignisse von den Endpunkten an einen zentralen Ort, bevor sie überschrieben oder gelöscht werden? Die Event-ID-Referenz nennt die wichtigen Ereignisse, aber lokal auf dem Endpunkt sind sie oft nach einem Tag überschrieben und im Vorfall wertlos, weil der Angreifer sie kontrolliert. WEF löst das agentenlos: Windows selbst schickt die Ereignisse an einen Sammelserver, ohne dass eine zusätzliche Software installiert werden muss. Dieser Beitrag erklärt, wie WEF funktioniert, die drei Bausteine, wie man ein sinnvolles Abonnement aufbaut, und wie WEF sich ins SIEM einfügt.

Wie WEF funktioniert

Das Prinzip ist einfach: Die zu überwachenden Windows-Systeme (die Quellen) schicken ausgewählte Ereignisse an einen zentralen Windows-Server (den Sammler, Collector). Die Auswahl, welche Ereignisse gesammelt werden, steht in einem Abonnement (Subscription), das der Sammler vorgibt. Der große Vorteil gegenüber einem Agenten: WEF ist in Windows eingebaut, kostet nichts und braucht keine zusätzliche Software auf den Endpunkten, was den Betrieb und die Absicherung vereinfacht. Es gibt zwei Betriebsarten. Beim Push (source-initiated) melden sich die Quellen beim Sammler und schicken ihre Ereignisse, gesteuert per Gruppenrichtlinie, das ist die übliche Wahl für viele Endpunkte. Beim Pull (collector-initiated) holt der Sammler die Ereignisse aktiv ab, was für wenige, fest definierte Systeme passt. Für die meisten Umgebungen ist der Push-Betrieb der richtige, weil er sich über die Gruppenrichtlinie zentral auf viele Systeme ausrollen lässt.

Die drei Bausteine

  • Der Sammler (Collector). Ein Windows-Server, auf dem der Dienst Windows Event Collector läuft und die Abonnements verwaltet. Er nimmt die Ereignisse der Quellen entgegen und legt sie in einem eigenen Protokoll ab. Für größere Umgebungen können mehrere Sammler die Last verteilen.
  • Die Quellen (Sources). Die überwachten Systeme, deren WinRM-Dienst so konfiguriert ist, dass sie ihre Ereignisse an den Sammler schicken. Die Konfiguration erfolgt zentral per Gruppenrichtlinie, sodass ein neues System automatisch mitmacht, sobald es in die richtige Gruppe kommt.
  • Das Abonnement (Subscription). Der Kern: Es legt fest, welche Ereignisse gesammelt werden, in Form einer Abfrage über die Event-IDs und Protokolle. Das Abonnement ist der Teil, der über den Nutzen entscheidet, weil hier die Auswahl der wichtigen Ereignisse getroffen wird.

Ein sinnvolles Abonnement aufbauen

Wie bei der Sysmon-Konfiguration entscheidet die Auswahl über alles: Sammelt man zu wenig, fehlen die entscheidenden Ereignisse; sammelt man alles, erstickt der Sammler und das nachgelagerte SIEM in Datenmengen. Der bewährte Weg ist, sich an den wichtigen Event-IDs aus der Event-ID-Referenz zu orientieren und nach Systemklasse zu unterscheiden.

  • Von den Domain Controllern: die Anmelde- und Kontoereignisse, die Kerberos-Ereignisse (4768, 4769, 4771), die Änderungen an privilegierten Gruppen und die Replikationsereignisse. Das ist die Grundlage für fast jede Erkennung aus der Serie Angriff erkennen.
  • Von den Servern und Arbeitsplätzen: die Prozesserstellung (4688) mit Befehlszeile, die Anmeldungen (4624, 4625), die geplanten Aufgaben (4698), die Dienst-Installationen und, wo vorhanden, die Sysmon-Ereignisse.
  • PowerShell-Ereignisse: das Script Block Logging (4104), das die ausgeführten Skripte protokolliert, ein zentrales Signal, das im Beitrag zur defensiven PowerShell-Nutzung vertieft wird.
  • Die Manipulation der Protokollierung: das Löschen des Sicherheitsprotokolls (1102) und die Änderung der Überwachungsrichtlinie, beides sofortige Alarme.

Microsoft und die Community stellen fertige, gut kommentierte Abonnement-Vorlagen bereit, die genau diese Auswahl abbilden und sich als Ausgangspunkt übernehmen lassen, ähnlich den Sysmon-Referenzkonfigurationen. Man beginnt mit einer solchen Vorlage und passt sie an die eigene Umgebung an, statt bei null zu starten.

WEF und das SIEM

WEF ist kein Ersatz für ein SIEM, sondern eine ideale Vorstufe. Der Sammler bündelt die Ereignisse vieler Systeme an einem Ort, und von dort holt der SIEM-Agent sie zentral ab, statt auf jedem einzelnen Endpunkt installiert werden zu müssen. Das reduziert die Zahl der nötigen Agenten drastisch: Statt tausend Endpunkte mit einem Agenten auszustatten, genügen wenige Sammler. Damit verbindet WEF zwei Vorteile: die agentenlose Sammlung von den Endpunkten und die zentrale, saubere Übergabe ans SIEM. Die Aufbewahrung und der Manipulationsschutz gelten dann wie im Beitrag zu Log-Management und Aufbewahrung beschrieben, und der Sammler selbst gehört geschützt, weil er die gesammelten Beweise vieler Systeme hält. In kleineren Umgebungen ohne SIEM kann der WEF-Sammler sogar der zentrale Ort sein, an dem man die Ereignisse auswertet, wenn auch mit weniger Komfort als ein SIEM.

Der Einstieg

  1. Einen Sammler aufsetzen. Einen Windows-Server bestimmen, den Windows-Event-Collector-Dienst aktivieren und absichern. Für den Anfang genügt einer.
  2. Die Quellen per Gruppenrichtlinie anbinden. Den WinRM-Dienst und die Weiterleitung an den Sammler zentral konfigurieren, zunächst für eine Testgruppe.
  3. Mit einer Abonnement-Vorlage starten. Eine gepflegte Vorlage übernehmen, die die wichtigen Event-IDs abdeckt, statt die Abfrage von Hand zu schreiben.
  4. Das Volumen prüfen und anpassen. Auf der Testgruppe messen, wie viele Ereignisse ankommen, und die Auswahl nachschärfen, bevor man breit ausrollt.
  5. Ans SIEM anbinden und ausrollen. Den Sammler ans SIEM anschließen, dann die übrigen Systeme in die Gruppenrichtlinie aufnehmen. Ab hier macht jedes neue System automatisch mit.

Fazit

Windows Event Forwarding ist der günstigste und sauberste Weg, die wichtigen Windows-Ereignisse von den Endpunkten an einen zentralen Ort zu bringen, agentenlos, in Windows eingebaut und zentral per Gruppenrichtlinie steuerbar. Der Kern ist das Abonnement, das sich an den wichtigen Event-IDs orientiert und nach Systemklasse unterscheidet, und der größte Nutzen entsteht, wenn WEF als Vorstufe die Ereignisse bündelt und zentral ans SIEM übergibt. Für ein Blue Team ist WEF deshalb eine der lohnendsten Grundlagen überhaupt, weil fast jede Windows-Erkennung darauf aufbaut, dass die Ereignisse rechtzeitig und vollständig am zentralen Ort ankommen, bevor ein Angreifer sie löschen kann.

NH

$ whoami

Norbert Hofmann

Cyber Defense Analyst im Security Operations Center eines Managed Security Service Providers. Red und Blue Teaming, Malware-Analyse, Incident Response und Security-Awareness-Trainings. Finalist bei „Deutschlands bester Hacker“ 2022, mehrere CVE-Einträge für WordPress-Plugins.