Sysmon ist das kostenlose Werkzeug, mit dem ein Windows-System die Telemetrie liefert, die Windows selbst nicht schreibt: welcher Prozess welche Netzwerkverbindung aufgebaut hat, wer auf den Speicher des LSASS-Prozesses zugreift, welche DNS-Namen ein Programm auflöst, welcher Treiber geladen wurde. Ein Systemdienst mit Treiber, entwickelt von Mark Russinovich und Thomas Garnier bei Microsoft, seit Jahren der Standard für Endpunkt-Sichtbarkeit ohne EDR-Lizenz. Die Installation dauert fünf Minuten. Die Konfiguration entscheidet darüber, ob du danach eine Erkennungsquelle hast oder eine Festplatte voller Rauschen. Dieser Beitrag erklärt beides.
Was Sysmon ist und was es liefert
Sysmon gehört zur Sysinternals-Suite, läuft als geschützter Prozess und schreibt seine Ereignisse in ein eigenes Log, Microsoft-Windows-Sysmon/Operational. Es analysiert nichts, alarmiert nichts und versteckt sich nicht; es liefert Ereignisse, die ein SIEM oder ein Analyst auswertet. Bei Erscheinen dieses Beitrags steht Version 15 mit Unterversionen im Bereich 15.2x bereit, dazu eine Linux-Variante. Was Sysmon aufzeichnet, steuert eine XML-Konfiguration, und ohne sie protokolliert es nur einen kleinen Standardsatz.
Die Sysmon-Event-IDs
| Event-ID | Ereignis | Wofür du es brauchst |
|---|---|---|
| 1 | Prozess erstellt | Befehlszeile, Elternprozess, Hashes, Signatur, Benutzer. Die wichtigste einzelne Quelle. |
| 3 | Netzwerkverbindung | Welcher Prozess spricht mit welcher Adresse und welchem Port. |
| 5 | Prozess beendet | Laufzeit von Prozessen, Korrelation mit Event 1. |
| 6 | Treiber geladen | Unsignierte oder bekannte verwundbare Treiber, die Angreifer für Bring-Your-Own-Vulnerable-Driver einsetzen. |
| 7 | Bibliothek geladen | DLL-Sideloading, ungewöhnliche Module in vertrauten Prozessen. Sehr laut, nur gezielt filtern. |
| 8 | Thread in fremdem Prozess erstellt | Code-Injection, ein Klassiker der Schadsoftware. |
| 10 | Prozesszugriff | Zugriff auf lsass.exe mit Leserechten: das Auslesen von Zugangsdaten. |
| 11 | Datei erstellt | Ausführbare Dateien und Skripte in Temp- und Benutzerverzeichnissen. |
| 12, 13, 14 | Registry-Objekt erstellt, Wert gesetzt, umbenannt | Autostart-Schlüssel, Dienste, Winlogon-Einträge: Persistenz. |
| 15 | Datenstrom erstellt | Downloads mit Zone-Identifier, Dateien mit alternativen Datenströmen. |
| 17, 18 | Named Pipe erstellt, verbunden | Typische Pipe-Namen von C2-Frameworks und seitlicher Bewegung. |
| 19, 20, 21 | WMI-Filter, -Consumer, -Bindung | WMI-Persistenz, selten und fast immer relevant. |
| 22 | DNS-Anfrage | Welcher Prozess welchen Namen auflöst. |
| 23, 26 | Datei gelöscht (archiviert), gelöscht (protokolliert) | Werkzeuge, die sich nach Gebrauch selbst löschen; auf Wunsch Kopie der Datei. |
| 25 | Process Tampering | Process Hollowing und verwandte Techniken, bei denen das Abbild im Speicher nicht zur Datei passt. |
| 27, 28 | Ausführbare Datei blockiert, Shredding blockiert | Die einzige präventive Funktion: Ausführbare Dateien in bestimmten Pfaden gar nicht erst schreiben lassen. |
| 29 | Ausführbare Datei erkannt | Neu erstellte Executables, auch ohne Blockierung. |
Die wichtigsten dieser Events erklärt das Event-ID-Lexikon im Kanal Sysmon einzeln, mit allen Feldern, Detection-Hinweisen, Fehlalarmen und einer Sigma-Regel. Ein Klick auf die ID in der Tabelle führt direkt zum Eintrag.
Installation in fünf Minuten
Archiv herunterladen, entpacken, in einer administrativen Eingabeaufforderung mit der Konfigurationsdatei installieren: sysmon64.exe -accepteula -i sysmonconfig.xml. Danach existiert der Dienst, der Treiber ist geladen und das Log füllt sich. Eine geänderte Konfiguration wird mit sysmon64.exe -c sysmonconfig.xml im laufenden Betrieb übernommen, -c ohne Datei zeigt die aktive Konfiguration, -u deinstalliert. In der Fläche verteilst du Sysmon per Gruppenrichtlinie als Startskript, per Intune oder über die vorhandene Softwareverteilung; entscheidend ist, dass die Konfiguration zentral liegt und Änderungen an einer Stelle passieren.
Die Konfiguration entscheidet
Die Konfiguration ist eine XML-Datei mit Filtern pro Ereignistyp. Zwei Prinzipien stehen zur Wahl: onmatch="include" protokolliert nur, was den Regeln entspricht, onmatch="exclude" protokolliert alles außer dem, was die Regeln ausnehmen. Für laute Ereignisse wie Bibliotheken und Registry ist Include der einzige Weg, für Prozessstarts und Netzwerkverbindungen hat sich Exclude mit gezielten Ausnahmen bewährt, weil du sonst nur das siehst, was du vorher erwartet hast.
Diese Konfiguration schreibst du nicht von Grund auf selbst. Zwei Community-Projekte haben jahrelange Erfahrung darin gesammelt. sysmon-config von SwiftOnSecurity ist eine einzelne, ausführlich kommentierte Datei mit dem Anspruch, in den meisten Umgebungen ohne Änderung zu laufen; ideal für den Einstieg und um zu verstehen, warum welche Ausnahme existiert. sysmon-modular von Olaf Hartong zerlegt die Konfiguration in Module pro Ereignistyp und ATT&CK-Technik, aus denen ein Skript die fertige Datei baut; die Standardzusammenstellung ist umfangreicher als SwiftOnSecurity und kommentiert bei jeder Regel, welche Technik sie sichtbar macht. Für die Produktion ist sysmon-modular die bessere Basis, weil sich die Module gezielt an- und abschalten lassen.
Tuning: eine Woche Baseline, dann Ausnahmen
Nach dem Rollout auf eine Pilotgruppe läuft die Konfiguration eine Woche unverändert. Danach zeigt eine Auswertung nach Ereignistyp und Prozess, wo das Volumen herkommt: meist Backup-Agenten, Monitoring-Werkzeuge, Softwareverteilung und Browser mit ihren tausenden Netzwerkverbindungen. Diese bekommen gezielte Ausnahmen, und zwar nie allein über den Prozessnamen, weil Angreifer ihre Werkzeuge nach genau diesen Namen umbenennen. Eine Ausnahme kombiniert Pfad, Signatur oder Hash mit dem Namen. Und für PowerShell, cmd, rundll32, regsvr32, certutil und die übrigen Bordmittel, die Angreifer bevorzugen, gibt es keine Ausnahmen, egal wie laut sie sind.
Ein guter Test dafür, ob die Konfiguration stimmt, sind die Techniken aus dem Homelab: Wenn nach einem Atomic-Red-Team-Test für T1003.001 kein Event 10 mit lsass.exe als Ziel erscheint, filtert eine Regel zu viel. Wenn nach einem Tag auf einem normalen Büroarbeitsplatz mehr als ein paar zehntausend Ereignisse anfallen, filtert sie zu wenig.
Welche Ereignisse zuerst
Wer klein anfängt, nimmt sechs Ereignistypen und bekommt damit den größten Teil der Sichtbarkeit: Event 1 für Prozessstarts mit Befehlszeile und Elternprozess, Event 3 für Netzwerkverbindungen ohne Browser und Update-Dienste, Event 10 ausschließlich für Zugriffe auf lsass.exe, Event 11 für ausführbare Dateien und Skripte in Benutzer- und Temp-Verzeichnissen, Event 13 für die bekannten Autostart-Schlüssel und Event 22 für DNS-Anfragen. Events 7 und 8 kommen dazu, sobald das SIEM das Volumen trägt und jemand Zeit hat, die Treffer zu bewerten.
Sysmon ins SIEM
Das Sysmon-Log ist ein normaler Windows-Ereigniskanal und lässt sich mit jedem Agenten abholen, ob Wazuh, Winlogbeat, Splunk Universal Forwarder oder Windows Event Forwarding auf einen Sammelserver. Der Kanalname muss in der Agentenkonfiguration eingetragen sein; das ist der häufigste Grund, warum Sysmon lokal läuft und im SIEM nichts ankommt. Der Lohn ist eine Datenquelle, für die es mehr fertige Erkennungsregeln gibt als für jede andere: Ein großer Teil der Sigma-Regeln für Windows setzt Sysmon voraus, und sie lassen sich in die Regelsprache des eigenen SIEM übersetzen. Zusammen mit den Windows-Sicherheitsereignissen deckt Sysmon fast alles ab, was auf einem Endpunkt sicherheitsrelevant ist.
Grenzen und die Sicht des Angreifers
- Sysmon ist sichtbar. Dienst und Treiber lassen sich vom Angreifer erkennen, und wer den Dienst umbenennt, gewinnt wenig, weil der Treiber im System trotzdem auffällt. Angreifer mit Administratorrechten können den Treiber entladen; genau dieses Ereignis, das Beenden des Sysmon-Dienstes, gehört deshalb als Alarm ins SIEM.
- Die Konfiguration ist lesbar. Sie liegt in der Registry unter dem Treiberschlüssel. Ein Angreifer mit Zugriff sieht deine Ausnahmen und kann seine Werkzeuge so benennen, dass sie hineinfallen. Auch deshalb: keine Ausnahmen nur nach Namen.
- Keine Reaktion. Sysmon isoliert nichts und beendet nichts. Das bleibt einem EDR oder einem Menschen vorbehalten. Wer beides hat, betreibt Sysmon oft parallel, weil seine Ereignisse in Sigma-Regeln und Hunting-Abfragen die gemeinsame Sprache sind, während jedes EDR seine eigene spricht.
- Volumen. Eine unbedachte Konfiguration erzeugt auf einem Client Gigabytes pro Tag. Die Ausnahmen aus dem Tuning sind kein Komfort, sondern die Voraussetzung dafür, dass das SIEM bezahlbar bleibt.
Fazit
Sysmon ist das beste Verhältnis von Aufwand zu Sichtbarkeit, das es für Windows-Endpunkte gibt: kostenlos, in Minuten installiert, mit Community-Konfigurationen, die Jahre an Erfahrung enthalten. Der Preis ist die Pflege der Konfiguration, eine Woche Baseline und gelegentliches Nachschärfen, wenn neue Software ins Netz kommt. Wer das leistet, sieht auf jedem Endpunkt, was ein Angreifer tut, und hat damit die Grundlage für fast jede Regel, die ein Blue Team je schreiben wird.