Dieser Artikel ist der erste Teil einer Serie zur Analyse von Sysmon-Bedrohungen. Alle weiteren Teile der Serie:
Teil 1. Einführung in die Analyse von Sysmon-Protokollen (hier)
Teil 2. Nutzung von Sysmon-Ereignisdaten zur Bedrohungserkennung
Teil 3. Vertiefte Analyse von Sysmon-Bedrohungen mit Graphen
Wenn Sie im Bereich der Informationssicherheit tätig sind, müssen Sie sich oft mit laufenden Angriffen auseinandersetzen. Wenn Sie geschult sind, können Sie nach ungewöhnlichen Aktivitäten in den "rohen" unbearbeiteten Protokollen suchen – zum Beispiel ein PowerShell-Skript mit einem oder ein VBS-Skript, das sich als Word-Datei ausgibt, während Sie einfach die letzte Aktivität im Windows-Ereignisprotokoll durchsehen. Aber das ist wirklich eine große Herausforderung. Zum Glück hat Microsoft Sysmon entwickelt, das die Analyse von Angriffen erheblich erleichtert.
Möchten Sie die grundlegenden Ideen hinter den im Sysmon-Protokoll angezeigten Bedrohungen verstehen? Laden Sie unser Handbuch herunter und Sie erkennen, wie Insider unbemerkt andere Mitarbeiter beobachten können. Das Hauptproblem bei der Arbeit mit dem Windows-Ereignisprotokoll ist das Fehlen von Informationen über übergeordnete Prozesse, d.h. aus den Aufzeichnungen lässt sich die Hierarchie der Prozesse nicht nachvollziehen. In den Sysmon-Protokolleinträgen hingegen sind die ID des übergeordneten Prozesses, sein Name und die ausgeführte Befehlszeile enthalten. Danke, Microsoft.
Im ersten Teil unserer Serie betrachten wir, was mit den grundlegenden Informationen aus Sysmon gemacht werden kann. Im zweiten Teil werden wir die Informationen über übergeordnete Prozesse nutzen, um komplexere Übereinstimmungsstrukturen zu erstellen, die als Bedrohungsgraphen bekannt sind. Im dritten Teil werden wir einen einfachen Algorithmus untersuchen, der den Bedrohungsgraphen nach ungewöhnlichen Aktivitäten durchsucht, indem er das „Gewicht“ des Graphen analysiert. Am Ende erwartet Sie als Belohnung eine übersichtliche (und verständliche) probabilistische Methode zur Bedrohungserkennung.
Teil 1: Einführung in die Analyse von Sysmon-Protokollen
Wie kann man die Komplexität des Ereignisprotokolls verstehen? Am Ende – mit SIEM. Es normalisiert Ereignisse und vereinfacht die anschließende Analyse. Aber wir müssen nicht so weit gehen, zumindest nicht gleich zu Beginn. Um die Prinzipien von SIEM zu begreifen, reicht es aus, ein wunderbares kostenloses Tool wie Sysmon auszuprobieren. Damit zu arbeiten ist überraschend einfach. Gut gemacht, Microsoft!
Welche Möglichkeiten bietet Sysmon?
Kurz gesagt – nützliche und lesbare Informationen über Prozesse (siehe Bilder unten). Sie werden viele hilfreiche Details entdecken, die im Windows-Ereignisprotokoll nicht enthalten sind, aber am wichtigsten sind die folgenden Felder:
- Prozess-ID (dezimal, nicht hex!)
- ID des übergeordneten Prozesses
- Befehlszeile des Prozesses
- Befehlszeile des übergeordneten Prozesses
- Datei-Image-Hash
- Datei-Image-Namen
Sysmon wird sowohl als Gerätetreiber als auch als Dienst installiert – mehr dazu Ihr Hauptvorteil ist die Möglichkeit, Protokolle aus mehreren Quellen zu analysieren, Informationen zu korrelieren und die Ergebnisse in einem Ereignisprotokollordner auszugeben, der sich unter folgendem Pfad befindet: Microsoft -> Windows -> Sysmon -> Operational. In meinen eigenen Untersuchungen der Windows-Protokolle, die einem das Haar zu Berge stehen lassen, musste ich ständig zwischen, sagen wir, dem PowerShell-Protokollordner und dem Ordner „Sicherheit“ hin und her wechseln, während ich die Ereignisprotokolle durchblätterte, in einem heldenhaften Versuch, irgendwie die Werte zwischen ihnen in Einklang zu bringen. Das ist wahrlich keine einfache Aufgabe, und wie ich später erkannte, wäre es besser gewesen, gleich Aspirin einzupacken.
Sysmon hingegen macht einen qualitativen Schritt nach vorn, indem es nützliche (oder, wie es die Anbieter gerne nennen, effektive) Informationen bereitstellt, die helfen, die grundlegenden Prozesse zu verstehen. Zum Beispiel habe ich eine versteckte Sitzung , die die Bewegung eines cleveren Insiders innerhalb des Netzwerks simuliert, gestartet. Das werden Sie im Windows-Ereignisprotokoll sehen:
Im Windows-Protokoll ist einige Information über den Prozess sichtbar, aber diese ist wenig hilfreich. Außerdem, warum sind die Prozess-IDs in hexadezimaler Form???
Eine professionelle IT-Fachkraft, die die Grundlagen des Hackens versteht, sollte bei der Eingabeaufforderung misstrauisch werden. Die Verwendung von cmd.exe, um einen weiteren Befehl auszuführen und die Ausgabe in eine Datei mit einem ungewöhnlichen Namen umzuleiten, sieht eindeutig nach den Aktionen von Überwachungs- und Kontrollsoftware aus. : Auf diese Weise wird eine Pseudo-Shell mittels WMI-Diensten erstellt.
Lassen Sie uns nun das Äquivalent eines Sysmon-Eintrags betrachten und darauf achten, wie viele zusätzliche Informationen es uns bietet:
Sysmon-Funktionen auf einem Screenshot: detaillierte Informationen über den Prozess in lesbarer Form
Sie sehen nicht nur die Eingabeaufforderung, sondern auch den Dateinamen, den Pfad zur ausführbaren Anwendung, was Windows darüber weiß („Windows-Befehlsprozessor“), die ID des übergeordneten Prozesses, die Eingabeaufforderung des Elternteils, der die cmd-Shell gestartet hat, sowie den echten Namen der Datei des übergeordneten Prozesses. Alles an einem Ort, endlich!
Aus dem Sysmon-Log können wir mit hoher Wahrscheinlichkeit schließen, dass die verdächtige Eingabeaufforderung, die wir in den "rohen" Logs gesehen haben, nicht das Ergebnis einer normalen Mitarbeiteraktivität ist. Vielmehr wurde sie von einem C2-ähnlichen Prozess – wmiexec, wie ich bereits erwähnt habe – generiert und direkt von dem Prozess WMI-Dienst (WmiPrvSe) hervorgerufen. Nun haben wir einen Hinweis darauf, dass ein entfernter Angreifer oder Insider die Unternehmensinfrastruktur testet.
Präsentation von Get-Sysmonlogs
Es ist natürlich großartig, wenn Sysmon Protokolle an einem Ort zusammenführt. Aber es wäre wahrscheinlich noch besser, wenn wir auf individuelle Protokollfelder programmatisch zugreifen könnten – beispielsweise über PowerShell-Befehle. In diesem Fall könnte man ein kleines PowerShell-Skript schreiben, das die Suche nach potenziellen Bedrohungen automatisiert!
Ich bin nicht der Erste, der auf diese Idee kommt. Und es ist gut, dass in einigen Forum- und GitHub-Beiträgen Es wurde bereits erklärt, wie man PowerShell zur Analyse von Sysmon-Protokollen verwendet. In meinem Fall wollte ich vermeiden, separate Parsing-Skripte für jedes Sysmon-Feld zu schreiben. Daher habe ich das Prinzip des faulen Menschen angewendet und, wie ich finde, etwas Interessantes erfunden.
Der erste wichtige Punkt ist die Möglichkeit des Befehls Sysmon-Protokolle zu lesen, die gewünschten Ereignisse zu filtern und das Ergebnis in einer PS-Variable auszugeben, wie hier:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Wenn Sie die Funktionsweise des Befehls selbst überprüfen möchten, können Sie durch die Anzeige des Inhalts im ersten Element des Arrays $events, $events[0].Message, eine Reihe von Textzeilen mit einem sehr einfachen Format erhalten: der Name des Sysmon-Feldes, ein Doppelpunkt und dann der Wert.
Hurra! Ausgabe des Sysmon-Protokolls im fertigen JSON-Format
Denken Sie an dasselbe wie ich? Mit ein wenig mehr Aufwand kann die Ausgabe in eine formatierte JSON-Zeichenfolge konvertiert werden, die direkt in ein PS-Objekt mit dem leistungsstarken Befehl .
Ich werde PowerShell-Code zur Konvertierung zeigen – er ist sehr einfach – im nächsten Teil. Aber lassen Sie uns zunächst ansehen, was mein neues Team namens get-sysmonlogs, das ich als PS-Modul installiert habe, tun kann.
Anstatt tief in die Analyse von Sysmon-Logs über die unpraktische Ereignisanzeige einzutauchen, können wir mühelos inkrementelle Aktivitäten direkt aus der PowerShell-Sitzung suchen und zudem den PS-Befehl (Alias – „?“) zur Verkürzung der Ergebnisse verwenden:
Eine Liste von Cmd-Shells, die über WMI ausgeführt werden. Bedrohungsanalyse zum kleinen Preis mit unserem eigenen Befehl Get-Sysmonlogs.
Erstaunlich! Ich habe ein Sysmon-Log-Umfrage-Tool erstellt, als ob es eine Datenbank wäre. In unserem Artikel über wurde erwähnt, dass diese Funktion von dem coolen Tool ausgeführt wird, das darin beschrieben wird, auch wenn es formal über ein echtes SQL-ähnliches Interface erfolgt. Ja, EQL ist elegant, aber darauf kommen wir im dritten Teil zurück.
Sysmon und Graphanalyse
Lassen Sie uns abstrahieren und überlegen, was wir gerade erstellt haben. Im Grunde haben wir jetzt eine Windows-Ereignisdatenbank, die über PowerShell zugänglich ist. Wie ich bereits erwähnt habe, gibt es Verbindungen oder Beziehungen zwischen den Einträgen – über die ParentProcessId – wodurch wir die vollständige Prozesshierarchie erhalten können.
Wenn Sie die Serie gelesen haben wissen Sie, dass Hacker es lieben, komplexe mehrstufige Angriffe zu erstellen, bei denen jeder Prozess seine kleine Rolle spielt und den Boden für den nächsten Schritt bereitet. Solche Dinge sind äußerst schwierig einfach aus einem „rohen“ Log zu erfassen.
Aber mit meinem Team von Get-Sysmonlogs und der zusätzlichen Datenstruktur, die wir weiter unten im Text betrachten werden (das ist natürlich ein Graph), werden wir eine praktische Möglichkeit haben, Bedrohungen zu erkennen – dafür muss nur die richtige Suche an den Spitzen durchgeführt werden.
Wie immer in unseren DYI Blog-Projekten, je mehr Sie an der Analyse von Bedrohungsdetails im kleinen Maßstab arbeiten, desto besser erkennen Sie, wie komplex die Bedrohungserkennung auf Unternehmensebene ist. Und dieses Bewusstsein ist von entscheidender Bedeutung. wichtig..
Im zweiten Teil des Artikels werden wir auf die ersten interessanten Herausforderungen stoßen, wenn wir beginnen, Sysmon-Ereignisse in deutlich komplexere Strukturen zu verknüpfen.
Quelle: habr.com
