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

    SysInternals SysmonZu 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.

    Die Muster-Konfiguration für Symon schließt bereits viele unverdächtige Aktivitäten aus.

    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.

    Neuen GPO-Eintrag für Registry-Schlüssel mit Hilfe des Assistenten erstellen.

    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.

    Schlüssel für Sysmon auswählen und deren Wert übernehmen

    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.

    Log-Weiterleitung für Sysmon-Events einrichten

    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.

    Eine benutzerdefinierte Ansicht für Sysmon in der Ereignisanzeige enthält auch alle unverdächtigen Events.

    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\\)'

    Filtern von Sysmon-Logs mit Hilfe des PowerShell-Cmdlets Get-WinEvent

    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.

    1 Kommentar

    Alexej Kucher sagt:
    15. Dezember 2017 - 10:18

    Eine weitere ausführliche XML zum Konfigurieren von sysmon stammt von SwiftOnSecurity. Zu finden unter https://github.com/SwiftOnSecurity/sysmon-config