Varonis debuts trailblazing features for securing Salesforce. Learn More

Wir stellen vor: Die Least Privilege Automation für Microsoft 365, Google Drive und Box

Mehr erfahren

Powershell Verschleierung: Unerkannt durch Verwirrung, Teil II

Dieser Artikel ist Teil der Reihe „Powershell Verschleierung“. Sehen Sie sich den Rest an: Powershell-Verschleierung: Unerkannt durch Verwirrung, Teil 1 Powershell-Verschleierung: Unerkannt durch Verwirrung, Teil 2 Die Methode, Code zu...
Michael Buckbee
3 minute gelesen
Veröffentlicht 23. Januar 2020
Letzte aktualisierung 1. November 2021

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.

Windows PowerShell-Protokollfunktion sind ausgezeichnet!

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:

ein PowerShell cmdlet

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.

 PowerShell-Protokollfunktion
Eine bessere PowerShell-Protokollfunktion kann in GPM aktiviert werden!

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

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

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

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:

Zwar sehr verschleiert
Zwar sehr verschleiert, aber mit der aktivierten PowerShell-Protokollfunktion waren die zugrundeliegenden cmdlets im Protokoll verfügbar.

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.

Durcheinander messen
Das zugrundeliegende cmdlet, das von dieser hexadezimalen Verschleierung dargestellt wird, wurde nicht erkannt.

Durcheinander messen

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!

Zeichenfrequenz aufweist als Standardskripte
Die Punkte unter dem Haupttrend zeigen, dass eine verschleierte PowerShell eine andere Zeichenfrequenz aufweist als Standardskripte.

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!

Weitere Gedanken

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.

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.
Testen Sie Varonis gratis.
Detaillierte Zusammenfassung Ihrer Datensicherheitsrisiken
Umsetzbare Empfehlungen, die auf Ihre Bedürfnisse zugeschnitten sind
Ohne Bedingungen und Auflagen
Keep reading
hinter-dem-varonis-rebranding
Hinter dem Varonis-Rebranding
Entdecken Sie die Strategie, die hinter dem Rebranding von Varonis steht – mit einem Übergang zu einem Heldenarchetyp und der Einführung von Protector 22814.
cybersecurity-trends-2024:-was-sie-wissen-müssen
Cybersecurity-Trends 2024: Was Sie wissen müssen
Erfahren Sie mehr über Datensicherheitsmanagement, KI-Sicherheitsrisiken, Änderungen bei der Compliance und mehr, um Ihre Cybersecurity-Strategie für 2024 vorzubereiten.
das-war-2023 – so-wird-2024
Das war 2023 – so wird 2024
Im Kielwasser der massiven Verbreitung von WannaCry im letzten Monat sorgt gerade eine neue Variante von Ransomware für massive Störungen, dieses Mal unter der Bezeichnung „NotPetya“. Fast den gesamten Morgen...
podcast-empfehlung:-alles,-was-sie-zu-data-security-posture-management
Podcast-Empfehlung: Alles, was Sie zu Data Security Posture Management
Im Gespräch mit Oliver Schonschek, News-Analyst bei Insider Research, hatte ich die Möglichkeit, das Konzept Data Security Posture Management zu erklären und zu zeigen, wie es sich in der Praxis umsetzen lässt. Dabei stand zunächst die Frage im Raum, ob und inwieweit wir unsere bisherigen Security-Konzepte neu denken müssen. Werden durch DSPM bewährte Praktiken wie Endpoint-Sicherheit, Firewalls und ähnliches gar obsolet?