Sysmon im großen Maßstab verteilen und optimieren

Die Baseline für Überwachungsrichtlinie und Sysmon erklärt, was Sysmon aufzeichnet und warum Sie es wollen. Die Installation auf einem Rechner dauert eine Minute. Es auf Tausenden Rechnern zu betreiben, mit einer Konfiguration, die Angriffe findet, ohne Ihr SIEM zu begraben, ist eine andere Aufgabe. Um genau diese geht es hier: eine Konfiguration wählen, sie datengestützt optimieren, im großen Maßstab verteilen und aktualisieren und sicherstellen, dass Sie bemerken, wenn sie nicht mehr funktioniert.

Vorab: eigenständig oder integriert

Sysmon ist inzwischen auch als optionales Feature in Windows 11 und Windows Server 2025 integriert, standardmäßig deaktiviert. Unter Windows 11 24H2 und 25H2 kam es mit dem Vorschau-Update vom 24. Februar 2026 (KB5077241) und den nachfolgenden kumulativen Updates. Sie aktivieren es mit Enable-WindowsOptionalFeature -Online -FeatureName Sysmon (oder Dism /Online /Enable-Feature /FeatureName:Sysmon) und führen dann sysmon -i mit Ihrer Konfiguration aus. Es verwendet dasselbe XML-Konfigurationsformat, schreibt in denselben Sysmon-Operational-Kanal, und Windows Update wartet die Binärdateien. Drei praktische Punkte:

• Eigenständiges Sysmon und das integrierte Feature können nicht auf demselben Host laufen. Deinstallieren Sie die Sysinternals-Version, bevor Sie die integrierte aktivieren.
• Die integrierte Version lokalisiert den gerenderten Ereignistext. Werten Sie die XML-Felder des Ereignisses aus, nicht den Nachrichtentext, sonst bricht Ihre Pipeline auf nicht-englischen Systemen.
• Alles Folgende zu Konfiguration, Optimierung und Überwachung gilt für beide.

Schritt 1: eine Konfigurationsstrategie wählen

Die meisten Teams forken sysmon-modular oder SwiftOnSecurity in ein eigenes Repository, behalten das Upstream-Projekt als Remote und legen lokale Änderungen als dünne Schicht darüber. Ist Defender for Endpoint im Einsatz, vermeidet die MDE-ergänzende Variante von sysmon-modular, dass Sie erfassen, was MDE bereits gut aufzeichnet. Wie sich MDE neben anderen Werkzeugen einfügt, beschreibt EDR im Blockmodus und passiven Modus.

Pflegen Sie eine Basiskonfiguration und ergänzen Sie rollenspezifische Overlays: Arbeitsplätze, Mitgliedsserver, Domänencontroller und aus dem Internet erreichbare Server verhalten sich unterschiedlich. Ein Domänencontroller sollte niemals einen Browser starten; ein Entwickler-Laptop startet den ganzen Tag Compiler.

Typische Änderungen durch die Overlays:

• Arbeitsplätze: Prozesserstellungs-, Netzwerk- und DNS-Ereignisse breit erfassen; Rauschen von Browsern und Kollaborations-Apps präzise ausschließen.
• Domänencontroller: Prozesszugriffe auf lsass.exe detailliert erfassen, Netzwerkereignisse für ungewöhnliche Prozesse behalten und den umfangreichen, aber erwarteten LDAP- und Replikationsverkehr von Systemprozessen ausschließen.
• Web- und Anwendungsserver: jeden Kindprozess des Webserver- oder Datenbankdienstes protokollieren, da diese fast nie legitim Shells starten.
• Jump-Server und PAWs: ausführlicher als überall sonst, denn ihre Aktivität ist per Definition Administratoraktivität und eine Prüfung wert.

Prüfen Sie, dass die schemaversion in der Datei zu dem passt, was Ihre Binärdatei unterstützt:

Sysmon64.exe -s | Select-Object -First 5   # gibt das von dieser Binärdatei unterstützte Schema aus

Schritt 2: die Regel-Engine verstehen, bevor Sie optimieren

Fehler bei der Optimierung entstehen meist, weil die Regelauswertung von Sysmon falsch verstanden wird:

• Jeder Ereignistyp hat einen Filter onmatch="include" oder onmatch="exclude". Ein Ereignistyp mit leerem Include-Filter protokolliert nichts; einer mit leerem Exclude-Filter protokolliert alles.
• Innerhalb einer RuleGroup bedeutet groupRelation="or", dass eine beliebige Bedingung zutrifft; groupRelation="and" bedeutet, dass alle zutreffen müssen. Verwenden Sie and-Gruppen, um Ausschlüsse präzise zu machen.
• Benennen Sie Ihre Regeln. Das Attribut name erscheint im Ereignis als RuleName; daran sehen Analysten, warum etwas protokolliert wurde (zum Beispiel eine Technik-ID).

Ein präziser Ausschluss sieht so aus:

<RuleGroup name="Exclude agent update checks" groupRelation="and">
  <NetworkConnect onmatch="exclude">
    <Image condition="is">C:\Program Files\Contoso Agent\agent.exe</Image>
    <DestinationPort condition="is">443</DestinationPort>
  </NetworkConnect>
</RuleGroup>

Und ein gezielter Einschluss für Diebstahl von Anmeldedaten:

<RuleGroup name="" groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage name="technique_id=T1003.001,technique_name=LSASS Memory" condition="is">C:\Windows\system32\lsass.exe</TargetImage>
  </ProcessAccess>
</RuleGroup>

Kombinieren Sie diese LSASS-Regel mit LSA-Schutz und Credential Guard: Die Konfiguration meldet Ihnen den Versuch, der Schutz lässt ihn scheitern.

Schritt 3: messen, dann Rauschen reduzieren

Pilotieren Sie eine Woche lang auf 20 bis 50 Rechnern pro Rolle, mit einem Sysmon-Log, das deutlich über den kleinen Standardwert vergrößert wurde:

wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:1073741824   # 1 GB

Finden Sie dann heraus, woher das Volumen kommt:

$ev = Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 50000

# Volumen pro Ereignis-ID
$ev | Group-Object Id | Sort-Object Count -Descending | Select-Object Count, Name

# Top-Prozesse bei Netzwerkverbindungen (Ereignis 3)
$ev | Where-Object Id -eq 3 | ForEach-Object {
  ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'Image' | ForEach-Object '#text'
} | Group-Object | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

Machen Sie dasselbe in Ihrem SIEM über den gesamten Pilot. Die üblichen Hauptverursacher sind die Ereignisse 3 (Netzwerk), 7 (Image geladen), 10 (Prozesszugriff), 11 (Datei erstellt), 12/13 (Registrierung) und 22 (DNS), getrieben von Browsern, Sicherheitsagenten, Backup-Software und Updatern.

Regeln, um Rauschen sicher zu reduzieren:

1. Nach vollständigem Pfad ausschließen, nie nach Namen. Image end with chrome.exe schließt jede Datei aus, die ein Angreifer chrome.exe nennt. Image is C:\Program Files\Google\Chrome\Application\chrome.exe tut das nicht.
2. Niemals für Benutzer beschreibbare Orte ausschließen wie C:\Users\, C:\ProgramData\ oder %TEMP%. Genau dort legen Angreifer ihre Werkzeuge ab.
3. Felder kombinieren. Schließen Sie einen Prozess und einen Zielport aus, oder beim Prozesszugriff eine Quelle und ein Ziel-Image, nicht nur den Prozess.
4. Bei Image-Loads Signaturen bevorzugen. Ereignis 7 enthält Signed und Signature; wer von Microsoft signierte DLLs aus von Microsoft signierten Prozessen ausschließt, entfernt den Großteil des Volumens.
5. Der Sicherheitswert hat Vorrang. Bevor Sie einen Ereignistyp entfernen, notieren Sie, welche Erkennung davon abhängt. Die Sysmon-Ereignisse 1, 3, 10, 11, 13 und 22 speisen die meisten Erkennungsregeln.
6. Dateilöschungen im Blick behalten. FileDelete (Ereignis 23) mit einem Archivverzeichnis kopiert jede gelöschte Datei und kann Datenträger füllen. FileDeleteDetected (Ereignis 26) protokolliert ohne Archivierung und reicht meist aus.

Schritt 4: im großen Maßstab verteilen und aktualisieren

Sysmon installiert einen Treiber und einen Dienst und kopiert sich nach %windir%. Verteilen Sie es über das Werkzeug, dem Sie bei Software bereits vertrauen: Configuration Manager, eine Intune-Win32-App oder eine per GPO gestartete geplante Aufgabe. Die Logik ist immer dieselbe: installieren, falls es fehlt, aktualisieren, wenn sich die Binärdatei geändert hat, Konfiguration neu laden, wenn sich die Datei geändert hat.

$pkg    = 'C:\ProgramData\CorpSysmon'
$binary = Join-Path $pkg 'Sysmon64.exe'
$config = Join-Path $pkg 'sysmonconfig.xml'
$marker = Join-Path $pkg 'applied.sha256'

if (-not (Get-Service -Name Sysmon64 -ErrorAction SilentlyContinue)) {
    & $binary -accepteula -i $config
} elseif ((Get-Item "$env:windir\Sysmon64.exe").VersionInfo.FileVersion -ne
          (Get-Item $binary).VersionInfo.FileVersion) {
    & "$env:windir\Sysmon64.exe" -u force
    & $binary -accepteula -i $config
}

$hash = (Get-FileHash $config).Hash
if (-not (Test-Path $marker) -or (Get-Content $marker) -ne $hash) {
    & $binary -c $config
    Set-Content -Path $marker -Value $hash
}

Konfigurationsänderungen mit -c greifen ohne Neustart und ohne Lücke. Binär-Upgrades per Deinstallation und Neuinstallation hinterlassen eine kurze Überwachungslücke; prüfen Sie in den Versionshinweisen jeder Version den unterstützten Upgrade-Pfad und planen Sie Upgrades, statt sie zufällig geschehen zu lassen.

Release-Prozess:

• Konfiguration in der Versionsverwaltung, geprüft wie Firewallregeln.
• XML vor dem Release auf einem Testrechner mit -c validieren; eine fehlerhafte Datei wird abgelehnt und die alte Konfiguration bleibt aktiv, was verschleiern kann, dass Ihre Änderung nie angekommen ist.
• Rollout in Ringen: Pilot, dann 10 %, dann alle, mit Blick auf das Ereignisvolumen bei jedem Schritt.
• Legen Sie die Konfiguration nicht auf eine Freigabe, die jeder Benutzer lesen kann. Sie verrät Angreifern genau, was Sie nicht protokollieren.

Der Schalter -d installiert den Treiber unter einem anderen Namen, und das Umbenennen der ausführbaren Datei ändert den Dienstnamen. Damit verstecken Sie Sysmon nur vor den bequemsten Skripten; das ist keine Schutzmaßnahme und erschwert Ihre eigenen Zustandsprüfungen.

Was kaputtgeht

• SIEM-Ingestion-Kosten steigen sprunghaft, wenn die erste Konfiguration zu ausführlich ist. Immer erst pilotieren, dann flächendeckend ausrollen.
• Leistungsprobleme sind selten, aber real bei breiten Image-Load- oder Registrierungs-Einschlüssen auf stark ausgelasteten Servern wie Exchange, SQL oder Dateiservern.
• Koexistenz: Einige Sicherheitsprodukte überwachen dieselben Kernel-Callbacks. Testen Sie mit Ihren EDR- und Backup-Agenten.
• Veraltete Konfigurationen: Hosts, die ein Update verpasst haben, laufen stillschweigend mit alten Regeln weiter, sofern Sie das nicht prüfen.

Schritt 5: Sysmon selbst überwachen

Ein Sysmon, das vor zwei Wochen stehen geblieben ist, sieht genauso aus wie ein ruhiger Host. Erkennen Sie:

• Sysmon-Ereignis 4 (Dienststatus geändert), 16 (Konfiguration geändert) und 255 (Fehler).
• Dienststopps im System-Log vom Dienststeuerungs-Manager.
• Hosts ohne Sysmon-Ereignisse in den letzten Stunden, die aber weiterhin andere Logs senden.
• Konfigurationsdrift: Nehmen Sie den Hash der Konfiguration in Ihr Inventar auf und vergleichen Sie ihn über die gesamte Flotte.

Überprüfung

Prüfen Sie auf einem Testhost die laufende Konfiguration und lösen Sie bekannte Ereignisse aus:

Sysmon64.exe -c                                   # zeigt die aktive Konfiguration und ihren Hash
Resolve-DnsName example.com                       # Ereignis 22 erwartet
Test-NetConnection example.com -Port 443          # Ereignis 3 erwartet, sofern nicht ausgeschlossen

Bestätigen Sie, dass diese Ereignisse mit dem richtigen RuleName im SIEM ankommen, geliefert über Windows Event Forwarding oder Ihren Agent. Führen Sie denselben Test dann durch Ihre Erkennungsregeln, zum Beispiel die Regel für nicht verwaltetes PowerShell aus Bösartiges PowerShell erkennen. Die Ereignis-IDs, die Windows ohne Sysmon protokolliert, finden Sie in der Referenz der Sicherheitsereignis-IDs; mehr zu Sysmon und Protokollierung auf der Themenseite Überwachung und Protokollierung.

Checkliste

• Eigenständiges oder integriertes Sysmon pro OS-Build entschieden
• Konfiguration von einem gepflegten Projekt geforkt, in der Versionsverwaltung, mit rollenspezifischen Overlays
• Pilot vor dem flächendeckenden Rollout pro Ereignis-ID und pro Prozess gemessen
• Ausschlüsse nutzen vollständige Pfade und kombinierte Felder; keine für Benutzer beschreibbaren Ordner
• Sysmon-Log für lokale Pufferung dimensioniert; Ereignisse weitergeleitet
• Automatisierte Installation, Aktualisierung und Konfigurationsneuladen mit Rollout in Ringen
• Zustand von Sysmon (4, 16, 255, Dienststopps, stille Hosts, Konfigurations-Hash) überwacht
• Optimierung vierteljährlich gegen die Erkennungsregeln geprüft