Fortschritte bei der Infektion: Skripte mit Nietzsche

Autor:innen:

• Jozsef Gegeny, Senior Security Researcher
• Norbert Biro, Senior Security Researcher
• Robert Neumann, Leiter, Acronis TRU Labs

Mehrstufige Infektionsketten haben in den letzten zehn Jahren zunehmend an Bedeutung gewonnen. Cyberkriminelle sind von der einfachen Infektion über einen schädlichen E-Mail-Anhang oder einen Drive-by-Download zu mehreren Zwischenschritten übergegangen, bevor die endgültigen Schaddaten bereitgestellt werden. All diese zusätzlichen Schritte zielen darauf ab, die eingesetzten Sicherheitslösungen zu umgehen und eine ungestörte Infektion mit der finalen Malware zu ermöglichen. Aufgrund ihrer oft unnötigen Komplexität bergen diese Infektionsketten aber auch zusätzliche Risiken. Denn wie bei einer echten Kette geht die Kontinuität verloren, wenn sie an irgendeiner Stelle unterbrochen wird.

Vor Kurzem sind wir auf eine komplexe Infektionskette gestoßen, die mehrere Skriptsprachen verwendet, um bekannte Malware-Familien wie die Open-Source-Variante DCRat oder den Infostealer Rhadamanthys zu verbreiten.

Unsere Untersuchung begann mit dem Eingang einer E-Mail mit einem RAR-Archiv im Anhang. Wie erwartet enthielt das Archiv keinen legitimen Inhalt, sondern eine Visual Basic Script-Datei (VBS) mit dem Namen „Citación por embargo de cuenta“. Der Dateiname, der sich offensichtlich an ein spanischsprachiges Publikum richtet, lässt sich ins Deutsche in etwa mit „Vorladung zur Kontopfändung“ übersetzen. Es handelt sich dabei um eine rechtliche Benachrichtigung im Zusammenhang mit der Pfändung oder Sperrung eines Bankkontos aufgrund von Schulden oder anderen finanziellen Verpflichtungen. Die Absicht ist klar: Das Opfer soll nicht zögern, sondern sofort den Anhang öffnen – und damit eine bösartige Infektionskette in Gang setzen.

Die schädliche VBS-Datei verwendet verschachtelte Dropper, was zu einem mehrstufigen Malware-Auslieferungsprozess führt. Wir haben unsere Analyse in vier verschiedene Phasen unterteilt, die in der folgenden Abbildung dargestellt sind.

Die VBS-Datei ist ca. 200 KB groß, was darauf hindeutet, dass es sich nicht um ein einfaches internes Automatisierungsskript handelt. Bei näherer Betrachtung wird uns auch sofort klar, dass es sich hier um eine Verschleierungstaktik handelt. Die eher ungewöhnliche Größe ist nur zum Teil auf die Verschleierungstaktik zurückzuführen, wie die spätere Analyse zeigen wird – sie enthält auch einen verschlüsselten Payload, der erst in Phase 3 extrahiert wird.

Es gibt verschiedene Möglichkeiten, mit der Verschleierung umzugehen: Man könnte sie manuell aufheben, den AMSI-Support von Microsoft nutzen oder sie einfach ignorieren und darauf vertrauen, dass die endgültigen Schaddaten abgefangen werden können, wenn die Ausführung diese Phase erreicht. Acronis ist der festen Überzeugung, dass bei der Erkennung von Bedrohungen ein mehrschichtiger Ansatz erforderlich ist. Daher ziehen wir es vor, schädliche Inhalte zu neutralisieren, bevor sie ausgeführt werden, wenn dies möglich ist. Zusätzlich zu unserem eigenen AMSI-Support verwenden wir einen intern entwickelten generischen Skriptemulator, der auf dem Konzept eines abstrakten Syntaxbaums (Abstract Syntax Tree, AST) basiert, um die Entfernung der Verschleierung für ähnliche Szenarien zu automatisieren.

Nach der Enttarnung ist das Skript für das menschliche Auge besser interpretierbar. Die primäre Funktion der ursprünglichen VBS-Datei besteht darin, eine Windows Batch-Datei (BAT) zu erzeugen und die Ausführung an diese Datei zu übergeben. Die schädliche BAT-Datei wird im Benutzerprofilverzeichnis abgelegt:

Die VBS-Datei erstellt außerdem eine Kopie von sich selbst im gleichen Verzeichnis:

Es ist nicht überraschend, dass unser Batch-Skript in der 2. Phase (konsistent mit der 1. Phase) ebenfalls verschleiert ist.

Wenn sie ausgeführt wird, konstruiert die Batch-Datei mit Hilfe des „set“-Befehls einen Base64-kodierten String aus einer Reihe von Umgebungsvariablen. Dieser Base64-String ist ein kompaktes PowerShell-Skript. Es wird mit dem Argument „-command“ ausgeführt, als ob es über die Windows PowerShell-Eingabeaufforderung eingegeben worden wäre:

Kurz gesagt, die dekodierten Base64-Daten, die ein PowerShell-Skript darstellen, werden im Benutzerprofilverzeichnis gespeichert:

Anschließend wird es mit dem folgenden Befehl ausgeführt:

Interessanterweise scheinen die Cyberkriminellen keine großen Anstrengungen unternommen zu haben, diese Ebene zu verschleiern, da der gesamte Text klar und leicht lesbar ist:

Darin finden sich jedoch einige erwähnenswerte Zitate, wie z. B:

Die meisten, wenn nicht alle Zitate stammen von Friedrich Nietzsche, einem deutschen Philosophen. Die Zitate wurden als Kommentare in das PowerShell-Skript eingefügt und haben keine Bedeutung für die Funktion. Vielleicht besitzen Malware-Autor:innen ja doch eine philosophische Ader.

Die Hauptfunktion dieses Skripts besteht darin, die Datei „aguwDI.bat“ aus den vorherigen Phasen im Benutzerprofilverzeichnis zu finden, die letzte (sehr lange) Zeile dieser Datei zu lesen, die Markierungsbytes zu entfernen und schließlich die resultierenden Schaddaten zu entschlüsseln und zu speichern:

Der in den Speicher geladene Payload ist eine ausführbare Windows .NET-Datei und gehört zu einer beliebten Familie von Remote-Access-Trojanern namens DCRat.

Die Schaddaten wurden mit einem eigenen .NET-Packer komprimiert und stark verschleiert. Bei der Analyse stellten wir fest, dass die Datei in ihrer Ressourcenstruktur zwei verschlüsselte Datenblobs enthält.

Diese Datenblobs verwenden nur eine einfache Verschlüsselung und können leicht mit einer Byte-für-Byte Exklusiv-Oder-Gatter-Operation mit dem Schlüssel 0x78 entschlüsselt werden. Bei der Entschlüsselung dieser Ressourcen entdeckten wir zwei zusätzliche ausführbare Dateien:

Bei der einen handelt es sich um die ausführbare DCRat-Hauptdatei, bei der anderen um eine Bibliothek, die es dem Packer-Modul ermöglicht, das DCRat-Beispiel direkt im Speicher zu laden und auszuführen, ohne es auf die Festplatte zu schreiben. Dies wird durch eine Technik namens RunPE erreicht, die in der Helfer-Bibliothek implementiert ist. Die Hauptbinärdatei von DCRat ist inzwischen ziemlich veraltet, aber eine erfolgreiche Infektion ist mit ähnlichen Auslieferungsmethoden immer noch möglich.

Die in böswilligen Kampagnen genutzten Infektionsketten entwickeln sich ständig weiter und werden immer komplexer. Cyberkriminelle suchen nach Möglichkeiten, ihre eigentlichen Schaddaten zu verbergen, selbst wenn es sich nur um eine weitere Variante einer beliebten Malware-Familie handelt, die der Sicherheitsbranche seit Jahren bekannt ist. Gelingt dies, können selbst veraltete Malware-Binärdateien ungestört ausgeführt werden, sofern die eingesetzte Sicherheitslösung nicht in der Lage ist, deren Anwesenheit im Speicher zu erkennen.

Gleichzeitig steigt mit der Komplexität dieser Infektionsketten auch das Risiko, dass sie bei jedem neu hinzukommenden Schritt gestört werden, was letztlich dazu führt, dass die eigentlichen Schaddaten gar nicht erst geladen werden.

Bei der Analyse dieser Kampagne sind wir auf einige ähnliche Fälle gestoßen, bei denen die Infektionskette genau wie oben beschrieben verlief, die endgültigen Schaddaten jedoch unterschiedlich waren. Anstelle von DCRat verwendeten die Cyberkriminellen den Infostealer Rhadamanthys oder Remcos, einen weiteren beliebten Remote-Access-Trojaner.

Die in der Angriffskette verwendeten Komponenten werden von Acronis Advanced Security + Extended Detection and Response (XDR) erfolgreich erkannt.