Tags: Log-Management, Sicherheit
Zu den SysInternals gehört Sysmon, das zahlreiche Aktivitäten des Betriebssystems überwacht. Daraus können sich Hinweise auf Schadcode oder Angriffe ergeben. Die Herausforderung besteht darin, die relevanten Daten aus der Vielzahl von Log-Einträgen zu filtern.
Die Inbetriebnahme von Sysmon ist recht einfach. Das Tool muss von einem User mit administrativen Rechten gestartet werden und läuft dann vollständig im Hintergrund. Beim Aufruf akzeptiert es eine Handvoll Parameter. Erforderlich ist -i (für install), dem man den Namen einen Konfigurationsdatei übergeben kann. Das Log-Verhalten lässt sich zudem über Schalter wie -l oder -m beeinflussen (sysmin -? zeigt eine Belehrung zur Syntax).
Musterkonfiguration anpassen
Die eigentliche Kunst besteht zum einen darin, das Tool so einzustellen, dass es sich auf das Logging der wichtigsten Ereignisse beschränkt. Zum anderen muss man Mechanismen entwickeln, um aus der dann immer noch erheblichen Datenmenge die entscheidenden Hinweise zu extrahieren.
Neben den erwähnten Schaltern -l und -m, die keine wirkliche Feinabstimmung erlauben, kann man eine Konfigurationsdatei verwenden, um das Monitoring im Detail anzupassen. Eine solche fehlt jedoch im Lieferumfang von Sysmon und das Anlegen einer derartigen XML-Datei ist eine der größten Hürden für den Einsatz des Tools.
Diese Lücke schließt der Microsoft-Mitarbeiter Moti Bani mit einer Beispielkonfiguration, die viele unverdächtige Systemereignisse ausschließt und so das produzierte Datenvolumen reduziert. Sie kann von Github heruntergeladen werden.
Der Autor versteht diese Datei als Muster, das durchaus noch weiter angepasst werden soll. Wenn man sysmon mit dieser Konfiguration startet, dann wird man zum Beispiel schnell feststellen, dass sich die Netzwerkaktivitäten der verschiedenen Defender-Module im Eventlog finden. Dies kann man unterbinden, indem man im Abschnitt
<NetworkConnect onmatch="exclude">
unter anderem die Zeile
<Image condition="contains">MpCmdRun.exe</Image>
einträgt. Weitere Kandidaten für Ausschlüsse wird man nach Durchsicht der Ereignisanzeige unter Anwendungs- und Dienstprotokolle => Microsoft => Windows => Sysmon => Operation bald finden.
Verteilung der Sysmon-Konfiguration im Netz
Beim Einsatz im Unternehmen stellt sich die Frage, wie man Sysmon auf einer größeren Zahl von PCs ausführen und dabei mit einer einheitlichen Konfiguration versehen kann. Das Tool kommt solchen Szenarien entgegen, indem es den Inhalt der Konfigurationsdatei nach dem Aufruf mit dem Parameter -i in der Registry speichert. Die betreffenden Einträge lassen sich dann mit Group Policy Preferences im Netzwerk verteilen.
Bei Sysmon finden sich die benötigten Werte unter HKLM\SYSTEM\CurrentControlSet\Services\SysmonDrv\Parameters. Im GPO-Editor wählt man aus dem Kontextmenü nach dem Befehl Neu am besten den Assistenten aus, weil man damit gleich alle drei Schlüssel (HashingAlgorithm, Options und Rules) auf einmal übernehmen kann.
Log-Auswertung
Neben der Verteilung der Konfiguration steht eine weitere Aufgabe an, wenn man das Tool auf mehreren PCs einsetzt. Nachdem eine Auswertung des Eventlogs auf jedem einzelnen Rechner nicht sinnvoll ist, muss man die Log-Einträge auf einer Maschine zusammenführen.
Setzt man ein SIEM-Tool ein, dann kümmert sich dieses in der Regel selbst um die Konsolidierung der Logs. Außerdem sollte es in der Lage sein, die von Sysmon protokollierten Ereignisse eigenständig zu bewerten und in seiner Analyse von Bedrohungen zu berücksichtigen.
Fehlt es an einer solchen Software, dann wird man für die Auswertung der Events auf die Bordmittel zurückgreifen. Dazu kann man zwar die Ereignisanzeige einsetzen und dort eine benutzerdefinierte Ansicht für Microsoft-Windows-Sysmon/Operational einrichten.
Der Nutzen dieser Darstellung wird in der Praxis eher gering sein, weil Sysmon trotz zahlreicher Ausschlüsse in der Konfigurationsdatei weiterhin viele Einträge erzeugt, die keine Bedeutung bei der Erkennung von Bedrohungen haben und nur gewöhnliche Systemaktivitäten betreffen.
Daher muss man bei der Auswertung nochmals filtern. Moti Bani gibt in seinem Guide für Sysmon einige Anhaltspunkte, worauf man dabei achten sollte. So ist beispielsweise das Event mit der ID 4 (Status von Sysmon geändert) nur interessant, wenn der Service gestoppt wurde. Dies könnte auf die Aktivitäten eines Angreifers hinweisen.
In PowerShell ließe sich dies so abfragen:
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational";ID=4} |
? Message -like *Stopped*
Ähnlich sieht es bei anderen Events aus, wo man vor allem auf Prozesse achten sollte, die nicht vom System selber stammen. Das gilt etwa für die Event-ID 6, die das Laden von Treibern protokolliert. Hier ist Aufmerksamkeit angebracht, wenn diese nicht aus dem Verzeichnis %SYSTEMROOT%\system32\drivers kommen:
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational";ID=6} |
? Message -NotLike *system32\drivers*
Für andere Events wiederum kann man Einträge ignorieren, wenn der Pfad für den Code nicht mit Windows oder Programme übereinstimmt. In diesem Fall macht man sich reguläre Ausdrücke zunutze, um mehrere Bedingungen abzufragen:
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational";ID=8,9} |
? Message -NotMatch '(ProgramFiles|\\Windows\\)'
Dieser Aufruf liefert nur jene Log-Einträge mit der Event-ID 8 (CreateRemoteThread) oder 9 (RawAccessRead), in deren Nachricht die Zeichenketten ProgramFiles bzw. \Windows\ nicht vorkommen.
Täglich Know-how für IT-Pros mit unserem Newsletter
Ähnliche Beiträge
- Azure Sentinel: Microsofts SIEM für On-Premises und Cloud
- Verdächtige Aktivitäten und unsichere Systeme entdecken mit EventSentry
- Deep Scriptblock Logging: PowerShell-Kommandos im Eventlog aufzeichnen
- PowerShell-Logging: Befehle in Transcript-Datei aufzeichnen
- Auditing: Administratoren im Active Directory überwachen
1 Kommentar
Eine weitere ausführliche XML zum Konfigurieren von sysmon stammt von SwiftOnSecurity. Zu finden unter https://github.com/SwiftOnSecurity/sysmon-config