Leitfaden zur Sysmon-Bedrohungsanalyse, Teil 1

Dieser Artikel ist der erste Teil einer Serie zur Sysmon-Bedrohungsanalyse. Alle anderen Teile der Serie:

Teil 1: Einführung in die Sysmon-Protokollanalyse (wir sind hier)
Teil 2: Verwenden von Sysmon-Ereignisdaten zur Identifizierung von Bedrohungen
Teil 3. Detaillierte Analyse von Sysmon-Bedrohungen mithilfe von Diagrammen

Wenn Sie im Bereich Informationssicherheit arbeiten, müssen Sie wahrscheinlich häufig laufende Angriffe verstehen. Wenn Sie bereits über ein geschultes Auge verfügen, können Sie in den „rohen“ unverarbeiteten Protokollen nach nicht standardmäßigen Aktivitäten suchen – beispielsweise nach einem laufenden PowerShell-Skript mit dem DownloadString-Befehl oder ein VBS-Skript, das vorgibt, eine Word-Datei zu sein – einfach durch die neueste Aktivität im Windows-Ereignisprotokoll scrollen. Aber das bereitet wirklich große Kopfschmerzen. Glücklicherweise hat Microsoft Sysmon entwickelt, das die Angriffsanalyse erheblich vereinfacht.

Möchten Sie die Grundideen hinter den im Sysmon-Protokoll angezeigten Bedrohungen verstehen? Laden Sie unseren Leitfaden herunter WMI-Ereignisse als Spionagemittel und Sie erkennen, wie Insider andere Mitarbeiter heimlich beobachten können. Das Hauptproblem bei der Arbeit mit dem Windows-Ereignisprotokoll ist der Mangel an Informationen über übergeordnete Prozesse, d. h. Es ist unmöglich, daraus die Hierarchie der Prozesse zu verstehen. Sysmon-Protokolleinträge enthalten hingegen die ID des übergeordneten Prozesses, seinen Namen und die zu startende Befehlszeile. Vielen Dank, Microsoft.

Im ersten Teil unserer Serie schauen wir uns an, was Sie mit Basisinformationen von Sysmon machen können. In Teil XNUMX werden wir die Informationen des übergeordneten Prozesses voll ausnutzen, um komplexere Compliance-Strukturen zu erstellen, die als Bedrohungsdiagramme bezeichnet werden. Im dritten Teil betrachten wir einen einfachen Algorithmus, der ein Bedrohungsdiagramm durchsucht, um nach ungewöhnlichen Aktivitäten zu suchen, indem er das „Gewicht“ des Diagramms analysiert. Und am Ende werden Sie mit einer sauberen (und verständlichen) probabilistischen Methode zur Bedrohungserkennung belohnt.

Teil 1: Einführung in die Sysmon-Protokollanalyse

Was kann Ihnen helfen, die Komplexität des Ereignisprotokolls zu verstehen? Letztendlich - SIEM. Es normalisiert Ereignisse und vereinfacht deren anschließende Analyse. Aber so weit müssen wir nicht gehen, zumindest zunächst nicht. Um die Prinzipien von SIEM zu verstehen, reicht es zunächst aus, das wunderbare kostenlose Dienstprogramm Sysmon auszuprobieren. Und es ist überraschend einfach, mit ihr zu arbeiten. Weiter so, Microsoft!

Welche Funktionen bietet Sysmon?

Kurz gesagt – nützliche und lesbare Informationen zu den Prozessen (siehe Bilder unten). Sie finden eine Reihe nützlicher Details, die nicht im Windows-Ereignisprotokoll enthalten sind. Die wichtigsten sind jedoch die folgenden Felder:

• Prozess-ID (dezimal, nicht hexadezimal!)
• ID des übergeordneten Prozesses
• Befehlszeile verarbeiten
• Befehlszeile des übergeordneten Prozesses
• Dateibild-Hash
• Dateibildnamen

Sysmon wird sowohl als Gerätetreiber als auch als Dienst installiert – weitere Details hier. Sein Hauptvorteil ist die Möglichkeit, Protokolle zu analysieren mehrere Quellen, Korrelation von Informationen und Ausgabe der resultierenden Werte in einen Ereignisprotokollordner, der sich entlang des Pfads befindet Microsoft -> Windows -> Sysmon -> Betriebsbereit. Bei meinen eigenen haarsträubenden Untersuchungen zu Windows-Protokollen musste ich ständig beispielsweise zwischen dem PowerShell-Protokollordner und dem Sicherheitsordner wechseln und die Ereignisprotokolle durchblättern, in einem tapferen Versuch, die Werte zwischen den beiden irgendwie in Beziehung zu setzen . Das ist nie eine leichte Aufgabe, und wie mir später klar wurde, war es besser, sich sofort mit Aspirin einzudecken.

Sysmon macht einen Quantensprung nach vorne, indem es nützliche (oder wie Anbieter gerne sagen: umsetzbare) Informationen bereitstellt, die dabei helfen, die zugrunde liegenden Prozesse zu verstehen. Ich habe zum Beispiel eine geheime Sitzung gestartet wmiexec, wodurch die Bewegung eines intelligenten Insiders innerhalb des Netzwerks simuliert wird. Folgendes sehen Sie im Windows-Ereignisprotokoll:

Das Windows-Protokoll zeigt einige Informationen über den Vorgang, die jedoch von geringem Nutzen sind. Plus Prozess-IDs im Hexadezimalformat???

Für einen professionellen IT-Experten mit einem Verständnis für die Grundlagen des Hackens sollte die Befehlszeile verdächtig sein. Die Verwendung von cmd.exe, um anschließend einen anderen Befehl auszuführen und die Ausgabe in eine Datei mit einem seltsamen Namen umzuleiten, ähnelt eindeutig den Aktionen einer Überwachungs- und Steuerungssoftware Befehl und Kontrolle (C2): Auf diese Weise wird mithilfe von WMI-Diensten eine Pseudo-Shell erstellt.
Werfen wir nun einen Blick auf das Sysmon-Eintragsäquivalent und beachten wir, wie viele zusätzliche Informationen es uns liefert:

Sysmon-Funktionen in einem Screenshot: detaillierte Informationen zum Prozess in lesbarer Form

Sie sehen nicht nur die Befehlszeile, sondern auch den Dateinamen, den Pfad zur ausführbaren Anwendung, was Windows darüber weiß („Windows Command Processor“), die Kennung elterlich Prozess, Befehlszeile Elternteil, mit dem die cmd-Shell gestartet wurde, sowie der tatsächliche Dateiname des übergeordneten Prozesses. Endlich alles an einem Ort!
Aus dem Sysmon-Protokoll können wir schließen, dass diese verdächtige Befehlszeile, die wir in den „rohen“ Protokollen gesehen haben, mit hoher Wahrscheinlichkeit nicht das Ergebnis der normalen Arbeit des Mitarbeiters ist. Ganz im Gegenteil, es wurde von einem C2-ähnlichen Prozess generiert – wmiexec, wie ich bereits erwähnt habe – und wurde direkt vom WMI-Dienstprozess (WmiPrvSe) erzeugt. Jetzt haben wir einen Hinweis darauf, dass ein entfernter Angreifer oder Insider die Unternehmensinfrastruktur testet.

Einführung in Get-Sysmonlogs

Natürlich ist es großartig, wenn Sysmon die Protokolle an einem Ort ablegt. Aber es wäre wahrscheinlich noch besser, wenn wir programmgesteuert auf einzelne Protokollfelder zugreifen könnten – beispielsweise über PowerShell-Befehle. In diesem Fall könnten Sie ein kleines PowerShell-Skript schreiben, das die Suche nach potenziellen Bedrohungen automatisiert!
Ich war nicht der Erste, der eine solche Idee hatte. Und es ist gut, dass in einigen Forenbeiträgen und GitHub Projekte Es wurde bereits erläutert, wie Sie PowerShell zum Parsen des Sysmon-Protokolls verwenden. In meinem Fall wollte ich vermeiden, für jedes Sysmon-Feld separate Zeilen eines Parsing-Skripts schreiben zu müssen. Also habe ich das Lazy-Man-Prinzip angewendet und bin, glaube ich, dabei auf etwas Interessantes gekommen.
Der erste wichtige Punkt ist die Fähigkeit des Teams Get-WinEvent Lesen Sie Sysmon-Protokolle, filtern Sie die erforderlichen Ereignisse und geben Sie das Ergebnis wie hier in die PS-Variable aus:

$events = Get-WinEvent  -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}

Wenn Sie den Befehl selbst testen möchten, indem Sie den Inhalt im ersten Element des $events-Arrays, $events[0].Message, anzeigen, kann die Ausgabe eine Reihe von Textzeichenfolgen mit einem sehr einfachen Format sein: der Name des Sysmon-Feld, ein Doppelpunkt und dann der Wert selbst.

Hurra! Ausgabe des Sysmon-Protokolls in ein JSON-fähiges Format

Denkst du dasselbe wie ich? Mit etwas mehr Aufwand können Sie die Ausgabe in einen JSON-formatierten String konvertieren und ihn dann mit einem leistungsstarken Befehl direkt in ein PS-Objekt laden ConvertFrom-Json .
Den PowerShell-Code für die Konvertierung – es ist ganz einfach – zeige ich im nächsten Teil. Sehen wir uns zunächst an, was mein neuer Befehl namens get-sysmonlogs, den ich als PS-Modul installiert habe, bewirken kann.
Anstatt über eine umständliche Ereignisprotokollschnittstelle tief in die Sysmon-Protokollanalyse einzutauchen, können wir mühelos direkt in einer PowerShell-Sitzung nach inkrementellen Aktivitäten suchen und den PS-Befehl verwenden woher (Alias ​​– „?“), um die Suchergebnisse zu verkürzen:

Liste der über WMI gestarteten cmd-Shells. Kostengünstige Bedrohungsanalyse mit unserem eigenen Get-Sysmonlogs-Team

Fabelhaft! Ich habe ein Tool erstellt, um das Sysmon-Protokoll abzufragen, als wäre es eine Datenbank. In unserem Artikel über EQL Es wurde darauf hingewiesen, dass diese Funktion von dem darin beschriebenen coolen Dienstprogramm ausgeführt wird, formal jedoch immer noch über eine echte SQL-ähnliche Schnittstelle. Ja, EQL elegant, aber wir werden im dritten Teil darauf eingehen.

Sysmon- und Diagrammanalyse

Lassen Sie uns einen Schritt zurücktreten und über das nachdenken, was wir gerade geschaffen haben. Im Wesentlichen verfügen wir jetzt über eine Windows-Ereignisdatenbank, auf die über PowerShell zugegriffen werden kann. Wie ich bereits erwähnt habe, gibt es Verbindungen oder Beziehungen zwischen Datensätzen – über die ParentProcessId –, sodass eine vollständige Prozesshierarchie erhalten werden kann.

Wenn Sie die Serie gelesen haben „Die Abenteuer der schwer fassbaren Malware“ Sie wissen, dass Hacker es lieben, komplexe mehrstufige Angriffe zu erstellen, bei denen jeder Prozess seine eigene kleine Rolle spielt und ein Sprungbrett für den nächsten Schritt bereitet. Es ist äußerst schwierig, solche Dinge einfach aus dem „rohen“ Baumstamm zu fangen.
Aber mit meinem Befehl „Get-Sysmonlogs“ und einer zusätzlichen Datenstruktur, die wir später im Text betrachten werden (natürlich ein Diagramm), haben wir eine praktische Möglichkeit, Bedrohungen zu erkennen – was lediglich die richtige Vertex-Suche erfordert.
Wie immer bei unseren DYI-Blogprojekten gilt: Je mehr Sie sich mit der Analyse der Details von Bedrohungen im kleinen Maßstab befassen, desto mehr werden Sie erkennen, wie komplex die Bedrohungserkennung auf Unternehmensebene ist. Und dieses Bewusstsein ist extrem wichtiger Punkt.

Auf die ersten interessanten Komplikationen werden wir im zweiten Teil des Artikels stoßen, wo wir beginnen, Sysmon-Ereignisse miteinander zu viel komplexeren Strukturen zu verbinden.

Source: habr.com