Dieser Artikel ist Teil der Reihe „Powershell Verschleierung“. Sehen Sie sich den Rest an:
Die Methode, Code zu verschleiern, um das Entdecken von Malware und Virenscannern zu vermeiden (oder Reverse-Engineering zu verhindern), ist nicht neu. Wenn wir einen Blick zurück in die historischen Aufzeichnungen werfen, stoßen wir auf das (in Perl geschrieben). Was ist da schon Besonderes dran?
Die entscheidende Änderung liegt darin, dass sich Hacker mithilfe von PowerShell in praktisch jeder Phase eines Angriffs frei von schädlichem Code bewegen können. Und über eine Verschleierung hat diese PowerShell-Ware dann effektiv eine Art Tarnkappe. Und wir alle wissen, dass Tarngeräte, sogenannte Cloaking Devices, einer Seite einen enormen Vorteil bringen können!
IT-Sicherheitsteams müssen sich mit dieser neuen Bedrohung auseinandersetzen.
Wie sich zeigt, war ich letztes Mal ein wenig zu voreilig in meinem Rückblick bezüglich der Protokollfähigkeiten von PowerShell, die in der Gruppenrichtlinienveraltung aktiviert werden. Ich zeigte ein Beispiel, in dem ich ein PowerShell cmdlet von einer Remote-Wesbite heruntergeladen und ausgeführt hatte:
Ich hatte den Eindruck, dass die PowerShell-Protokollfunktion die eingebettete Malware nicht in dem String anzeigen würde, der von Website heruntergeladen wurde.
Ich hatte mich geirrt.
Wenn Sie die PowerShell-Protokollfunktion über GPM aktivieren, dann erscheint tatsächlich der Remote PowerShell-Code im Protokoll. Zur Erinnerung: Ich hatte die PowerShell Version 4 verwendet und (soweit ich weiß) das neueste Windows Management Framework (WMF), das eine eher granulare Protokollierung unterstützen soll.
Das ist zwar eher nebensächlich, aber es bedeutet, dass die Angreifer auch den ersten Payload verschleiern.
Außerdem lag ich falsch in meiner Annahme, dass die Verschleierung, die von Invoke-Obfuscation geliefert wurde, im Protokoll nicht verborgen erscheint. Im letzten Post testete ich bspw. eine String-Verschleierung für Folgendes:
Im Wesentlichen handelt es sich nur um eine Verknüpfung separater Strings, die zur Laufzeit zusammengeführt werden, um ein cmdlet zu bilden.
Für diesen Post testete ich mehrere Invoke-Obfuscation-Scrambling-Optionen, um zu prüfen, wie die Befehlszeile im Ereignisprotokoll angezeigt wird.
Ich testete seine String-Reorder-Option (siehe unten), die einige nette Tricks in PowerShell nutzt.
Sehen Sie diesen ersten Teil $env:comspec[4,15,25]? Er nimmt die Umgebungsvariable $env:comspec und extrahiert das 4., 15. und 25. Zeichen zur Generierung von „IEX“, der PowerShell-Alias für Invoke-Expression. Der join-Operator nimmt die Anordnung und konvertiert sie in einen String.
Der nächste Teil dieses PowerShell-Ausdrucks verwendet das Format operator f. Wenn Sie als Programmierer mit ähnlichen sprintf-Befehlen gearbeitet haben, werden Sie diese Fähigkeiten sofort erkennen. Mit PowerShell können Sie jedoch die Elementposition in der Parameterliste angeben, die einbezogen wird, um den daraus resultierenden String zu erstellen. Somit startet {20}, {5}, {9}, {2} die Zusammenstellung eines weiteren Invoke_Expression cmdlet.
Ja, das kann ganz schnell kompliziert werden!
Außerdem ermögliche ich Invoke-Obfuscation die freie Auswahl aus seinem Verschleierungs-Menü und habe folgendes Durcheinander erhalten:
Nachdem ich das alles getestet hatte, prüfte ich die Ereignisanzeige, um festzustellen, dass Windows jetzt mit leistungsfähigeren Protokollfunktionen einen besseren Durchblick hat und die zugrundeliegende PowerShell erfassen kann:
Bedeutet das, dass eine PowerShell-Verschleierung im Windows-Ereignisprotokoll immer aufgehoben wird und damit Malware-Detektoren die Möglichkeit gibt, einen traditionellen Musterabgleich zu verwenden?
Die Antwort ist nein!
Mit Invoke-Obfuscation können Sie auch PowerShell-Skripte in RAW ASCII-, hexadezimale und sogar in binäre Zeichen verschlüsseln. Und dieses Verschleiern einer Verschlüsselung scheint die Ereignisprotokollierung zu unterwandern.
An dieser Stelle haben scheinbar die Angreifer den Vorteil: ein Cloaking Device (Tarngerät), das seine Skripte für Verteidiger unsichtbar macht oder sie zumindest sehr verschleiert.
Bei dem Vortrag auf der Black Hat-Konferenz, die ich im ersten Post erwähnt habe, wurde eine Arbeit von Lee Holmes (Microsoft), Daniel Bohannon und anderen Forschern vorgestellt, bei der verschleierte Malware unter Verwendung von probabilistischen Modellen und maschinellen Lernmethoden erkannt wurde.
Wenn Sie interessiert sind, können Sie sich das Dokument ansehen, das sie auf der Konferenz vorgestellt haben. Holmes entlieh sich Methoden aus der natürlichen Sprachverarbeitung, um eine Zeichenfrequenz der verschleierten PowerShell-Skripte gegenüber harmlosen Varianten zu analysieren. Hier gibt es deutliche Unterschiede!
Auf jeden Fall wechselte Holmes zu einem komplizierteren, logistischen Regressions-Modell – das im Wesentlichen einen PowerShell-Code entweder in bösartige, verschleierte oder in normale Skripte klassifiziert. Anschließend schulte er sein Logit, indem er sich das Parsing der Befehle von PowerShell genauer unter die Lupe nahm – und Statistiken für Verschachtelungsebenen usw. erfasste – um sich einen respektableren Klassifikator auszudenken mit einer Genauigkeit von etwa 96 Prozent. Zwar nicht perfekt, aber ein guter Anfang!
Ich ziehe vor Microsoft zwar meinen Hut für die Verbesserung ihrer PowerShell-Protokollfunktion, aber es gibt immer noch genügend Schlupflöcher, die Angreifer nutzen können, um ihre Skripte unerkannt auszuführen. Und das setzt voraus, dass IT-Teams wissen, wie die PowerShell-Protokollfunktion überhaupt aktiviert wird!
Das Maschinenlernmodell von Lee Holmes geht davon aus, dass es möglich ist, diese heimlichen Skripte zu erkennen.
Das bedeutet jedoch, dass wir wieder beim Scannen nach Malware sind. Und dieser Ansatz hat bekanntermaßen Schwächen. Man kann mit Angreifern, die ihren Code ständig ändern und anpassen, um die Detektoren in die Irre zu führen, nicht mithalten.
Wohin führt das? Natürlich aktivieren Sie die PowerShell-Protokollfunktion bei Bedarf und versuchen, Ihre Scanning-Software aktuell zu halten. Aber letztendlich braucht man einen soliden Sekundärschutz, der in der Lage ist, Aktivitäten nach einem Exploit zu erkennen und beispielsweise den Zugriff auf Ihre sensible Daten Ausschau zu verhindern.
Erfassen Sie alles, was PowerShell-Protokollscanner verpassen! Fordern Sie noch heute eine Demo an.