Verdächtige Aktivitäten aufzeichnen mit Sysmon und auswerten mit PowerShell

Zu den SysInternals gehört Sysmon, das zahl­reiche Aktivi­täten des Betriebs­systems über­wacht. Daraus können sich Hin­weise auf Schad­code oder Angriffe ergeben. Die Heraus­forderung besteht darin, die rele­vanten Daten aus der Viel­zahl von Log-Einträgen zu filtern.

Die Inbetrieb­nahme von Sysmon ist recht einfach. Das Tool muss von einem User mit admini­strativen 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 Konfigurations­datei ü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 Daten­menge die entscheidenden Hinweise zu extrahieren.

Neben den erwähnten Schaltern -l und -m, die keine wirkliche Fein­abstimmung erlauben, kann man eine Konfigurations­datei verwenden, um das Monitoring im Detail anzupassen. Eine solche fehlt jedoch im Liefer­umfang 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 Beispiel­konfiguration, die viele unverdächtige System­ereignisse ausschließt und so das produzierte Daten­volumen 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 Netzwerk­aktivitä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 Konfigurations­datei 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\Current­ControlSet\Services\Sysmon­Drv\Parameters. Im GPO-Editor wählt man aus dem Kontext­menü 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 zusammen­fü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 benutzer­definierte 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 Konfigurations­datei weiterhin viele Einträge erzeugt, die keine Bedeutung bei der Erkennung von Bedrohungen haben und nur gewöhnliche System­aktivitä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 beispiel­sweise 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.