Update: Windows Verschlüsselungstrojaner neue ...

Update [03.04.2012]:
Ich gehe inzwischen davon aus, dass die Verschlüsselung des Trojaners als sicher angesehen werden kann und nicht zu knacken sein wird. Alle bisherigen Analysen gehen in diese Richtung, auch wenn es sich um keine klassische asymmetrische Verschlüsselung handelt. Siehe hierzu die Updates vom 03.04. ganz unten im Blogpost.

Seit etwa zwei Wochen ist ein besonders perfider Computervirus im Umlauf, der derzeit nur über E-Mails verteilt wird. In den entsprechenden E-Mails wird dem Empfänger mitgeteilt, es werde ein bestimmter Rechnungsbetrag von seinem Konto abgebucht und er möge die angehängte Rechnung überprüfen. Als Absender werden gefälschte E-Mail Adressen namenhafter Versandhäuser, Elektonikhändler und anderer Online-Shows verwendet.
Bei allen E-Mails ist ein zip Anhang (Rechnung.zip, Abmahnung.zip, Buchung.zip, u.ä.) zu finden. Wenn das Opfer diesen Anhang öffnet, so werden alle Dateien auf der Festplatte verschlüsselt, der Rechner gesperrt und eine Aufforderung zur Zahlung von 100 € per Ucash oder Paysafecard angezeigt:



Es gab vor etlichen Wochen schon eine andere Variante des Trojaners, der die verschlüsselten Dateien nach dem Schema "locked-[Alter Dateiname].[Alte Extension].[zufällige Zeichenfolge] umbenannt hat. Dieser Trojaner nutze eine relativ einfache Verschlüsselung (RC4), die relativ schnell geknackt wurde. So gab es bald Entschlüsselungsprogramme von verschiedenen Antivirus-Herstellern (Dr. Web, Avira, Kaspersky), sowie von verschiedenen unabhängigen IT-Experten (DecryptHelper, ScareUnencrypt).

Bei der neuen Variante des Virus sieht es hingegen bisher recht schlecht aus: Nach über zwei Wochen ist noch immer nicht klar, wie Betroffene wieder an ihre Dateien kommen. Und das, obwohl davon auszugehen ist, dass die AV-Hersteller, wie auch die IT-Experten diverser Foren (trojaner-board.de, botfrei.de, delphipraxis.net) und viele andere (z.B. Xylitol) an einer Lösung des Problems arbeiten.

Auch ich habe mir bereits die ein oder andere Nacht um die Ohren geschlagen, um dem Geheimnis des Trojaners auf die Schliche zu kommen. Meine bisherigen Ergebnisse trage ich hier nun unter Verweis auf weitere Erkenntnisse von anderer Seite zusammen und stelle zur Diskussion, dass es sich bei der neuen Variante um ein public-private Key Verfahren handelt, dass auf absehbare Zeit nicht zu knacken sein wird. Ich möchte in der Hoffnung mit meiner Vermutung unrecht zu haben mit diesem Post dazu aufrufen, mehr Informationen zu diesem Trojaner zu veröffentlichen, den bisher erreichten Wissensstand offener als bisher zu kommunizieren (Trojaner-board) und hoffe, dass sich so noch mehr Leute finden, die Willens und in der Lage sind, diesen Virus zu analysieren. Dieser Virus ist in meinen Augen einfach zu gefährlich, als dass man sich über seinen Wissensstand ausschweigen könnte: Wer also Kenntnisse, Ergänzungen und Anregungen hat, der möge diese bitte öffentlich machen.

Ich werde diesen Post in den nächsten Tagen noch um weitere Informationen ergänzen und diesen Beitrag weiter aktualisieren, wenn ich neue Informationen zu diesem Trojaner finde.

Tools used: OllyDbg, WinDbg, Hexeditor, PEiD, DeDe, IDA Free, Wireshark, Virtualbox, Ubuntu Linux

Grob-Analyse

1) Ablauf der Infektion

Mit Öffnen des Anhangs wird der Trojaner aktiviert. Es erscheint zunächst eine Fehlermeldung, dass es sich nicht um ein Word-Dokument handelt:



Der Trojaner installiert sich daraufhin im Windows Verzeichnis (C:\Windows\system32\[Zufällige Hex-Werte].exe) und im Benutzerverzeichnis (%temp%\[Zufällige Buchstaben]\[Zufällige Hex-Werte].exe). Die Ausgangsdatei wird gelöscht, der Trojaner hängt sich per Codeinjection in "ctfmon.exe" bei 0x7FF94D59 ein:



Weiterhin werden diverse Einträge für den Autostart in der Registry vorgenommen, so dass der Trojaner beim Starten von Windows aktiv ist.

2) Netzwerk-Kommunikation

Sobald der Trojaner aktiv ist, versucht er mehrmals über verschiedene Domains mit dem C&C-Server zu verbinden:

a)
hxxp://ogutors-free.com/a.php?id=8C20AF3F4B435546464F&cmd=img&win=Windows_XP_&loc=0x0407&ver=1.170.1
b)
hxxp://ogutors-free.com/a.php?id=8C20AF3F4B435546464F&cmd=msg&ver=1.170.1
c)hxxp://ogutors-free.com/a.php?id=8C20AF3F4B435546464F&cmd=lfk&ldn=35&stat=CRA&ver=1.170.1&data=MON1xEF944FhyhIF7GcaNYG29T6Zf lvjVTFc2zKPPP8VnTIA
d) Bei Eingabe Paysafe-Code:
hxxp://ogutors-free.com/a.php?id=8C20AF3F4B435546464F&cmd=key&ver=1.170.1&data=1:1:NTU1NTU1NTU1NTU1NTU1NTU1NTUA

Zu den Daten:
ID = vermutlich Installationskennung o.ä.
CMD = Kommando an den Server // CMD=IMG Anfordern der Bilder, die bei gesperrtem Computer angezeigt werden
win = Windows Version
loc = Länderkennung
ver = Version des Trojaners
ldn = ??
stat = Könnte ID des Affiliate (Vertriebspartners) sein
data = ???

Bei allen drei Aufrufen bekommt er Daten vom CC-Server zurück, deren Größe sich unterscheidet:
1. Aufruf: 243,8 kbyte (Bilder)
2. Aufruf: 704 bytes (Vermutung: public Key)
3. Aufruf: 4 bytes (ACK?)

Weitere mögliche Domains sind: SPATBE-WEB.COM, HORAD-FORUM.COM, QUA-A.COM, SPATBE-W.COM, polskamaskas.com, horad-fo.com

Erst nach dem Kontakt mit dem Server beginnt die Verschlüsselung. Die Domains weisen mehrere A-Record-Einträge (verschiedene IP-Adressen) auf. Bei den Servern handelt es sich um shared Server (auf denen viele Domains liegen) mit aktuellem Softwarestand (u.a. linux, nginx, php). Mit dabei sind auch Cluster. Abuse Mails werden nichts bringen (Server-Standorte: China, Russland, ...), zumal es sich bei den gehosteten PHP-Scripten vermutlich eher um Proxys handeln wird, die die Informationen nur weiterleiten, so dass man an dieser Stelle sicher nicht zum Ziel kommen wird.

3) Verschlüsselung:

Der Trojaner verschlüsselt immer nur die ersten 3000 Byte und benutzt dabei die Windows Crypto API (CAPI). Das Ding ist deshalb so schnell, weil es in jede Datei nur 3kb schreibt und er zusätzlich nach Dateitypen filtert. Das bedeutet, dass er bei z.B. angenommenen 30.000 Dateien gerade mal knapp 90 Megabyte (!) schreiben muss. Dass das schnell geht und zwar auch bei starker Verschlüsselung - ist klar.

Er legt dabei keine Sicherheitskopien an, sondern liest die Bytes aus der Datei und schreibt Sie direkt verschlüsselt zurück.


Fein-Analyse / Debugging

Vorweg: Ich denke inzwischen, dass es schlecht aussieht, was die Möglichkeiten einer Entschlüsselung der Daten angeht. Es gibt meiner Ansicht nach einige Indizien, die dafür sprechen, dass es sich hier um ein Public-Key Verfahren mit ausreichend starker Verschlüsselung / Schlüssellänge handelt. Zu den theoretischen Indizien:

- Der Trojaner ist gegenüber einer Analyse nur schlecht geschützt: Kein Anti-Debugging, kein Exepacker (UPX = upx -d Trojaner *haha*), kein Crypter - der Entwickler ist sich seiner Sache scheinbar recht sicher
- Diesen Trojaner scheint es bisher nur in Deutschland zu geben, es könnte sich also um einen Versuchsballon für das Rollout von Drive-By-Downloads handeln.
- Der Programmierer grüßt den französischen Hacker Xylitol, der in letzter Zeit viele Malware-Samples analysiert hat und sich damit bei den Malware-Entwicklern unbeliebt gemacht hat:

Auch das spricht dafür, dass der Entwickler der Malware sich sicher fühlt.
- Es werden drei Verbindungen zum C&C-Server aufgemacht. Dabei finden wahrscheinlich folgende Schritte statt: a) Es wird eine Installationskennung/ID übermittelt. b) Es werden die Bilddateien heruntergeladen c) Es wird ein kleines Datenpaket heruntergeladen, das meiner Ansicht nach ein public Key sein könnte.
- Nicht zuletzt ist das Public-Key Verfahren das für diese "Geschäftsidee" einzig sinnvolle Verfahren, da es von Außen nicht angreifbar ist.
- Es wäre nicht erstaunlich, wenn das Public-Key Verfahren bei diesem Virus ohne Logik-Fehler eingesetzt wird, denn schließlich ist dieses Anfriffsszenario schon länger denkbar und ich habe ein in dieser Hinsicht sehr erhellendes Paper gefunden, bei dessen Lektüre mir bewußt wurde, mit was wir es hier sehr wahrscheinlich zu tun haben: Einer 1zu1-Implementation dieses Angriffes!
Die Autoren gehen nicht auf die Möglichkeit einer Entschlüsselung ein (da es diese nicht gibt!), die einzige Möglichkeit, sich zu schützen ist Vorbeugung:

A solid defense against a cryptoviral extortion attack is to have backups of the plaintext that could potentially be attacked. Regular backups that are periodically verified should be considered. Other countermeasures include having a strong defense against malicious software. This includes but is not limited to: a firewall, a resident antiviral program, and an intrusion detection service. Antivirus updates should be obtained regularly and full malware scans should be conducted routinely. Executable software should only be obtained from reliable sources. It should be noted that by storing user files in encrypted form, protection against cryptoviral extortion is not necessarily achieved. The encryption of an encryption will serve the user no good when the outer layer annot be deciphered.

Update [31.05.2012]: Ganz so schlecht sieht es doch nicht aus. Ich habe in den letzten Tagen einige Memory-Dumps angeschaut und da sind zumindest keine Public-Keys zu finden. Ich denke, das hier Marcu wohl mit seiner Aussage "Die Hoffnung nicht aufgeben" recht hat und es sich noch immer um eine symmetrische Verschlüsselung handelt. Wie und wo die Schlüssel berechnet werden, muss herausgefunden werden.

1) CTFMON will ins Internet (soso ...)



2) CAPI imports, also breakpoints auf ADVAPI32 setzen (CryptAcquireContext, CryptGenKey, CryptEncrypt, CryptDecrypt ...) vgl.: M$



3) Wenn man den Trojaner nun laufen läßt, versucht er wie oben beschrieben, eine Verbindung mit dem C&C-Server aufzubauen und sobald er von diesem Daten erhalten hat, fängt er mit der Verschlüsselungsroutine an.

Ich vermute dabei, dass er zunächst die "Bilddateien" entschlüsselt, eventuell mit diesem Schlüssel hier: "732jjdnbYYSUUW7kjksk***ndhhssh".



Update: Den Schlüssel findet man auch im Memdump eines infizierten Rechners, der ab Infektion keine Internetverbindung hatte. Dieser Schlüssel oder was es auch sein mag, ist somit sicher statisch und hart im Trojaner eincodiert:



Update [31.05.2012]: Der statische Teilschlüssel wird offenbar mit einem weiteren dynamischen Teil kombiniert:



Dann legt er im %temp% Verzeichnis eine 2 KByte Datei an (Vermutung: Diese Datei ist auch im Bildpaket enthalten):



Später kommen hier noch mehrere weiter Dateien dazu, die unter Umständen die alten Dateinamen referenzieren. Was aber in der 2KByte-Datei steht, ist mir bisher unklar. Wenn es sich hierbei um einen Schlüssel für symmetrische Verschlüsselung handelt, hätten wir noch mal Glück gehabt. Denkbar wäre aber auch, dass hier nur ein Schlüssel für die Verschlüsselung der Referenzdateien (Dateinamen) handelt, der dann statisch wäre. Das würde dann für die Entschlüsselung beim PP-Key Verfahren nicht helfen. Diese Datei bedarf aber noch genauerer Analyse.

Dann gehts los und der Trojaner verbindet sich abermals mit dem CC-Server, z.B.:

hxxp://ogutors-free.com/a.php?id=8C20AF3F4B435546464F&cmd=lfk&ldn=35&stat=CRA&ver=1.170.1&data=MON1xEF944FhyhIF7GcaNYG29T6Zf lvjVTFc2zKPPP8VnTIA

Und bekommt hier meiner Ansicht nach einen public Key übergeben, wobei das Kommando "lfk" für "load full key" stehen könnte. Dann beginnt die eigentliche Verschlüsselung, 3000 Bytes in 3000 Bytes out.

Beim debuggen sind mir Referenzen zum Enhanced Cryptographic Provider ins Auge gefallen, auch das spricht leider für keine schnelle Lösung:



- Weitere Analysen / Screenshots usw folgen.

Updates [31.05.2012]:

Definition 3000byte / %temp%-Dateien / möglicher Beginn der Verschlüsselung


Verschlüsselte Daten in Datei schreiben:


Dateiliste für Verschlüsselung:


Loop durch die Datei / Schlüssel-Liste (wichtig: Vermutlich existieren alle dynamischen & statischen Schlüssel hier schon und sind im Memory-Dump zu finden):


Hier ein kleiner Ausschnitt eines Memdumps. Es läßt sich eine Zuordnung erkennen (vermute, es sind): Dateiname inkl. Pfad / neuer Dateiname inkl. Pfad / dynamischer Schlüssel:


Updates [03.04.2012]:

Wenn die bisherigen Analysen stimmen, sieht es so aus, als ob ich mit meiner Vermutung leider zum Teil Recht hatte und die Verschlüsselten Daten nicht ohne Weiteres entschlüsselt werden können. Der Trojaner nutzt demnach zwar keine asymmetrische Verschlüsselung, was prinzipiell die sicherste Variante wäre, aber er überträgt einen Teil des zur Verschlüsselung genutzten Keys (Basiskey) an den CC-Server. Wenn der Schlüssel nicht auf dem Computer des Opfers zwischengespeichert wird und der Schlüssel mit Zufallsdaten erzeugt wird (wovon sicherlich auszugehen ist), gibt es keine Möglichkeit mehr, den Schlüssel zu errechnen. Die Einzige Möglichkeit wäre somit, darauf zu hoffen, dass die Strafverfolgungsbehörden zugriff auf die Datenbank der CC-Server bekommen: Sehr unwahrscheinlich!



Hier wird der Basekey erzeugt:


Dieser wird dann an den CC-Server übermittelt:


Dann beginnt die Verschlüsselung auf Grundlage des Basekeys. McAfee hat das Vorgehen des Trojaners ebenfalls analysiert und in einer anschaulischen Grafik dargestellt:



Hier heißt es:

The random base key is encrypted using RC4 and the key used is an MD5 checksum of the data, consisting of the serial number of boot drive volume concatenated with the first six characters of the computer name and another hard-coded string. The ciphered data is passed to another encryption routine and the returned value of this routine along with the volume’s serial number followed by the computer name are passed in the query string of the HTTP request as “data” and “id,” respectively.

Quelle: Ransomware holds up victims

Nicht auf ein PP-Verfahren zu setzen hat in meinen Augen vor allem den Vorteil, dass bei den CC-Servern keine Rechnerressourcen "verschwendet" werden. Auch ist die Vorhaltung von PP-Key Kombinationen minimal aufwändiger als eine Datenbank mit der Installationskennung->Basekey. Man sieht also, die Malware-Programmierer sind keine Skript-Kiddies, das Konzept von diesem Trojaner ist gut durchdacht.

Das Einzige, was mir bisher noch nicht ganz klar ist, was in der 1kb-Datei im %temp%-Verzeichnis steht. Da diese aber vor Generierung des Basekeys erstellt wird, dürfte sich auch hier kein Schlüssel mehr finden.



Zusammenfassend läßt sich wohl sagen, dass wir es nun mit einer neuen Eskalationsstufe in Sachen Malware zu tun haben. Die einzige Möglichkeit sich hiergegen zu schützen heißt von nun an auch für Privatpersonen tägliche Backups aller wichtigen Datenbestände auf verschiedene Medien!

Referenzen/Links:

- Entschlüsselungsroutine, die Marcu gefunden hat, für den Fall, dass es doch symmetrisch ist
- Using Symmetric Encryption with Microsoft's CryptoAPI
- CryptoAPI Tracer script
- Cryptography Functions
- Microsoft Enhanced Cryptographic Provider
- Delphi-Praxis: Verschlüsselungs-Trojaner, Hilfe benötigt
- Trojaner-Board: Neue Verschlüsselungs-Trojaner Variante im Umlauf
- Asymmetrisches Kryptosystem
- Cryptovirology Labs
- An Implementation of Cryptoviral Extortion Using Microsoft’s Crypto API? Adam L. Young and Moti M. Yung
- Von kleinen, fiesen Windowsrechnerkrabbeltierchen
- Ransomware holds up victims