Leitfaden zur Analyse von Sysmon-Bedrohungen, Teil 1

Leitfaden zur Analyse von Sysmon-Bedrohungen, Teil 1

Dieser Artikel ist der erste Teil einer Serie zur Analyse von Sysmon-Bedrohungen. Alle anderen Teile der Serie sind:

Teil 1. Einführung in die Analyse von Sysmon-Protokollen (wir hier)
Teil 2. Nutzung von Daten aus Sysmon-Ereignissen zur Identifizierung von Bedrohungen
Teil 3. Vertiefte Analyse von Sysmon-Bedrohungen mittels Graphen

Wenn Sie im Bereich der Informationssicherheit tätig sind, haben Sie sicherlich oft mit laufenden Angriffen zu tun. Wenn Sie geschult sind, können Sie nach untypischen Aktivitäten in „rohen“ unverarbeiteten Protokollen suchen – beispielsweise nach einem PowerShell-Skript, das die DownloadString Befehl ausführt oder einem VBS-Skript, das sich als Word-Dokument tarnt, indem Sie einfach die letzte Aktivitäten im Windows-Ereignisprotokoll durchsehen. Aber das ist wirklich eine große Herausforderung. Glücklicherweise 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 unseren Leitfaden herunter, WMI-Ereignisse als Mittel der Spionage und Sie werden erkennen, wie Insider unbemerkt andere Mitarbeiter beobachten können. Das Hauptproblem bei der Arbeit mit dem Windows-Ereignisprotokoll besteht darin, dass es keine Informationen zu den übergeordneten Prozessen gibt, das heißt, man kann die Hierarchie der Prozesse nicht erkennen. In den Sysmon-Protokolleinträgen sind jedoch im Gegensatz dazu die Prozess-ID des übergeordneten Prozesses, dessen Name und die ausgeführte Befehlszeile enthalten. Danke, Microsoft.

Im ersten Teil unserer Serie werden wir uns ansehen, was man mit den Basisinformationen aus Sysmon tun kann. Im zweiten Teil werden wir die Informationen zu übergeordneten Prozessen vollständig nutzen, um komplexere Konformitätsstrukturen zu erstellen, die als Bedrohungsgraphen bekannt sind. Im dritten Teil betrachten wir einen einfachen Algorithmus, der den Bedrohungsgraphen scannt, um untypische Aktivitäten durch die Analyse des „Gewichts“ des Graphen zu finden. Und am Ende erwartet Sie als Belohnung eine klare (und verständliche) probabilistische Methode zur Bedrohungserkennung.

Teil 1: Einführung in die Analyse von Sysmon-Protokollen

Was hilft, die Komplexitäten des Ereignisprotokolls zu verstehen? Letztendlich - SIEM. Es normalisiert Ereignisse und vereinfacht deren anschließende Analyse. Aber wir müssen nicht so weit gehen, zumindest in der ersten Zeit. Zu Beginn wird es ausreichend sein, die großartige, kostenlose Anwendung Sysmon auszuprobieren. Und es ist erstaunlich einfach, damit zu arbeiten. Weiter so, Microsoft!

Welche Möglichkeiten bietet Sysmon?

Kurz gesagt – nützliche und lesbare Informationen über Prozesse (siehe die Bilder unten). Sie werden eine Menge nützlicher Details entdecken, die im Windows-Ereignisprotokoll nicht vorhanden sind, aber das Wichtigste sind die folgenden Felder:

  • Prozess-ID (in dezimaler Form, nicht hex!)
  • ID des übergeordneten Prozesses
  • Kommandozeile des Prozesses
  • Kommandozeile des übergeordneten Prozesses
  • Dateihash
  • Dateinamen

Sysmon wird sowohl als Gerätetreiber als auch als Dienst installiert – mehr dazu hier. Ihr wesentlichster Vorteil ist die Möglichkeit, Logs aus mehreren Quellen zu analysieren, Informationen zu korrelieren und die resultierenden Werte in einen Ereignisprotokoll-Ordner auszugeben, der sich unter dem Pfad befindet Microsoft -> Windows -> Sysmon -> Operational. In meinen eigenen Ermittlungen zu Windows-Logs, die einem die Haare zu Berge stehen lassen, musste ich ständig zwischen beispielweise dem Pfad mit PowerShell-Logs und dem Ordner "Sicherheit" wechseln, während ich das Ereignisprotokoll durchblätterte in einem verzweifelten Versuch, die Werte zwischen ihnen abzugleichen. Das ist bei weitem keine leichte Aufgabe, und wie ich später verstand, wäre es besser gewesen, gleich Aspirin zu besorgen.

Sysmon hingegen macht einen qualitativen Sprung nach vorne, indem es nützliche (oder, wie die Anbieter sagen, effektive) Informationen bereitstellt, um das Verständnis grundlegender Prozesse zu unterstützen. Zum Beispiel habe ich eine verdeckte Sitzung wmiexec, die eine Bewegung eines smarten Insiders innerhalb des Netzwerks simuliert. Das sehen Sie im Windows-Ereignisprotokoll:

Leitfaden zur Analyse von Sysmon-Bedrohungen, Teil 1

Im Windows-Protokoll ist eine gewisse Information über den Prozess sichtbar, aber sie ist wenig nützlich. Außerdem sind die Prozess-ID in hexadezimaler Form???

Bei einem professionellen IT-Spezialisten, der die Grundlagen des Hackens versteht, sollte die Kommandozeile Verdacht erregen. Die Verwendung von cmd.exe, um einen anderen Befehl mit Umleitung der Ausgabe in eine Datei mit einem seltsamen Namen auszuführen, sieht ganz nach Software zur Kontrolle und Verwaltung aus. Befehls- und Kontrollsystem (C2): Auf diese Weise wird ein Pseudo-Shell mit WMI-Diensten erstellt.
Jetzt schauen wir uns das Äquivalent eines Eintrags aus Sysmon an und achten darauf, wie viel zusätzliche Information es uns liefert:

Leitfaden zur Analyse von Sysmon-Bedrohungen, Teil 1

Die Funktionen von Sysmon auf einem Screenshot: detaillierte Prozessinformationen in lesbarer Form

Sie sehen nicht nur die Kommandozeile, sondern auch den Dateinamen, den Pfad zur ausführbaren Datei, was Windows darüber weiß ("Windows-Kommandoprozessor"), die ID des übergeordneten Prozesses, die Kommandozeile des Elternteils, der die cmd-Shell gestartet hat, sowie den tatsächlichen Namen der Datei des übergeordneten Prozesses. Alles an einem Ort, endlich!
Aus dem Sysmon-Protokoll können wir schließen, dass diese verdächtige Kommandozeile, die wir in den "rohen" Protokollen gesehen haben, mit hoher Wahrscheinlichkeit kein Ergebnis der normalen Aktivitäten eines Mitarbeiters ist. Vielmehr wurde sie von einem C2-ähnlichen Prozess - wmiexec, wie ich zuvor erwähnte - erzeugt und direkt vom WMI-Dienstprozess (WmiPrvSe) hervorgebracht. Jetzt haben wir einen Hinweis darauf, dass ein entfernter Angreifer oder Insider die Unternehmensinfrastruktur testet.

Wir stellen Get-Sysmonlogs vor

Es ist natürlich großartig, wenn Sysmon die Protokolle an einem Ort bereitstellt. Aber es wäre wahrscheinlich noch besser, wenn wir programmatisch auf die einzelnen Felder des Protokolls zugreifen könnten - zum Beispiel ü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 gekommen ist. Und es ist gut, dass in einigen Foren und GitHub Projekten bereits erklärt wurde, wie man PowerShell zum Parsen von Sysmon-Protokollen verwendet. In meinem Fall wollte ich die Notwendigkeit vermeiden, separate Parsing-Skriptzeilen für jedes Sysmon-Feld zu schreiben. Deshalb habe ich das Prinzip des faulen Menschen angewandt und denke, dass ich am Ende etwas Interessantes erfunden habe.
Ein wichtiger Punkt ist die Möglichkeit des Befehls Get-WinEvent Sysmon-Protokolle zu lesen, die benötigten Ereignisse zu filtern und das Ergebnis in eine PS-Variable auszugeben, wie hier:

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

Wenn Sie die Arbeiten des Teams selbst überprüfen möchten, können Sie über die Anzeige des Inhalts im ersten Element des Arrays $events, $events[0].Message, eine Reihe von Textzeilen mit einem sehr einfachen Format erhalten: Feldname Sysmon, Doppelpunkt und dann der eigentliche Wert.

Leitfaden zur Analyse von Sysmon-Bedrohungen, Teil 1

Hurra! Sysmon-Log-Ausgabe im fertigen JSON-Format

Denken Sie an dasselbe wie ich? Wenn Sie ein wenig mehr Aufwand betreiben, können Sie die Ausgabe in eine formatierte JSON-Zeichenkette konvertieren und dann direkt in ein PS-Objekt mit dem leistungsstarken Befehl hochladen. ConvertFrom-Json .
Ich werde PowerShell-Code zur Konvertierung zeigen – er ist sehr einfach – im nächsten Abschnitt. Lassen Sie uns vorerst ansehen, was mein neues Kommando mit dem Namen get-sysmonlogs, das ich als PS-Modul installiert habe, tun kann.
Anstatt uns in die Analyse von Sysmon-Logs über die umständliche Schnittstelle des Ereignisprotokolls zu vertiefen, können wir mühelos inkrementelle Aktivitäten direkt aus der PowerShell-Sitzung suchen und den PS-Befehl verwenden. where (Alias – "?") zur Verkürzung der Ausgaberesultate:

Leitfaden zur Analyse von Sysmon-Bedrohungen, Teil 1

Liste der Cmd-Shells, die über WMI gestartet wurden. Bedrohungsanalyse zum kleinen Preis mit unserem eigenen Befehl Get-Sysmonlogs

Unglaublich! Ich habe ein Befragungswerkzeug für das Sysmon-Log erstellt, als ob es eine Datenbank wäre. In unserem Artikel über EQL wurde erwähnt, dass diese Funktion von dem darin beschriebenen großartigen Tool ausgeführt wird, obwohl es formal über eine echte SQL-ähnliche Schnittstelle erfolgt. Ja, EQL ist elegant, aber darauf werden wir im dritten Teil eingehen.

Sysmon und Graphanalyse

Lassen Sie uns abstrahieren und darüber nachdenken, was wir gerade erstellt haben. Im Wesentlichen haben wir jetzt eine Windows-Ereignisdatenbank, die über PowerShell zugänglich ist. Wie ich bereits erwähnt habe, gibt es zwischen den Aufzeichnungen Verbindungen oder Zusammenhänge – über ParentProcessId – daher können wir die vollständige Hierarchie der Prozesse erhalten.

Wenn Sie die Serie gelesen haben „Die Abenteuer der unerfassbaren Malware“ , 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 extrem schwierig nur aus dem "rohen" Log zu erfassen.
Aber mit meinem Befehl Get-Sysmonlogs und der zusätzlichen Datenstruktur, die wir im weiteren Verlauf des Textes betrachten werden (natürlich ein Graph), werden wir einen praktischen Weg haben, um Bedrohungen zu erkennen – wofür es nur erforderlich ist, die richtige Suche in den Knoten durchzuführen.
Wie immer in unseren DIY-Blogprojekten, je mehr Sie an der Analyse von Bedrohungsdetails in kleinerem Maßstab arbeiten, desto deutlicher erkennen Sie, wie kompliziert die Erkennung von Bedrohungen auf der organisatorischen Ebene ist. Und dieses Bewusstsein ist von entscheidender Bedeutung. ein wichtiger Punkt.

In der zweiten Hälfte des Artikels werden wir die ersten interessanten Herausforderungen antreffen, wenn wir beginnen, Sysmon-Ereignisse in deutlich komplexere Strukturen miteinander zu verknüpfen.

Quelle: habr.com

60GB SSD 8Gb DDR4