Analysiert: Ransomware meets Info-Stealer - RAA und das diebische Pony

Im Rahmen unserer Analysiert:-Serie geht es diesmal einem Erpressungs-Trojaner an den Code: Olivia von Westernhagen untersucht den in JavaScript realisierten RAA-Trojaner, der gleich auch noch eine Passwort-Klau-Malware im Gepäck hat.

In Pocket speichern vorlesen Druckansicht 6 Kommentare lesen
Analysiert: Ransomware meets Info-Stealer - RAA und das diebische Pony
Lesezeit: 9 Min.
Inhaltsverzeichnis

Ende Juni berichtete heise Security über eine neue Ransomware namens RAA, die sich auf besondere Weise von anderen Vertretern dieser Spezies unterschied. Demnach handelte es sich bei RAAs Programmcode um JavaScript, welches vornehmlich als gefälschter Rechnungsanhang verschickt wurde. Nach dem Doppelklick auf die Datei mit der Endung .js verschlüsselte das Skript nicht nur Dateien, sondern infizierte das betroffene System zusätzlich auch noch mit dem Passwort-Klau-Programm Pony.

Die Behauptung, es handele sich um "100 Prozent JavaScript", warf bei mir jedoch einige Fragen auf. Wie lässt sich eine JavaScript-Datei unabhängig von einer – meist durch einen Webbrowser bereitgestellten – Engine ausführen? Und woher nimmt das Skript die erforderlichen Rechte zum Starten einer .exe-Datei auf dem lokalen Rechner?

Um diesen Fragen auf den Grund zu gehen und weitere Details herauszufinden, habe ich mir eine RAA- nebst zugehöriger Pony-Variante näher angesehen. Zwar ist der während des Verschlüsselungsvorgangs kontaktierte Server mittlerweile offline; dennoch konnte ich mir einen guten Überblick über Besonderheiten der Ransomware verschaffen, die in dieser oder ähnlicher Form auch in künftiger Malware implementiert werden könnten. (Links zu den Dateien finden sich etwa bei Virustotal: RAA und Pony)

Nach einem Beautifier-Durchlauf, ist der Programmcode schon viel besser lesbar.

Während der Analyse wird schnell klar, dass es sich bei der Ransomware streng genommen nicht um reines JavaScript, sondern um JScript handelt. Die Microsoft-eigene Variante des ECMAScript-Standards, auf dem auch JavaScript basiert, unterscheidet sich von diesem in erster Linie dadurch, dass JScript für den Windows Script Host (WSH) geschrieben und durch dessen JScript-Engine ausgeführt wird. Da WSH vor allem zur Systemadministration und zur Automatisierung wiederkehrender Arbeitsprozesse entwickelt wurde, ermöglicht es Skripten die Nutzung von Methoden, mit denen sich das System nicht nur überwachen und analysieren, sondern auch umfangreich manipulieren lässt.

Selbstverständlich kann auch so manches "reine" JavaScript auf diese Weise ohne Webbrowser als Standalone-Skript per Kommandozeile oder Doppelklick lokal ausgeführt werden. Für Schadcode essentielle Funktionen wie das Auslesen und Bearbeiten von Registry-Einträgen, die Simulation von Tastatur-Eingaben in laufende Anwendungen, das Starten neuer Prozesse oder auch die Verwendung von ActiveX-Steuerelementen werden jedoch erst mittels Methoden aus dem WSH-eigenen WScript-Object sowie aus COM-Objekten zugänglich.

Zunächst werfe ich im Texteditor einen ersten Blick auf das gut 723-KByte-große Skript. Der absichtlich unübersichtlich gespeicherte Code wird durch die Verwendung eines Tools wie JSBeautifier sofort besser lesbar. Aus mehreren Artikeln weiß ich bereits, dass RAA zum Verschlüsseln der Dateien die frei verfügbare CryptoJS-Bibliothek verwendet – genauer: deren Implementierung der Blockchiffre AES. Dementsprechend besteht der erste Teil des Skripts aus einer Kopie des CryptoJS-AES-Codes.

Den eigentlichen, mittels zufälliger Variablen- und Funktionsnamen und teils auch Verschlüsselung stark obfuskierten Schadcode finde ich am Ende des Scripts. Er gliedert sich zum einen in die Verschlüsselungs- und Erpressungs-Funktionen und zum anderen in einen Bereich, der für das Extrahieren und Starten des Pony-Trojaners zuständig ist. Im Folgenden werfe ich zunächst einen näheren Blick auf die Funktionsweise von RAA, bevor ich mich Pony zuwende. Interessant wird auch sein herauszufinden, ob eine Interaktion zwischen den beiden Schädlingen stattfindet, die über das Starten des Pony-Prozesses hinausgeht.

Vorgeblich beschädigtes, zuerst angezeigtes Dokument.

Die grundsätzliche Vorgehensweise der Ransomware RAA wurde bei heise Security bereits beschrieben: Das JScript stellt nach seiner Ausführung unter Verwendung des Wordpad zunächst ein scheinbar defektes Textdokument dar, um den Nutzer in Sicherheit zu wiegen. In Wirklichkeit jedoch verschlüsselt es mittels der bereits erwähnten CryptoJS-Bibliothek im Hintergrund Dateien und versieht sie dann mit der Endung .locked. Anschließend fordert RAA mittels eines zweiten Dokuments eine Lösegeldzahlung in Bitcoins. Diese zweite, manuell zu öffnende Textdokument ist übrigens mit einer .rtf-Endung versehen – vermutlich um die Kompatibilität nicht nur mit Office, sondern auch mit alternativ genutzten Textverarbeitungsprogrammen zu gewährleisten.

Statt nur die bekannten Einzelheiten zu wiederholen, möchte ich einige interessante Details hinzufügen, die bisher noch nicht erwähnt oder nicht näher erklärt wurden. Dabei stehen die Besonderheiten des Verschlüsselungsvorgangs im Vordergrund. Darüber hinaus soll noch einmal deutlich gemacht werden, welche Möglichkeiten des WSH die Ransomware nutzt, die sie als reines JavaScript nicht hätte.

Erpresser-Botschaft mit Platzhaltern für ID und Bitcoin-Adresse.

Obwohl RAA zur Zahlung der geforderten Bitcoins und zur Kontaktaufnahme mit dem Erpresser im Textdokument eine Bitcoin- und eine E-Mail-Adresse bereitstellt, wird auf die Kommunikation mit einem entfernten Server während des Verschlüsselungsprozesses keineswegs verzichtet. Hierfür gibt es zwei Gründe: Zum einen ist der Key, der dem Nutzer im Anschluss an die Zahlung mitsamt eines Entschlüsselungs-Tools zugesendet werden soll, rechnerspezifisch. Zum anderen wird die im Dokument angezeigte Bitcoin-Adresse bei jeder Ausführung neu vom Server abgerufen. Dies gibt dem Erpresser die Möglichkeit, die Adresse zu ändern, falls sie gesperrt wird, ohne dass ihm die Besitzer bereits infizierte Rechner als zahlende Kunden verloren gehen.

Die Vorbereitung des Verschlüsselungsvorgangs beginnt folgendermaßen: Unter Verwendung des WScript-Objects erzeugt RAA ein neues ActiveX-Objekt vom Typ Scriptlet.TypeLib. Ein solches Objekt verfügt zur eindeutigen Identifizierung stets über eine so genannten GUID aus Hexadezimalwerten im Format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Die letzten 18 Stellen dieser eindeutigen GUID mit angehängtem Zusatz "- RAA" dienen der Ransomware als ID.

Die Ransomware sendet nun einen GET-Request an eine im Skript fest definierte URL und übergibt besagte ID als Parameter. Der Server sendet einen mehr 2000 Zeichen langen String zurück, der auf dem lokalen Rechner per split()-Funktion in zwei Teile aufgeteilt wird. Während es sich bei einer Hälfte um die Bitcoin-Adresse für die Lösegeldzahlung handelt, kommt die andere Hälfte beim nachfolgenden Verschlüsselungsvorgang zum Einsatz.

Meist ist ja im Zusammenhang mit Verschlüsselungstrojanern von EINEM Key die Rede, der dem Opfer im Falle einer Lösegeldzahlung übermittelt wird. Tatsächlich wird im vorliegenden Fall jedoch auf Basis des vom Server übermittelten Strings PRO DATEI sowohl ein neuer Key als auch ein neuer sogenannter Initialization Vector (IV) generiert. Letzterer dient gewissermaßen dazu, die "Zufälligkeit" des Verschlüsselungsresultats – und damit die Sicherheit der Verschlüsselung – zu erhöhen.

Erzeugen von Key und Initialisierungsvektor samt zugehöriger Offsets.

Das Generieren von Keys und IVs erfolgt mittels des JScripts direkt auf dem infizierten Rechner. Sie werden innerhalb einer Funktion erzeugt, der der vom Server übermittelte lange String als Parameter übergeben wird. Der Aufruf der Funktion erfolgt pro Datei. Sowohl der Key als auch der IV umfassen je 32 Zeichen (32 Byte ergeben die verwendeten 256 Bit), die jeweils von einer zufällig ausgewählten Position des Strings stammen.

Die anschließende Verschlüsselung erfolgt durch einen Aufruf von CryptoJS.AES.encrypt(). Als Parameter werden die zu verschlüsselnde Datei, der Key sowie der IV übergeben. Bei AES handelt es sich um eine symmetrische Blockchiffre, die ein und denselben Key und IV sowohl für die Ver- als auch für die Entschlüsselung nutzt. Da RAA diese Werte jedoch für sämtliche Dateien lokal generiert, liegt die Frage nahe, wie die Entschlüsselung durch den Erpresser überhaupt möglich ist.

Dabei sind zwei Details entscheidend. Zum einen wird der als Verschlüsselungs-Basis dienende lange String dauerhaft auf dem C&C-Server gespeichert und kann mit Hilfe der übermittelten GUID eindeutig einem bestimmten PC zugeordnet werden. Zum anderen speichert RAA am Ende jeder verschlüsselten Datei die Offsets, an deren Position im String die einzelnen Bytes von Schlüssel und IV zu finden sind.

Hinter den verschlüsselten Daten der Datei schreibt RAA mit "ids" die Computer-ID und die Offsets für Key und IV in die Datei, bevor er diese abschließend mit der Endung .locked versieht.

Mit Hilfe dieser Offsets kann das Entschlüsselungs-Tool also aus dem vom Erpresser gelieferten 2000-Zeichen-String den benötigten IV und AES-Key für eine Datei ermitteln und diese dann wieder dechiffrieren. Ohne den String ist dieses Vorhaben hingegen aussichtslos. Die Zeichenfolge wird auf dem Command&Control-Server erzeugt und es ist nicht bekannt wie. Es ist jedoch anzunehmen, dass der Server zu jeder GUID einen zufälligen String auswürfelt. Auf dem Client liegt der Schlüssel-String nur während der Verschlüsselung und da auch nur im Arbeitsspeicher vor. Danach ist eine Entschlüsselung auf eigene Faust zum Scheitern verurteilt.

Dass man und wie man trotzdem einige Daten noch retten kann, verrät die nächste Analysiert-Folge, in der ich auch die WSH-Nutzung und vor allem das diebische Pony genauer untersuchen werde.

Mehr Infos

Analysiert - die Serie auf heise Security

Im Rahmen der losen heise-Security-Serie "Analysiert:" werfen Experten einen Blick hinter die Kulissen von aktuellen Schädlingen, Betrugsmaschen oder anderen Tricks, die Sie um Ihre Daten bringen sollen.

(ovw)