Dieser Artikel ist der erste Teil einer Reihe von Sysmon-Bedrohungsanalysen. Alle anderen Teile der Serie:
Teil 1. Einführung in die Sysmon-Protokollanalyse (wir sind hier)
Teil 2. Verwenden von Sysmon-Ereignisdaten zum Erkennen von Bedrohungen
Teil 3. Detaillierte Sysmon-Bedrohungsanalyse mithilfe von Diagrammen
Wenn Sie sich mit Informationssicherheit beschäftigen, müssen Sie wahrscheinlich häufig verstehen in laufenden Angriffen. Wenn Sie bereits ein gutes Auge haben, können Sie in Rohprotokollen nach nicht standardmäßigen Aktivitäten suchen, z. B. nach einem PowerShell-Skript, in dem der Befehl DownloadString ausgeführt wirdoder ein VBS-Skript, das vorgibt, eine Word-Datei zu sein - blättert einfach durch die neueste Aktivität im Windows-Ereignisprotokoll. Aber das sind wirklich große Kopfschmerzen. Glücklicherweise hat Microsoft Sysmon entwickelt, um die Angriffsanalyse erheblich zu vereinfachen.
Möchten Sie die grundlegenden Ideen hinter den im Sysmon-Protokoll angezeigten Bedrohungen verstehen? Laden Sie unseren WMI-Veranstaltungsleitfaden als Spionagetool herunter und Sie werden verstehen, wie Insider andere Mitarbeiter ruhig 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, die Hierarchie der Prozesse daraus zu verstehen. Im Gegensatz dazu enthalten Sysmon-Protokolleinträge die Prozess-ID, den Namen und die auszuführende Befehlszeile des übergeordneten Elements. Vielen Dank, dass Sie Microsoft.
Im ersten Teil unserer Serie werden wir uns ansehen, was Sie mit grundlegenden Informationen von Sysmon tun können. In Teil 2 werden wir die Elterninformationen voll ausnutzen, um komplexere Konformitätsstrukturen zu erstellen, die als Bedrohungsgraphen bezeichnet werden. Im dritten Teil werden wir uns einen einfachen Algorithmus ansehen, der das Bedrohungsdiagramm durchsucht, um nach nicht standardmäßigen Aktivitäten zu suchen, indem das Diagramm "Gewicht" analysiert wird. Und als Belohnung finden Sie am Ende eine genaue (und verständliche) probabilistische Methode zur Erkennung von Bedrohungen.
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 nachfolgende Analyse. Aber so weit müssen wir zumindest nicht gehen. Um die Prinzipien von SIEM zu verstehen, reicht es am Anfang aus, das wunderbare kostenlose Dienstprogramm Sysmon auszuprobieren. Und es ist überraschend einfach, mit ihr zu arbeiten. Weiter so, Microsoft!
Welche Funktionen hat 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, sondern vor allem die folgenden Felder:
- Prozess-ID (dezimal, nicht hexadezimal!)
- Übergeordnete Prozess-ID
- Befehlszeile verarbeiten
- Die übergeordnete Prozessbefehlszeile
- Datei Bild Hash
- Bildnamen der Datei
Sysmon wird sowohl als Gerätetreiber als auch als Dienst installiert - weitere Details hier. Der Hauptvorteil besteht in der Möglichkeit, Protokolle aus mehreren Quellen zu analysieren , Informationen zu korrelieren und die resultierenden Werte in einem Ereignisprotokollordner anzuzeigen, der sich im Pfad Microsoft -> Windows -> Sysmon -> Operational befindet . Bei meinen eigenen Untersuchungen von Windows-Protokollen, bei denen mir die Haare zu Berge stehen, musste ich ständig zwischen dem PowerShell-Protokollordner und dem Sicherheitsordner wechseln und die Ereignisprotokolle durchblättern, um die Werte zwischen ihnen irgendwie zu vergleichen. Dies ist keine leichte Aufgabe, und wie ich später erkannte, war es besser, sich sofort mit Aspirin zu versorgen.
Sysmon macht einen Quantensprung vorwärts, indem es nützliche (oder, wie Anbieter gerne sagen, umsetzbare) Informationen bereitstellt, die Ihnen helfen, die zugrunde liegenden Prozesse zu verstehen. Zum Beispiel habe ich eine geheime wmiexec- Sitzung gestartet , die die Bewegung eines intelligenten Insiders innerhalb des Netzwerks simuliert. Folgendes wird im Windows-Ereignisprotokoll angezeigt:
Einige Informationen über den Prozess sind im Windows-Protokoll sichtbar, aber von geringem Nutzen. Plus Prozesskennungen hexadezimal ???
Ein professioneller IT-Experte mit einem Verständnis der Grundlagen des Hackens sollte der Befehlszeile gegenüber misstrauisch sein. Die Verwendung von cmd.exe zum Ausführen eines weiteren Befehls, der die Ausgabe in eine Datei mit einem seltsamen Namen umleitet, ähnelt eindeutig den C2- Softwareaktionen (Command-and-Control) : Auf diese Weise wird mithilfe von WMI-Diensten eine Pseudo-Shell erstellt.
Schauen wir uns nun das Äquivalent des Sysmon-Eintrags an und stellen fest, wie viele zusätzliche Informationen er uns gibt:
Sysmon Funktionen in einem Screenshot: detaillierte Informationen über den Prozess in einer lesbaren Form
nur Sie nicht die Befehlszeile sehen, aber auch der Dateiname, der Pfad zu der ausführbaren Anwendung , die Windows weiß davon ( „Windows Command Processor“), die Kennung des übergeordneten Prozesses, die Befehlszeile des Mutter Dadurch wurde die Cmd-Shell sowie der tatsächliche Dateiname des übergeordneten Prozesses gestartet. 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. Im Gegenteil, es wurde durch einen C2-ähnlichen Prozess generiert - wmiexec, wie ich bereits erwähnt habe - und wurde direkt durch den Service-WMI-Prozess (WmiPrvSe) erzeugt. Wir haben jetzt einen Indikator dafür, dass ein entfernter Angreifer oder Insider die Unternehmensinfrastruktur ausprobiert.
Einführung in Get-Sysmonlogs
Natürlich ist es großartig, wenn Sysmon die Protokolle an einem Ort hat. Aber wahrscheinlich wäre es sogar 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 diese Idee hatte. Es ist gut, dass einige Forenbeiträge und GitHub- Projekte bereits erklärt haben, wie PowerShell zum Parsen des Sysmon-Protokolls verwendet wird. In meinem Fall wollte ich vermeiden, dass für jedes Sysmon-Feld separate Zeilen für das Parsing-Skript geschrieben werden müssen. Also habe ich das Prinzip der faulen Person angewendet und ich denke, ich habe als Ergebnis etwas Interessantes gefunden.
Der erste wichtige Punkt ist die Fähigkeit des TeamsGet-WinEvent liest Sysmon-Protokolle, filtert die erforderlichen Ereignisse und gibt das Ergebnis wie folgt an eine 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, können Sie durch Anzeigen des Inhalts im ersten Element des Arrays $ events, $ events [0] .Message, eine Reihe von Textzeichenfolgen mit einem sehr einfachen Format abrufen: den Namen des Sysmon-Felds, einen Doppelpunkt und dann den Wert selbst.
Hurra! Sysmon-Protokollausgabe im JSON-fähigen Format
Denken Sie das Gleiche wie ich? Mit etwas mehr Aufwand können Sie die Ausgabe in eine JSON-formatierte Zeichenfolge konvertieren und dann mit dem leistungsstarken Befehl ConvertFrom-Json direkt in das PS-Objekt laden .
Ich werde Ihnen im nächsten Teil den PowerShell-Code für die Konvertierung zeigen - es ist sehr einfach. Lassen Sie uns zunächst sehen, was mein neuer Befehl namens get-sysmonlogs, den ich als PS-Modul installiert habe, tun kann.
Anstatt über die unbequeme Ereignisprotokollschnittstelle in die Sysmon-Protokollanalyse einzutauchen, können wir mühelos direkt in der PowerShell-Sitzung nach inkrementellen Aktivitäten suchen und den Befehl PS where (Alias "?") Verwenden. So verkürzen Sie die Ausgabe:
Liste der über WMI gestarteten Cmd-Shells. Die Bedrohungsanalyse ist mit unserem eigenen Get-Sysmonlogs-Team günstig.
Erstaunlich! Ich habe ein Sysmon-Protokollabfragetool erstellt, als wäre es eine Datenbank. In unserem Artikel über EQL wurde festgestellt, dass diese Funktion von dem darin beschriebenen coolen Dienstprogramm ausgeführt wird, obwohl sie formal über eine echte SQL-ähnliche Schnittstelle ausgeführt wird. Ja, EQL ist geschickt , aber wir werden es in Teil 3 ansprechen .
Sysmon- und Graphanalyse
Lassen Sie uns abstrahieren und darüber nachdenken, was wir gerade geschaffen haben. Im Wesentlichen verfügen wir jetzt über eine Windows-Ereignisdatenbank, die über PowerShell verfügbar ist. Wie bereits erwähnt, gibt es Verbindungen oder Verbindungen zwischen Datensätzen - über ParentProcessId -, sodass Sie eine vollständige Hierarchie der Prozesse erhalten können.
Wenn Sie die Serie „Die Abenteuer der schwer fassbaren Malvari“ lesen, wissen Sie, dass Hacker gerne komplexe mehrstufige Angriffe erstellen, bei denen jeder Prozess seine kleine Rolle spielt und ein Sprungbrett für den nächsten Schritt vorbereitet. Solche Dinge sind extrem schwer einfach aus dem "rohen" Protokoll zu fangen.
Mit meinem Befehl Get-Sysmonlogs und einer zusätzlichen Datenstruktur, die wir später im Text betrachten werden (dies ist natürlich ein Diagramm), haben wir eine praktische Möglichkeit, Bedrohungen zu erkennen - was nur eine korrekte Scheitelpunktsuche erfordert.
Wie immer in unseren DYI-Blogprojekten erkennen Sie umso mehr, wie schwierig es ist, Bedrohungen auf organisatorischer Ebene zu erkennen, je mehr Sie daran arbeiten, die Details von Bedrohungen in kleinem Maßstab zu analysieren. Und dieses Bewusstsein ist äußerst wichtig .
Die ersten interessanten Schwierigkeiten werden wir im zweiten Teil des Artikels begegnen, wo wir beginnen werden, Sysmon-Ereignisse mit viel komplexeren Strukturen zu verbinden.