Kurzfassung: Sysmon ist nur so gut wie seine Konfiguration. Der Kern ist die Filterlogik: Sysmon schlägt vor, alles zu protokollieren, und die Konfiguration schneidet zu, was wirklich zählt, meist über Ausschlüsse (was ist bekannt gut) statt Einschlüsse. Man fängt nicht bei null an, sondern mit einer der gepflegten Referenzkonfigurationen (SwiftOnSecurity, Florian Roths Fork, Olaf Hartongs sysmon-modular) und passt sie an die eigene Umgebung an, weil jede Umgebung eigene laute Prozesse hat. Die wichtigsten Event-Typen sind Prozessstart (1), Netzwerkverbindung (3), Treiber-Load (6), LSASS-Zugriff (10), Datei- und Registry-Änderungen (11, 13), DNS (22) und die WMI-Persistenz (19 bis 21). Der Rest ist Tuning gegen das Volumen.
Sysmon konfigurieren ist der Schritt, der aus dem Werkzeug eine Erkennungsquelle macht. Der Beitrag zu Sysmon erklärt, was der Dienst ist und wie man ihn installiert; hier geht es um die Frage, die danach kommt und die über den Nutzen entscheidet: Was soll er protokollieren, und was nicht? Ohne Konfiguration protokolliert Sysmon fast nichts, und mit der falschen Konfiguration erzeugt er so viel, dass das SIEM erstickt oder das Budget sprengt. Dieser Beitrag zeigt die Denkweise hinter einer guten Konfiguration, die wichtigen Event-Typen mit dem, worauf es bei jedem ankommt, und den praktischen Weg von der Referenzkonfiguration zur eigenen. Er reproduziert keine vollständige XML, weil die schnell veraltet und in jeder Umgebung anders aussieht, sondern vermittelt, wie man sie liest und anpasst.
Die Filterlogik verstehen
Der wichtigste Punkt zuerst: Sysmon filtert anders als die klassische Windows-Überwachung. Statt einer Liste, was protokolliert werden soll, arbeitet eine gute Konfiguration überwiegend mit Ausschlüssen. Der Grund ist praktisch: Angreifer benutzen ihre eigenen, unbekannten Werkzeuge, und was man ausschließt, ist das Bekannte und Gutartige. Wer per Einschluss nur die bekannten bösen Dinge protokolliert, verpasst alles Neue; wer das bekannte Gute ausschließt und den Rest protokolliert, sieht auch das Unbekannte. Jeder Event-Typ hat deshalb typischerweise einen Block mit onmatch="exclude", in dem die legitimen, lauten Prozesse und Pfade stehen, die in dieser Umgebung normal sind. Das Ergebnis: Sysmon protokolliert alles außer dem, was ausdrücklich als harmlos bekannt ist. Genau diese Ausschlussliste ist der Teil, der in jeder Umgebung anders aussieht und der die eigentliche Tuning-Arbeit ausmacht.
Mit einer Referenzkonfiguration anfangen
Niemand schreibt eine Sysmon-Konfiguration von null. Es gibt drei gepflegte Ausgangspunkte, die sich in Umfang und Philosophie unterscheiden:
- SwiftOnSecurity/sysmon-config. Die klassische Grundlage, ausführlich kommentiert und bewusst darauf ausgelegt, wenig Rauschen bei hoher Aussagekraft zu erzeugen. Der beste Einstieg, um die Filterlogik zu lernen, weil die Kommentare erklären, warum welche Regel existiert.
- Neo23x0/sysmon-config. Florian Roths Fork der SwiftOnSecurity-Konfiguration, der viele offene Verbesserungen zusammengeführt und die Abdeckung um aktuelle Techniken erweitert hat, etwa benannte Pipes von Cobalt Strike. Es gibt auch eine Variante mit Sperrregeln, die seit Sysmon 14 möglich sind, aber mit Vorsicht einzusetzen.
- olafhartong/sysmon-modular. Der umfangreichste Ansatz, modular aufgebaut und durchgängig auf MITRE ATT&CK abgebildet. Man kann eine ausbalancierte Standardkonfiguration nehmen oder aus den Modulen eine maßgeschneiderte bauen. Die sehr ausführliche Variante erzeugt viel Volumen und gehört vor dem Produktiveinsatz getunt.
Alle drei werden bei jeder neuen Sysmon-Version aktualisiert (aktuell für Version 15). Der Rat der Autoren ist einhellig: Keine dieser Konfigurationen ungetestet in Produktion nehmen. Und ein zweiter Rat, der oft übersehen wird: nicht für jedes System dieselbe Konfiguration, sondern eigene für Domain Controller, Server und Arbeitsplätze, weil dort völlig unterschiedlicher Verkehr normal ist.
Die Event-Typen, auf die es ankommt
| ID | Event | Worauf es ankommt |
|---|---|---|
| 1 | Prozess erstellt | Der wichtigste Event. Vollständige Befehlszeile, Elternprozess, Hash und Signatur. Ausschlüsse für die lautesten legitimen Prozesse (Update-Dienste, Monitoring), aber nie für die Interpreter (powershell, cmd, wscript). |
| 3 | Netzwerkverbindung | Welcher Prozess spricht mit welchem Ziel. Sehr laut, wenn ungefiltert. Man protokolliert gezielt: Verbindungen von Prozessen, die selten Netzwerk brauchen (Office, Skript-Hosts), und zu verdächtigen Ports. |
| 6 | Treiber geladen | Das Kernsignal für BYOVD. Muss aktiviert sein, um verwundbare Treiber gegen die LOLDrivers-Liste zu prüfen. Wenig Volumen, hohe Aussagekraft. |
| 7 | Image geladen (DLL) | Sehr hohes Volumen. Nur gezielt für bestimmte verdächtige DLLs aktivieren, nicht pauschal, sonst erstickt das SIEM. |
| 8 | Remote-Thread erstellt | Code-Injektion in fremde Prozesse. Geringes Volumen, starkes Signal. |
| 10 | Prozesszugriff | Der Zugriff auf lsass.exe zum Auslesen von Zugangsdaten. Gefiltert auf die kritischen Zugriffsmasken, die bekannten Sicherheitsprozesse ausgenommen. Eines der wichtigsten Signale überhaupt. |
| 11 | Datei erstellt | Neue Dateien in verdächtigen Pfaden (Temp, Autostart, Aufgaben). Gefiltert, sonst zu laut. |
| 13 | Registry-Wert gesetzt | Änderungen an Autostart-Schlüsseln und Schutzeinstellungen. Gezielt auf die relevanten Schlüssel begrenzt. |
| 15 | FileCreateStreamHash | Alternative Datenströme, oft für das Herkunftskennzeichen heruntergeladener Dateien (Mark of the Web). |
| 19 bis 21 | WMI-Ereignisse | Filter, Konsument und Bindung permanenter WMI-Konsumenten: die Persistenz, die im Repository statt im Dateisystem lebt. Immer aktivieren. |
| 22 | DNS-Anfrage | Anfragen pro Prozess. Grundlage für die Erkennung von DNS-Tunneling. Ausschlüsse für die üblichen legitimen Domänen halten das Volumen im Griff. |
Die Kunst ist die Balance: Event 1, 6, 8, 10, 19 bis 21 haben geringes Volumen und hohe Aussagekraft und gehören fast immer aktiviert. Event 3, 7, 11, 13 und 22 sind wertvoll, aber laut, und leben von guten Ausschlüssen. Wer sie ungefiltert aktiviert, produziert Datenmengen, die das Budget sprengen, bevor eine Regel greift, dasselbe Problem wie bei der Alert Fatigue, nur auf der Datenebene.
Der Weg zur eigenen Konfiguration
- Referenz wählen und verstehen. Mit SwiftOnSecurity anfangen, um die Logik zu lernen, oder mit sysmon-modular, wenn die ATT&CK-Abbildung und der modulare Aufbau gewünscht sind. Die Kommentare lesen, nicht nur die Datei laden.
- Auf einer Testgruppe ausrollen. Ein bis zwei Wochen auf einer kleinen, repräsentativen Gruppe laufen lassen und das Volumen pro Event-Typ messen. So zeigt sich, welche Prozesse in dieser Umgebung die lautesten sind.
- Die eigenen lauten Prozesse ausschließen. Die Softwareverteilung, das Monitoring, die Backup-Agenten und die Fachanwendungen erzeugen legitimen Lärm. Sie kommen mit Pfad und Signatur in die Ausschlüsse, damit das Wesentliche sichtbar bleibt. Der SIEM-Prozess selbst gehört ebenfalls ausgeschlossen, sonst protokolliert Sysmon seine eigene Weiterleitung.
- Nach Systemklasse trennen. Eigene Konfigurationen für Domain Controller, Server und Arbeitsplätze, weil ein DC anderen Verkehr normal findet als ein Client. Wenige, aber passende Konfigurationen statt einer für alle.
- Mit einem Test prüfen. Nach dem Ausrollen mit Atomic Red Team im Homelab die wichtigen Techniken ausführen und prüfen, ob die erwarteten Sysmon-Events wirklich ankommen. Eine Konfiguration, die nie gegen einen echten Test lief, ist eine Vermutung.
- Versionieren und pflegen. Die Konfiguration wie Code in einem Repository halten, Änderungen dokumentieren und bei jeder neuen Sysmon-Version die Referenz auf neue Features prüfen. Das ist dieselbe Disziplin wie beim Detection Engineering.
Sysmon vor Manipulation schützen
Ein Angreifer mit Adminrechten kann versuchen, Sysmon zu deinstallieren, die Konfiguration zu ändern oder den Dienst zu stoppen. Zwei Dinge helfen: Erstens lässt sich Sysmon so einrichten, dass Änderungen an seiner eigenen Konfiguration und seinem Dienst protokolliert werden, sodass die Manipulation selbst eine Spur hinterlässt. Zweitens gehören die Sysmon-Logs, wie alle Logs, sofort an einen zentralen, geschützten Ort weitergeleitet, wie im Beitrag zu Log-Management und Aufbewahrung beschrieben: Was schon im SIEM liegt, bevor der Angreifer aufräumt, ist gerettet. Das Abschalten der Protokollierung ist selbst ein Alarm wert.
Fazit
Eine gute Sysmon-Konfiguration ist der Unterschied zwischen einem Werkzeug, das das SIEM flutet, und einem, das den Angreifer zeigt. Der Schlüssel ist die Filterlogik über Ausschlüsse, der Start mit einer gepflegten Referenzkonfiguration, das Tuning gegen die eigenen lauten Prozesse und die Trennung nach Systemklasse. Wer die wichtigen Event-Typen kennt, mit einer Referenz anfängt, auf einer Testgruppe tunt und die Konfiguration wie Code pflegt, hat die beste kostenlose Endpunkt-Telemetrie, die Windows bietet. Das Gegenstück für Linux behandelt der Beitrag zum Linux-Sicherheitsmonitoring. Für ein Blue Team ist die Sysmon-Konfiguration eine der lohnendsten Investitionen überhaupt, weil fast jede Erkennung in der Serie Angriff erkennen auf den Daten aufbaut, die sie liefert.