Installation und Tuning von sysmon

Grundlagen

Was ist sysmon?

Bevor wir uns mit sysmon, dessen Installation, Tuning und der Verwendung auseinandersetzen, müssen wir den Bedarf dafür klärem. Und dieser ergibt sich aus der IT-Sicherheit, die aus unserem Business nicht mehr wegzudenken ist. Permanent kommen neue Bedrohungen dazu und wir versuchen als IT-ler, mit neuen Härtungsmaßnahmen gegenzusteuern. Aber die Angreifer sind uns leider einen Schritt voraus. Und so müssen wir uns mit dem Gedanken anfreunden: es ist nur eine Frage der Zeit, bis die eigene Infrastruktur angegriffen wird! (Beispiele zeige ich in meinen Beiträgen Forensik einer Trojanerinfektion und Eine wahre Bruteforce-Geschichte.)

Wenn es zu diesem Extrem kommt, dann muss neben der klassischen Härtung und der moderneren Isolation die dritte Säule in der IT-Sicherheit greifen: Detection & Response! Wir müssen feststellen, dass ein Angriff stattfindet und wir müssen im Nachhinein herausfinden, welche Assets (Geräte und Benutzer) betroffen sind. Da kommt nun sysmon ins Spiel: Die kleine Erweiterung von Mark Russinovich und Thomas Garnier läuft als Service auf einem Windows System und protokolliert sicherheitsrelevante Ereignisse in einem zusätzlichen Logfile. Die Events sind deutlich aufschlussreicher als die klassischen Advanced Audit Logs vom Windows selber.

Events, die sysmon erfassen kann

Insgesamt wird sysmon 25 verschiedene Event-IDs aufzeichnen können:

Es lohnt sich also, das Config-File mal genau anzusehen. Und eventuell werden auch im laufenden Betrieb Anpassungen notwendig. Das müssen wir beim Rollout berücksichtigen.

Installieren und Aktualisieren von sysmon mit GPO

Zuerst benötige ich das Setup. Das gibt es kostenlos beim Microsoft: Sysmon – Sysinternals | Microsoft Learn. Dazu wird aber auch eine Konfigurationsdatei erforderlich. Eine sehr gute Vorlage ist diese hier: sysmon-config/sysmonconfig-export.xml at master · SwiftOnSecurity/sysmon-config · GitHub. Nicht wenige SIEM-Anbieter empfehlen diese. Es handelt sich hier um eine Textdatei, die angepasst werden kann:

Nach dem Download und dem Entpacken der zip-Datei habe ich diese Dateien:

Nun muss sysmon auf den Systemen installiert werden. Die Anweisung dafür ist recht einfach:

sysmon.exe -accepteula -i sysmon.config

Ich möchte das automatisieren. Und dazu möchte ich Änderungen an der config-File automatisch verteilen. Das schreit nach einem PowerShell-Script, dass über einen Scripttask auf allen Systemen läuft. Und der Scripttask wird über eine GPO angelegt. Das hier ist mein PowerShell-Script:

##### Scriptinfo ##################################################################################
# Scriptreihe:      sysmon-installer-updater
# Datum:            2024-01-13
# Version:          V1.00
# Programmierer:    Stephan Walther
###################################################################################################

# Variablen
    $PathAD = "\\ws.its\netlogon\sysmon"
    $Logfile = @()

# Ermittle Aktion
    Start-Transcript -Path "C:\windows\sysmon-installer-updater.log"
    $ConfigFileHashAD  = (Get-FileHash -Path "$PathAD\sysmonconfig-export.xml").hash
    $ConfigFileHashReg = (Get-ItemProperty -Path "HKLM:\SOFTWARE\ws.its\sysmon" -Name "ConfigFileHash" -ErrorAction SilentlyContinue).ConfigFileHash
    $Logfile += "Hash im AD: $ConfigFileHashAD"
    $Logfile += "Hash lokal: $ConfigFileHashReg"
    
    $action = "none"
    if (-not (Get-Service | Where-Object { $_.name -eq 'sysmon64' })) {
        $action = "installiere sysmon"
        $param = "-i"
        $exit = 1
    }
    if ($ConfigFileHashReg.length -gt 0 -and $ConfigFileHashAD -ne $ConfigFileHashReg) {
        $action = "aktualisiere sysmon-config"
        $param = "-c"
        $exit = 2
    }

# starte Aktion bei Bedarf
    New-EventLog -LogName "Application" -Source "SysmonInstaller" -ErrorAction SilentlyContinue

    if ($action -ne 'none') {
        try {
            $Logfile += "Aktion: $action"
            $Logfile += "kopiere Dateien nach lokal"
            Copy-Item -Path "$PathAD" -Destination "C:\windows\Temp" -Recurse -Force -ErrorAction stop

            $Logfile += "starte setup: C:\windows\Temp\sysmon\Sysmon64.exe -accepteula $param C:\windows\Temp\sysmon\sysmonconfig-export.xml"
            Start-Process -FilePath "C:\windows\Temp\sysmon\Sysmon64.exe" -ArgumentList "-accepteula $param C:\windows\Temp\sysmon\sysmonconfig-export.xml" -ErrorAction stop

            Start-Sleep -Seconds 5

            $ConfigFileHashReg = $ConfigFileHashAD

            $Logfile += "schreibe neuen Config-Hash in die Registry"
            New-Item -Path "HKLM:\SOFTWARE\ws.its" -Force | Out-Null
            New-Item -Path "HKLM:\SOFTWARE\ws.its\sysmon" -Force | Out-Null
            Set-ItemProperty -Path "HKLM:\SOFTWARE\ws.its\sysmon" -Name ConfigFileHash -Value $ConfigFileHashReg

            $Logfile += "entferne Arbeitsverzeichnis C:\windows\Temp\sysmon"
            Remove-Item -Path "C:\windows\Temp\sysmon" -Recurse -Force

            $Logfile += "erfolgreich abgeschlossen"
            Write-EventLog -LogName "Application" -Source "SysmonInstaller" -EntryType Information -EventId 2 -Message "$( $Logfile -join "`r`n" )"            
        }
        catch {
            $Logfile += "Fehler in Zeile $( $error[0].InvocationInfo.ScriptLineNumber ): $( $error[0].Exception.Message )"
            Write-EventLog -LogName "Application" -Source "SysmonInstaller" -EntryType Error -EventId 3 -Message "$( $Logfile -join "`r`n" )"
        }
    } else {
        $Logfile += "keine Aktion erforderlich"
        Write-EventLog -LogName "Application" -Source "SysmonInstaller" -EntryType Information -EventId 1 -Message "$( $Logfile -join "`r`n" )"
    }

Den Code speichere ich in eine Scriptdatei, die ich zusammen mit der Setup-Datei und der Config-Datei im Netlogon ablege:

Jetzt fehlt noch der Scripttask in der GPO. Ich habe bereits eine GPO für die Audit-Konfiguration, die auf alle Systeme angewendet wird. Da erstelle ich nun einen neuen Eintrag für eine geplante Aufgabe:

Nun teste ich die neue Richtlinienanpassung auf einem meiner Server. Ich starte eine Gruppenrichtlinienaktualisierung und die Aufgabe wird wie gewünscht angelegt:

Danach starte ich die Aufgabe manuell und ein neuer Service sysmon wird bereitgestellt:

Und dieser zeichnet nun wie gewünscht die Events auf, die mit der config-Datei angegeben wurden:

Die Installationsautomatik funktioniert. 🙂 Bei jedem Scriptlauf wird im Anwendungs-Eventlog ein Eintrag auf dem Computer vorgenommen. So kann die Funktionsweise geprüft werden:

Tuning vom sysmon

Jetzt brauche ich noch etwas Feintuning. Wie bereits angegeben sind viele DNS QUERY Records dabei. Natürlich auch die für meine interne Domain. Die interessieren mich aber nicht. Ich hab das mal mit wenigen Zeilen PowerShell analysiert:

Man erkennt deutlich die Anzahl der Events 22 (DNS QUERY) und bei diesen überwiegen meine eigenen Domains! Das kann mit der Config-File angepasst werden. Ebenso schließe ich Namen aus, die mit meinem internen Namenspräfix ws- beginnen:

Ich speichere die Änderung in der Datei im Netlogon und starte die Aufgabe auf meinem Testrechner neu. Nun sollte das Update ausgeführt werden und das sollte auch im sysmon-Evenlog aufgezeichnet werden:

Nach einem Tag kontrolliere ich. wie sich das Volumen der DNS-QUERY-Records verändert. Das sieht schon deutlich besser aus:

Und ich komme nun schon wenige Stunden im Eventlog zurück:

Nach dieser Vorgehensweise sollte sysmon die nächsten Tage nach der Installation getunt werden. Niemand benötigt sinnfreie Logs. Achtet aber auch darauf, dass relevante Logs nicht unterdrückt werden. Fehlende Logs sind noch schlechter!

Umleitung der Eventlogs mit Windows Eventlog Forwarding

Ich habe bereits eine vollständige Windows Eventlog Forwarding Konfiguration. Mit WEF kann ich Events in einem Zielsystem sammeln. Wie das geht, zeige ich euch hier: https://www.ws-its.de/windows-eventlog-forwarding-einrichten/

Für sysmon muss ich nur noch das Abonnement anpassen:

Nach der Erstellung ziehen sich die ersten Systeme die neue Definition:

Nun sammle ich deren syslog-Events in dem einen Eventlog auf meinem Monitoring-System. Da in diesem Eventlog aber auch noch andere Events gespeichert werden, macht der Aufbau einer View Sinn:

Die Daten der anderen Server liegen im Eventlog “weitergeleitete Ereignisse”:

Nun muss ich mir ein Suchkriterium einbauen, dass es so aber nicht im grafischen Editor gibt. Also editiere ich die XML-Suchabfrage:

Die View wird gespeichert:

In der Ergebnisanzeige fehlt nun noch der Computername, von welchem die Infos stammen:

Und hier ist das Ergebnis:

Zusammenfassung

Damit habe ich eine vollautomatische Installation mit Aktualisierungsfunktion für sysmon geschaffen und die erste Optimierung der syslog-Events vorgenommen. Ebenso werden die Logs zentral mittels Eventlog Forwarding gesammelt und können durch eine View bequem durchsucht werden. 🙂

Ich habe euch einige Dateien zum Download zusammengestellt:

• Das PowerShell-Setup-Script
• Eine exportierte GPO mit der geplanten Aufgabe
• Das PowerShell-Script zur Analyse der sysmon-Eventlogs auf einem Server
• Die exportierte View für die Ereignisanzeige

Stay tuned!