Windows-Überwachungsrichtlinie und Sysmon: Logging-Baseline

Wenn in einem Windows-Netzwerk etwas schiefgeht, lauten die ersten Fragen immer gleich: Welches Konto hat sich wo angemeldet, was wurde ausgeführt, was hat sich geändert, und wohin wurde eine Verbindung aufgebaut? Mit den Standardeinstellungen beantwortet Windows davon nur wenige. Die Prozesserstellung wird nicht protokolliert, Befehlszeilen werden nicht erfasst, das Sicherheitsprotokoll läuft auf einem ausgelasteten Server innerhalb von Stunden über, und nichts verlässt den Host.

Dieser Leitfaden baut eine Logging-Baseline in vier Schichten auf: erweiterte Überwachungsrichtlinie, einige zusätzliche Einstellungen, Sysmon und Weiterleitung.

Schicht 1: erweiterte Überwachungsrichtlinie

Machen Sie zuerst die erweiterte Überwachungsrichtlinie maßgeblich. Aktivieren Sie unter Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options die Einstellung Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings (Unterkategorieeinstellungen erzwingen, die Kategorieeinstellungen außer Kraft setzen).

Konfigurieren Sie anschließend die Unterkategorien unter Security Settings > Advanced Audit Policy Configuration > Audit Policies. Ein solider Ausgangspunkt, weitgehend an Microsofts Baseline-Empfehlungen ausgerichtet:

Die effektive Richtlinie auf einem Host prüfen:

auditpol /get /category:*
auditpol /get /subcategory:"Process Creation"

Im Labor können Sie einzelne Unterkategorien direkt setzen (in der Produktion bleibt das GPO die maßgebliche Quelle):

auditpol /set /subcategory:"Process Creation" /success:enable

Schicht 2: die Einstellungen, die Ereignisse nützlich machen

Befehlszeilen können Geheimnisse enthalten (als Parameter übergebene Kennwörter). Das ist ein Grund, den Lesezugriff auf die Logs einzuschränken und diese Skripte zu korrigieren, nicht aber, die Befehlszeilenprotokollierung abgeschaltet zu lassen.

Achten Sie außerdem auf Beweisvernichtung: 1102 (Sicherheitsprotokoll gelöscht) und 104 (anderes Protokoll gelöscht, im System-Log) sollten immer einen Alarm auslösen.

Schicht 3: Sysmon

Sysmon (System Monitor, aus Microsoft Sysinternals) ist ein kostenloser Treiber mit Dienst, der detaillierte Prozess-, Netzwerk-, Datei- und Registrierungsaktivität in Applications and Services Logs > Microsoft > Windows > Sysmon > Operational schreibt. Seit 2026 ist es zudem ein integriertes optionales Feature von Windows 11 und Windows Server 2025, standardmäßig deaktiviert und mit demselben XML konfiguriert; der Leitfaden zum Sysmon-Deployment behandelt die Wahl zwischen beiden Varianten. Die nützlichsten Ereignisse:

Sysmon ist nur so gut wie seine Konfiguration: Eine leere Konfiguration protokolliert sehr wenig, eine naive flutet Ihr SIEM. Beginnen Sie mit einer gepflegten Community-Konfiguration wie SwiftOnSecuritys sysmon-config oder Olaf Hartongs sysmon-modular und passen Sie sie dann an Ihre Umgebung an.

# Mit einer Konfiguration installieren
Sysmon64.exe -accepteula -i sysmonconfig.xml
# Konfiguration später aktualisieren
Sysmon64.exe -c sysmonconfig.xml
# Aktive Konfiguration anzeigen
Sysmon64.exe -c

Verteilen Sie Sysmon über Ihr Softwareverteilungswerkzeug, fixieren Sie die Version und überwachen Sie, dass der Dienst Sysmon64 läuft: Ihn zu stoppen ist ein naheliegender Schritt für Angreifer (Sysmon protokolliert Ereignis 4 bei Statusänderungen des Dienstes und 16 bei Konfigurationsänderungen).

Schicht 4: Ereignisse vom Host holen

Lokale Logs kann jeder mit Administratorrechten löschen. Leiten Sie sie weiter.

Windows Event Forwarding (WEF) ist integriert und benötigt keinen Agent:

1. Auf einem Collector-Server: wecutil qc, um den Dienst Windows Event Collector zu konfigurieren.
2. Quellinitiierte Abonnements anlegen (XPath-Abfragen, die die oben genannten Ereignis-IDs auswählen).
3. Per GPO auf den Quellen: Administrative Templates > Windows Components > Event Forwarding > Configure target Subscription Manager = Server=http://wec01.corp.example:5985/wsman/SubscriptionManager/WEC,Refresh=60.
4. Dem Konto Network Service auf den Quellen Lesezugriff auf das Sicherheitsprotokoll gewähren, indem Sie es über eingeschränkte Gruppen (Restricted Groups) oder Gruppenrichtlinien-Einstellungen (Preferences) in die Gruppe Event Log Readers aufnehmen.

Senden Sie ForwardedEvents vom Collector an Ihr SIEM. Wenn Sie bereits einen SIEM- oder EDR-Agent betreiben, richten Sie stattdessen diesen auf dieselben Ereignis-IDs aus; entscheidend ist, dass die Ereignisse den Host innerhalb von Minuten verlassen.

So sieht es richtig aus

Ein schneller Test der Baseline: Stellen Sie die Fragen eines fiktiven Vorfalls und prüfen Sie, ob Ihre Logs sie beantworten:

• Wer hat sich letzten Dienstag an Server X angemeldet, und von wo? 4624 mit Anmeldetyp und Quell-IP, weitergeleitet.
• Was hat diese Sitzung ausgeführt? 4688 mit Befehlszeilen, Sysmon 1, PowerShell 4104.
• Hat etwas auf LSASS zugegriffen? Sysmon 10, gefiltert auf lsass.exe.
• Wurde Persistenz eingerichtet? 4697 / 7045 (Dienst), 4698 (geplante Aufgabe), Sysmon 13 auf Run-Schlüsseln.
• Wohin wurde eine Verbindung aufgebaut? Sysmon 3 und 22.
• Hat jemand versucht, Spuren zu verwischen? 1102, 104, Sysmon 4/16, Defender 5001/5007.

Checkliste

• Erweiterte Überwachungsrichtlinie mit Vorrang erzwungen; Unterkategorien wie oben gesetzt
• Befehlszeilen-Erfassung in 4688 aktiviert
• Sicherheitsprotokoll für Tage statt Stunden dimensioniert; Alarme bei gelöschten Logs
• Sysmon mit gepflegter, angepasster Konfiguration verteilt
• Ereignisse weitergeleitet (WEF oder Agent) und zentral aufbewahrt
• Vorfallfragen in einer Tabletop-Übung durchgängig beantwortet

Logging verhindert nichts, aber jeder andere Schutz auf dieser Karte ist vertrauenswürdiger, wenn Sie sehen können, dass er funktioniert, und den Moment erkennen, in dem er aufhört.