Sysmon Windows Event Forwarding: Ein Security-Team, das nach einem Vorfall nur die letzten Stunden lokaler Windows-Ereignisse findet, kann den tatsächlichen Angriffsverlauf kaum rekonstruieren. Microsoft Sysmon protokolliert ausgewählte Prozesse, Netzwerkverbindungen und Änderungen; Windows Event Forwarding (WEF) und Windows Event Collector (WEC) ermöglichen eine zentrale Sammlung. Mit guter Filterung und korrekter Aufbewahrung entsteht eine belastbare Grundlage für Incident Response, ohne jeden Endpunkt mit übermäßigem Logging zu überlasten. Dieser Fachartikel zu Sysmon Windows Event Forwarding beschreibt Architektur, Sicherheitsgrenzen, Logqualität und konkrete Prüfszenarien für mittelständische Windows-Umgebungen.
Autor: Salman Dolatpanah Gortlar · GORTNET IT-Dienstleistungen ·
Welche Fragen gute Sicherheitslogs beantworten müssen
Nach einer Kontoübernahme oder Malware-Meldung interessieren nicht nur der Name eines verdächtigen Programms, sondern Zeitpunkt, Ursprung und Wirkung. Welcher Benutzer startete den Prozess, welches Programm war sein Elternprozess, welcher Host kontaktierte eine fremde Adresse und wurden im selben Zeitraum Registry-Werte oder Dateien verändert? Windows Security Logs, Sysmon und EDR liefern dafür unterschiedliche Ausschnitte einer Ereigniskette.
Eine verlässliche Sammlung braucht einen klaren fachlichen Zweck. Wer wahllos sämtliche verfügbaren Events aktiviert, erzeugt Kosten und Rauschen, ohne Angriffe zwangsläufig besser zu erkennen. Definieren Sie zunächst fünf bis zehn Untersuchungsfragen, die für Ihre Infrastruktur relevant sind. Leiten Sie daraus Datenquellen, Eventtypen und Aufbewahrungsanforderungen ab. So bleibt die Logging-Architektur wartbar und ihre Wirksamkeit messbar.
Sysmon Windows Event Forwarding: Aufgaben sauber trennen
Sysmon ist ein Telemetrieerzeuger auf dem Windows-Endpunkt oder Server. Er kann unter anderem Prozessstarts und zugehörige Kommandozeilen, Prozess-GUIDs, bestimmte Netzwerkverbindungen, Datei- und Registry-Ereignisse erfassen. Windows Event Forwarding transportiert ausgewählte Windows-Ereignisse über den Windows-Eventing- und WS-Management-Mechanismus zum Collector. Der Windows Event Collector nimmt diese Events entgegen und speichert sie in dafür vorgesehenen Eventlogs.
WEF bewertet keine Malware und Sysmon entscheidet nicht, ob ein Vorgang bösartig ist. Diese Logik entsteht in Erkennungsregeln, SIEM-Korrelationen und der menschlichen Analyse. Trennen Sie deshalb Erhebung, Transport, Speicherung, Anreicherung und Alarmierung als technische Bausteine. Damit können Sie später den SIEM-Anbieter wechseln oder zusätzliche Datenquellen anbinden, ohne sämtliche Endpunkte neu zu instrumentieren.
Integriertes und Standalone Sysmon unterscheiden
Microsoft dokumentiert inzwischen auch eine optionale integrierte Sysmon-Funktion auf entsprechend unterstützten Windows-11- und Windows-Server-2025-Systemen. Daneben existiert das bekannte Standalone-Sysmon aus Sysinternals. Bei der Planung müssen Sie prüfen, welche Variante auf einem Gerät vorhanden ist, wie sie verwaltet wird und welche Featurestände das eingesetzte Betriebssystem tatsächlich bereitstellt.
Standalone und integriertes Sysmon können laut Microsoft nicht gleichzeitig auf demselben Gerät aktiviert sein. Bei einer Migration darf das Standalone-Produkt deshalb nicht einfach durch Aktivieren einer zweiten Instanz ergänzt werden. Testen Sie Konfigurationsübernahme, Eventkanal, Filterregeln und Rollback in einem begrenzten Pilot. Ein erfolgreicher Dienststart allein beweist nicht, dass die gewohnten Erkennungsfelder in der erwarteten Form eintreffen.
Wichtige Sysmon Events und praktische Untersuchungen
Sysmon Event ID 1 beschreibt einen Prozessstart und enthält je nach Konfiguration unter anderem Image, Command Line und Parent-Informationen. Event ID 3 kann Netzwerkverbindungen darstellen, ist aber aufgrund des großen Datenvolumens häufig nicht pauschal aktiviert. Event ID 22 enthält DNS-Abfragen und kann bei der Rekonstruktion externer Kommunikationsziele helfen. Process Access und andere fortgeschrittene Ereignisse liefern weitere Hinweise, müssen jedoch besonders sorgfältig gefiltert werden.
Für die Untersuchung ist eine zeitliche Kette hilfreich: Prozess gestartet, DNS-Name aufgelöst, Netzwerkverbindung hergestellt, Datei geschrieben und gegebenenfalls Registry verändert. Kein einzelnes Event beweist automatisch einen Angriff. Beispielsweise können Verwaltungs- oder Backup-Programme ähnliche technische Aktionen auslösen. Nutzen Sie Prozess-GUID, Hostname, Benutzer, Uhrzeit und bekannte Wartungsfenster, um legitime Abläufe von verdächtigen Aktivitäten zu unterscheiden.
Windows Security Events ergänzend erfassen
Sysmon ersetzt nicht die gewöhnlichen Windows-Sicherheitslogs. Für Domänenumgebungen sind Authentifizierungsereignisse von Domain Controllern wesentlich: Anmeldungen, Kerberos-Ticketanforderungen, Konto- und Gruppenänderungen sowie privilegierte Aktionen bilden oft den entscheidenden Identitätskontext. Die genauen Event-IDs und enthaltenen Felder variieren je nach Audit-Policy und Windows-Version.
Vermeiden Sie eine reine Endpoint-Perspektive, wenn der eigentliche Angriff auf Identitäten abzielt. Eine verdächtige lokale PowerShell-Aktion lässt sich deutlich besser bewerten, wenn Sie zugehörige AD-Anmeldeereignisse und Änderungen an Administratorgruppen hinzuziehen. Dokumentieren Sie, welche Logquellen für einen vollständigen Incident notwendig sind, damit der Collector nicht nur die leicht erreichbaren Arbeitsstationen berücksichtigt.
WEF-Architektur: Collector und Subscriptions
Windows Event Collector unterstützt die zentrale Entgegennahme weitergeleiteter Ereignisse. Bei Source-Initiated Subscriptions melden sich dafür konfigurierte Clients beim Collector an und liefern die gewünschten Events. Eine Collector-Initiated Subscription verwendet einen anderen Betriebsweg. Welche Variante geeignet ist, hängt von Domänenstruktur, Anzahl der Endgeräte, Erreichbarkeit und gewünschtem Verwaltungsmodell ab.
Für größere Umgebungen sind Kapazitätsplanung, Lastverteilung und eine klare Trennung von Collectors und Analyseplattform wichtig. Ein einziger Collector, dessen Systempartition bei hoher Ereignislast vollläuft, macht die Überwachung genau dann wertlos, wenn besonders viele Warnungen entstehen. Planen Sie getrennte Speicherkapazität, Log-Rotation, Wartungsfenster und eine kontrollierte Weiterleitung an das SIEM. Die erwartete Ereignisrate sollte im Pilot mit realen Endpunkten gemessen werden.
WinRM, Firewalls und sichere Erreichbarkeit
WEF verwendet WS-Management und ist daher mit der WinRM-Konfiguration und unterstützten Authentifizierungsmechanismen verbunden. Die benötigten Kommunikationswege hängen vom gewählten Subscription-Modell und Transport ab. Eine Infrastruktur darf deshalb nicht pauschal alle Managementports zwischen sämtlichen VLANs öffnen. Bestimmen Sie Richtung, Quelle, Ziel und erlaubte Transportmethode pro Collector und Clientgruppe.
Absichern bedeutet auch, Collectors selbst zu härten: unnötige lokale Dienste entfernen, privilegierte Zugriffe begrenzen, Sicherheitsupdates einspielen und Logs vor unbefugten Änderungen schützen. Prüfen Sie, ob die geplante TLS- beziehungsweise Domänenauthentifizierung in Ihrer Architektur unterstützt wird. Eine Testverbindung auf einen WinRM-Port ist nur ein Netzwerktest, noch kein Nachweis einer funktionierenden und autorisierten Event-Weiterleitung.
Filterregeln und Datenvolumen realistisch dimensionieren
Sysmon kann sehr große Ereignismengen erzeugen. Besonders Netzwerkverbindungen, Image-Load-Ereignisse und bestimmte Dateizugriffe benötigen strikte Auswahl. Entwickeln Sie Konfigurationsfilter anhand konkreter Detection-Ziele und überwachen Sie deren Auswirkungen auf CPU, Speicher, Netzwerk und SIEM-Kosten. Zu aggressive Ausschlüsse sind ebenfalls gefährlich, weil sie genau die relevanten Prozessketten entfernen können.
Arbeiten Sie mit dokumentierten Filterversionen und einer Pilotgruppe aus unterschiedlichen Rollen: Domänencontroller, Anwendungsserver, Standard-Workstations und Administratorgeräte. Vergleichen Sie nach jedem Update die Zahl der erwarteten und tatsächlichen Events. Eine einmal kopierte Community-Konfiguration darf nicht ungeprüft jahrelang unverändert bleiben. Neue Software und aktualisierte Sysmon-Versionen können die Verteilung von Ereignissen verändern.
Zeitstempel, Aufbewahrung und Beweissicherung
Bei der Rekonstruktion eines Vorfalls müssen Events verschiedener Systeme zeitlich zusammenpassen. Sorgen Sie für zuverlässige Uhrzeitsynchronisation und bewahren Sie Zeitstempel und Zeitzonen korrekt auf. Sysmon-Ereignisse verwenden UTC-Zeitangaben, während Darstellungen in Analysewerkzeugen je nach Einstellung lokalisiert werden können. Ein falsch interpretiertes Zeitfenster kann bei der Zuordnung von Angriffsschritten zu gravierenden Fehlern führen.
Bestimmen Sie für die Aufbewahrung den geschäftlichen und rechtlichen Bedarf. Ein kurzer lokaler Ringpuffer kann sinnvoll sein, reicht aber für eine mehrwöchige Untersuchung oft nicht aus. Zentral gespeicherte Sicherheitslogs sollten gegen unberechtigte Veränderung geschützt und von der normalen Administratorrolle getrennt sein. Für forensische Fälle dokumentieren Sie Export, Hashwerte, Zugriff und Übergabe der relevanten Daten, damit die Untersuchung später nachvollziehbar bleibt.
Erkennungsregeln und Triage-Runbooks entwerfen
Ein guter Alarm verbindet eine beobachtete Verhaltensweise mit einer plausiblen Risikohypothese. Beispiele sind unerwartete Prozesse unter einem privilegierten Kontext, neu installierte Remote-Tools außerhalb genehmigter Wartung oder ungewöhnliche Änderungen an sicherheitsrelevanten Registry-Pfaden. Der Alarm sollte die zugrunde liegenden Events referenzieren und genug Kontext für die erste Bewertung liefern.
Für jeden Detection-Use-Case definieren Sie Priorität, Datenquellen, typische Fehlalarme, Prüfschritte und eine verantwortliche Reaktionsrolle. Legen Sie fest, wann ein System isoliert, ein Konto gesperrt oder zunächst zusätzliche Evidenz gesammelt werden muss. Eine aggressive automatische Reaktion auf jeden Sysmon-Prozessstart würde den Betrieb destabilisieren. Entscheidend ist die passende Kombination aus technischem Signal und belastbarer Einordnung.
Monitoring der Logpipeline selbst
Eine zentrale Logplattform braucht eigenes Monitoring: Welcher Endpunkt hat zuletzt geliefert? Welche Collector-Queue wächst? Welche Subscription meldet Fehler und wann laufen Speicherkontingente voll? Ohne solche Kontrollen können monatelang ganze Gruppen nicht mehr erfasst werden, während das Dashboard dennoch normale historische Events zeigt. Berücksichtigen Sie neue Geräte beim Onboarding und entfernen Sie alte Hosts beim Offboarding.
Messen Sie die Event-Latenz, die Zahl aktiver Quellen und Datenverluste bei Störungen. Simulieren Sie einen kurzzeitig nicht erreichbaren Collector, um das tatsächliche Wiederanlaufverhalten zu prüfen. Führen Sie einen regelmäßigen Abgleich zwischen Inventar und eingehenden Hosts durch. Erst wenn die Pipeline selbst überprüfbar ist, dürfen Sicherheitsverantwortliche ihre Auswertungen als ausreichende Datengrundlage ansehen.
30-Tage-Plan für mittelständische Windows-Netze
Woche eins: Untersuchungsszenarien, Hostklassen und bestehende Audit-Richtlinien festlegen. Woche zwei: Sysmon-Konfiguration auf einer kleinen Pilotgruppe ausrollen und Event-Weiterleitung auf einen separaten Collector testen. Woche drei: relevante Events im SIEM zuordnen, Filter verfeinern und zwei praxisnahe Detection-Runbooks entwickeln. Woche vier: Speicherlast, Aufbewahrung, Rollback und Zugriffsschutz kontrollieren.
Das Projekt gilt als erfolgreich, wenn Sie in einem simulierten Vorfall eine vollständige Timeline von Prozessstart, Netzwerkaktivität und relevanten AD-Ereignissen rekonstruieren können. Ein schöner Loggraph ist kein Ersatz für diesen Nachweis. Führen Sie nach größeren Windows- und Sysmon-Updates einen erneuten Funktionstest durch.
Häufige Fragen zu Sysmon und WEF
Ist Sysmon ein Antivirenprogramm?
Nein. Sysmon erzeugt Telemetrie; Schutzmaßnahmen und Bewertungen entstehen durch weitere Kontrollen und Analyseprozesse.
Darf man integriertes und Standalone Sysmon gleichzeitig betreiben?
Nein, Microsoft dokumentiert, dass beide Varianten nicht gleichzeitig auf demselben Gerät aktiviert sein dürfen.
Müssen alle Events ungefiltert an das SIEM gesendet werden?
Nein. Zielgerichtete Filter sind für Performance, Kosten und brauchbare Sicherheitsanalysen wichtig.
Kann WEF eine SIEM-Lösung ersetzen?
WEF sammelt Events, ersetzt aber nicht deren umfassende Korrelation, Anreicherung und Analyse.
Fazit: Ereignisketten statt isolierter Alarme
Mit Sysmon Windows Event Forwarding lässt sich eine überprüfbare Sicherheitsdatenbasis aufbauen. Entscheidend sind eine kontrollierte Endpunktkonfiguration, sichere zentralisierte Speicherung, eine funktionierende Logpipeline und konkrete Use Cases. Testen Sie das System anhand eines simulierten Vorfalls und verbessern Sie es aus den Ergebnissen.
Über den Autor
Salman Dolatpanah Gortlar schreibt für GORTNET praxisorientierte technische Fachbeiträge zu Windows Server, Monitoring und IT-Sicherheit. Die beschriebenen Methoden ersetzen keine forensische Untersuchung im Einzelfall.
Weitere GORTNET-Ressourcen
Für einen Aufbau oder Review Ihrer Logging- und Monitoring-Architektur GORTNET kontaktieren.
Offizielle Dokumentation
Stand: 28. Oktober 2026. Details nach Windows-Version, eingesetzter Sysmon-Variante und rechtlichen Aufbewahrungsanforderungen prüfen.