PClock verwandelt Ihren WordPress-Blog in eine Malware-Kontrollzentrale

In den letzten fünf Monaten hat unser Malware-Analystenteam die Entwicklung der PClock-Ransomware-Familie verfolgt, die als eher einfache Kopie von CryptoLocker ihren Anfang nahm, aber eine enorme Entwicklung erfahren hat. In diesem Post möchten wir uns die technischen Aspekte der Verschlüsselung, die bei den neuesten Varianten zum Einsatz kommt, einmal genauer ansehen. Ebenso untersuchen wir, wie der Malware-Schöpfer mit Sicherheitslücken behaftete WordPress-Blogs mit Hilfe eines bösartigen WordPress-Plugins in C2-Server (kurz für „Command & Control-Server“) verwandelt.

Verschlüsselungsmodell

Kurz nachdem wir die allererste Version von PClock geknackt und ein Entschlüsselungsprogramm bereitgestellt hatten, wechselte der Malware-Schöpfer zu einem neuen Verschlüsselungsmodell. Dieses neue Modell kommt jetzt bei allen PClock-Varianten zum Einsatz. Es basiert auf einem Key pro Infektion, der während des ersten Ausführens durch Verknüpfung der Rückgabewerte verschiedener Windows-Funktionen erzeugt wird.

Teil der Funktion zur Erzeugung des Keys pro Infektion

Der String, der sich ergibt, sieht mehr oder weniger wie folgt aus:

12:15:19 PM 2416  3464  1376256  0  262292  65556  590762  65672

Mehrere Teile, die diesen String ausmachen, sind:

• Zeit, zu welcher der Key erstellt wurde
• Rückgabewert der GetCurrentThreadID-Funktion
• Rückgabewert der GetCurrentProcessID-Funktion
• Rückgabewert der GetProcessHeap-Funktion
• Rückgabewert der GetActiveWindow-Funktion
• Rückgabewert der GetClipboardOwner-Funktion
• Rückgabewert der GetDesktopWindow-Funktion
• Rückgabewert der GetForegroundWindow-Funktion
• Rückgabewert der GetShellWindow-Funktion

Die Endversion des Keys wird dann durch Hashen des String mit Hilfe des SHA-256-Algorithmus erzeugt. In diesem Fall würde dieser Key lauten: dbbff5ce8b1d8e58e28346b0ebbb9a70c7d04e05f10a803bff9539d4e6e044ed. Die Malware schickt dann diesen Key an ihren C2-Server. Sobald der Server meldet, dass der Key ordnungsgemäß abgespeichert wurde, beginnt die Malware sodann mit der Verschlüsselung der Dateien des Opfers.

Die Dateien werden in 16.384-Byte-Blöcken mit Hilfe des RC4-Algorithmus verschlüsselt. Jeder Block verfügt über einen eigenen Key, der wiederum durch Hashen eines Strings mit Hilfe des SHA-256-Algorithmus erzeugt wird. Jetzt enthält der String den Key, den vollständigen Dateipfad und den Blockindex. Falls zum Beispiel die Malware den ersten 16.384-Byte-Block einer Datei namens „C:\MyDocument.doc“ verschlüsselt, wäre der Key pro Block der SHA-256-Wert des Strings „dbbff5ce8b1d8e58e28346b0ebbb9a70c7d04e05f10a803bff9539d4e6e044edC:\MyDocument.doc1“. Für den zweiten Block der Datei würde sich der String zur Berechnung des Keys ändern zu „“dbbff5ce8b1d8e58e28346b0ebbb9a70c7d04e05f10a803bff9539d4e6e044edC:\MyDocument.doc2“ usw. Die Malware verschlüsselt jeden Block innerhalb des ersten Megabytes der Datei auf diese Weise. Danach wird nur jeder 17. Block der Datei verschlüsselt. Sollten weniger als 17 Blocks in der Datei verbleiben, wird nun jeder einzelne Block wieder verschlüsselt. Alle verbleibenden Bytes, die keinen vollständigen Block ergeben, werden ebenso mit einem Key verschlüsselt, der sich aus dem Key pro Infektion und dem Dateinamen ableitet, wobei die Blocknummer aus der Gleichung herausfällt.

Defekter Unicode-Umwandlungscode, der vom SHA-256-Baustein der Malware verwendet wird

Ein interessanter Aspekt des SHA-256-Bausteins der Malware ist die Tatsache, dass dabei offensichtlich ANSI-Strings Verwendung finden. Viele nicht englischsprachigen Nutzer haben Dateien auf ihrem System, deren Dateinamen Zeichen aufweisen, die nicht zum normalen ANSI-Zeichensatz gehören. PClock selbst verwendet intern durchgehend Unicode-Strings. Anstatt die Strings korrekt von Unicode in ANSI zu konvertieren, macht die Malware jedes Unicode-Zeichen zu einem ANSI-Zeichen, sodass das Higher-Level-Byte des Unicode-Zeichens fallen gelassen wird.

Nach Verschlüsselung der Dateien löscht die Malware sicher den Key pro Infektion aus dem System des Opfers, sodass nur auf dem C2-Server der Malware eine Kopie davon verbleibt, mit Hilfe derer die Dateien des Opfers entschlüsselt werden können.

Der C2-Server von PClock

Angesichts der Komplexität des neuen Verschlüsselungsmodells von PClock fragen Sie sich sicher, wie wir überhaupt Dateien entschlüsseln konnten. Die Antwort ist einfach: Der Malware-Schöpfer nutzte kompromittierte Webserver zum Hosting seiner C2-Server. Das mag wohl eine kostengünstige Art und Weise zur Unterhaltung einer Malware-Kampagne sein, aber es gibt ein paar Nachteile. Zunächst haben Sie nicht zwangsläufig Zugriff auf den gesamten Server, sodass Sie möglicherweise nicht in der Lage sind, die unsichere Konfiguration zu beheben, durch welche Sie zunächst einmal erst überhaupt in den Server gelangen konnten. Jedoch könnte die Software Ihres C2-Servers Malware-Analysten wie uns in die Hände geraten, die dann sich das Ganze einmal genauer ansehen.

Die allerersten Varianten mit dem neuen Verschlüsselungsmodell setzten auf ein einfaches C2-PHP-Script, das nicht überprüfte, ob man auch wirklich bei Anfrage des Entschlüsselungskeys bezahlt hatte. Unser Freund Nathan bei BleepingComputer machte sich diesen Fehler zur Bereitstellung eines kleinen Patchprogramms zu Nutze, wodurch der Malware vorgegaukelt wird, der Nutzer habe bezahlt, und diese sodann den C2-Server um den Key zur Entschlüsselung der Dateien des Opfers anfragt. Der Malware-Schöpfer aktualisierte recht schnell die serverseitigen Scripts, um sicherzugehen, dass der Nutzer auch wirklich bezahlt hat:

Zahlungsprüfung, um welche der Malware-Schöpfer neueren Versionen seiner Command & Control-Scripte ergänzte

Das war jedoch nur einer von vielen Fehlern. Bei genauerer Untersuchung des Codes erkennt man, dass der Schlüssel aus dem Unterverzeichnis „Keys“ ausgelesen wird. So konnten wir einfach die Dateinamen der Keys erraten und sie direkt herunterladen. Wir benötigten lediglich eine Liste der Bitcoin-Adressen, die von der Malware erzeugt wird, die der Malware-Schöpfer uns freundlicherweise auf dem Server in Form einer öffentlich zugänglichen Logdatei namens „filescount.log“ hinterließ:

Einige Beispiele für Einträge aus der öffentlich zugänglichen Logdatei des C2-Servers der Malware, mit der IP-Adresse des Opfers, der zugewiesenen Bitcoin-Adresse und der Anzahl der verschlüsselten Dateien

Wir brauchten lediglich ein paar Minuten, um ein kleines Script aufzusetzen, mit Hilfe dessen wir die Logdatei herunterluden, alle erzeugten Bitcoin-Adressen daraus auslasen und die entsprechenden Keys herunterluden, ohne das C2-Script des Malware-Schöpfers zu verwenden. Dieser bemerkte, dass wir irgendwie in der Lage waren, den Opfern weiterhin bei der Entschlüsselung zur Seite zu stehen. Daher entschied er sich dazu, die Namen der Keydateien noch zufälliger zu gestalten. Bei prüfendem Blick auf den Auszug aus dem Script unten erkennt man, dass die Dateinamen im Ordner „Keys“ aus zwei Teilen bestehen: Die Variable „$wallet“, welche grundlegend die Adresse des Bitcoin-Wallet enthält, an welche das Opfer die Zahlung senden soll, sowie eine Variable namens „$SALT“. Ein sog. „Salt“ sind in der IT üblicherweise zufällige Daten, welche es schwieriger machen, das Ergebnis zu erraten. Stellen Sie es sich wie eine primitive Form eines Passwortes in diesem speziellen Fall vor. Zu unserem Glück sind auch Malware-Schöpfer Nutzer wie Sie und ich, die ab und zu auf schwache Passwörter setzen. In diesem speziellen Fall waren die Daten, auf denen die gesamte Sicherheit des C2-Servers des Malware-Schöpfers basierte, einfach „0000“:

„0000“ ist kein sicheres Passwort

Es versteht sich von selbst, dass es weniger als ein paar Sekunden in Anspruch nahm, das zu erraten, und somit eine weitere Malware-Variante geknackt war. Der Malware-Schöpfer versuchte dann, komplexere „Salts“ wie „80b5c1cc“ zu verwenden, um die Entschlüsselung zu erschweren. Glücklicherweise reagierte der Besitzer eines kompromittierten Servers auf unsere Nachricht, dass sein Server Teil einer Malware-Kampagne sei. Er war so nett, uns behilflich zu sein und uns eine Kopie aller serverseitigen Scripts des Malware-Schöpfers mitsamt aller Keys bereitzustellen, die auf seinem Server hinterlegt waren. So war es uns ein Leichtes, auch diese Malware-Varianten problemlos zu knacken.

Die Ruhe vor dem Sturm

In den nächsten Wochen herrschte erst einmal Ruhe. Wir knackten alle Varianten bis auf eine, da wir den C2-Server nicht rechtzeitig ausmachen und alle gespeicherten Verschlüsselungskeys abgreifen konnten. Da wir alle Bitcoin-Adressen kannten, die mit der Malware in Verbindung stehen, konnten wir uns von den ersten Varianten, die etwa insgesamt 4.000 Nutzer infizierten, ausgehend erschließen, dass weniger als fünf Nutzer das Lösegeld bezahlten. Im Ergebnis waren wir verhalten optimistisch, dass der Malware-Schöpfer an diesem Punkt einfach aufgeben würde. Wir lagen jedoch falsch.

Am 3. März, beinahe anderthalb Monate nach dem letzten PClock-Angriff, ging einem unserer Frühwarnsysteme, dass wir üblicherweise für neue Malware-Familien einrichten, eine neue PClock-Variante ins Netz. Ohne Umschweife extrahierten wir die neuen C2-Server-Adressen und probierten unsere vorhandenen Scripte zur Extraktion der Keys aus, jedoch ohne Erfolg. Weiter gehende Analysen ergaben, dass auf den Servern allesamt veraltete Versionen von WordPress liefen. Andere Server waren ebenso mit anderen bösartigen Bedrohungen infiziert. Bei Beobachtung der Kommunikationsprotokolle der Malware bemerkten wir ebenfalls, dass die Malware mit der WordPress-Instanz statt wie bisher einem dedizierten C2-Server-Script kommunizierte. Zu diesem Zeitpunkt war uns klar, dass der Malware-Schöpfer seine Taktik geändert hatte.

Einer unserer ersten Schritte bestand darin, bei einer kompromittierten Website zufällig gewählte Dateinamen auszuprobieren, um zu sehen, ob sie auf irgendetwas Nützliches verweisen, und wir hatten Glück. Das wussten wir damals nicht, aber der Malware-Schöpfer setzte in punkto Sicherheit seiner Operation wieder einmal auf ein einziges Passwort und zudem eines der denkbar schwächsten Passwörter:

QWERTY ist ebenso wenig ein gutes Passwort

Nachdem wir das offen zugängliche Verzeichnis „QWERTY“ entdeckt hatten, das jeder öffnen und woraus jeder herunterladen konnte, hatten wir erneut einen Weg gefunden, alle Keys aus dem C2-Server auszulesen. Uns war klar, dass der Malware-Schöpfer letzten Endes die Server wechseln würde, die uns die Arbeit wohl nicht mehr so einfach machen würden. Daher mussten wir als Absicherung eine andere Methode zum Auslesen der Keys finden. Wie sonst auch informierten wir die Besitzer aller Websites darüber, dass ihre Website als Kommandozentrale für eine Malware-Kampagne missbraucht wurde. Und wieder ging uns ein Website-Besitzer zur Hand.

WPUnitE verwandelt Ihren Blog in einen Malware-C2-Server

Wir wussten, dass das neue C2-Script, auf das der Malware-Schöpfer setzte, Teil einer WordPress-Installation war, weshalb wir umgehend die WordPress-Plugins überprüften. Mit WordPress können Besitzer von Websites ihre Blogs mit Plugins von Drittanbietern um zusätzliche Inhalte und Funktionen ergänzen, die über den Einsatzbereich der ursprünglichen WordPress-Software hinausgehen. Diese Plugins werden von WordPress immer dann geladen, wenn ein Zugriff auf den Blog erfolgt, und verfügen über so gut wie keine Einschränkungen. Beim Blick auf die installierten Plugins stach eines direkt hervor: WPUnitE 1.0, das angeblich von „WordPress“ stammte.

Bösartiges WPUnitE-Plugin in kompromittiertem WordPress-Blog

Der Quellcode des Plugins ist durch mehrere Eval-Ebene, GZip-Kompression und BASE64-Kodierung verschleiert. Nach Entfernen dieser Ebenen findet man ein kleines Script, dass alle Befehle verarbeitet, welche die Malware sendet:

Verschleierter Code des Malware-C2-Plugins

Bei diesem Plugin werden zwei Arten von Befehlen unterschieden: Beschränkte Befehle, die erst zugänglich sind, nachdem ein Passwort geliefert wurde, und unbeschränkte Befehle, die jedem bereitstehen. In dieser Version des Scripts war das Passwort wie bereits erwähnt „QWERTY“. Das Passwort wird ebenso vom C2-Plugin als Speicherort für alle gespeicherten Verschlüsselungskeys verwendet. Somit wird auch klar, wie wir zuvor dass offen zugängliche Verzeichnis /QWERTY/ ausfindig machen konnten.

Die beschränkten Befehle lauten:

• CHECK Mit diesem Befehl wird eine einfache Selbstprüfung durchgeführt, um das Plugin auf ordnungsgemäße Funktion und Möglichkeit zur Speicherung der erhaltenen Verschlüsselungskeys zu testen.
• GET_STATE Mit diesem Befehl werden alle gespeicherten Keys angenommen und an den Client in Serienform und BASE64-kodiertem Format zurückgegeben.
• SET_STATE Mit diesem Befehl wird eine Liste in Serienform und BASE64-kodiertem Format der Keys angenommen und auf dem Server gespeichert. Der Malware-Schöpfer nutzte GET_STATE und SET_STATE sehr wahrscheinlich zur Synchronisierung der Verschlüsselungskeys zwischen allen C2-Servern. Früher gingen Keys verloren, und die Dateien konnten nicht mehr entschlüsselt werden, wenn der C2-Server vom Netz genommen wurde. Durch diesen Ansatz kann der Malware-Schöpfer eine Sicherung aller erzeugten Keys vorhalten und an neue C2-Server senden, nachdem einer vom Netz genommen wurde.

Die ohne Passwort zugänglichen Befehle werden ausschließlich von der Malware verwendet und lauten:

• PING PING nutzt die Malware zum Senden der erzeugten Bitcoin-Adresse, des erzeugten verschlüsselten Keys und der Anzahl der verschlüsselten Dateien an den C2-Server.
• GET_KEY Dieser Befehl kommt zum Einsatz, nachdem das Opfer das Lösegeld zum Erhalt des Entschlüsselungskeys bezahlt hat, mit Hilfe dessen seine Dateien wieder entschlüsselt werden können. Hier erfolgt eine ähnliche Überprüfung, um sicherzustellen, dass wirklich bezahlt wurde, bevor die Keys gesendet werden.

Da wir wussten, wie das C2-Plugin funktioniert, schrieben wir unser eigenes kleines Client-Script, das mit dem Befehl „GET_STATE“ alle gespeicherten Verschlüsselungskeys von allen C2-Servern auslesen konnte.

Zu diesem Zeitpunkt veröffentlichte in beinahe wöchentlichem Rhythmus der Malware-Schöpfer neue Varianten mit neuen C2-Servern, ohne zu wissen, dass wir die Verschlüsselungskeys von den C2-Servern auslesen konnten. Er musste in der Annahme sein, dass wir die Server auf gleiche Weise wie er hackten, da er die WordPress-Blogs, die er infiltriert hatte, aktualisierte, um alle Sicherheitslücken zu schließen, die uns Zugriff auf die Website und die dort gespeicherten Keys gegeben hätten. In Wahrheit kannten wir sein Passwort und C2-Interface, weshalb wir die allergleichen Methoden zum Einsatz brachten, mit denen er Sicherungen der Keys für sich anlegte.

Passwörter ändern

Leser unseres Blogs wissen, dass wir im Gegensatz zu unseren Konkurrenten niemals öffentlich Informationen preisgeben, mit Hilfe derer Malware-Schöpfer ihre Werke verbessern könnten. Lieber behalten wir Fehler, auf die wir stoßen, für uns und teilen sie nur privat mit anderen Malware-Analysten, sodass wir alle diese Fehler dazu nutzen können, vielen Ransomware-Opfern auf lange Zeit zu helfen. In Anbetracht dessen verwundert es nicht, dass der Malware-Schöpfer letztlich einen Weg fand, um uns auszusperren. Am 21. April tauchten neue PClock-Varianten auf, bei denen C2-Servern verwendet wurden, mit welchen unser angepasster Client nicht kommunizieren konnte. Es stellte sich heraus, dass er wohl bemerkt haben musste, dass wir sein „sicheres“ Passwort die ganze Zeit gekannt hatten und in der Tat die allergleichen Befehle einsetzten, die er zur Erstellung seiner Sicherungen verwendete. Daraufhin änderte er das Passwort. Zu seinem Pech sind wir die Guten, die sich nicht zu verstecken brauchen. Wir baten den Besitzer der Website, uns freundlicherweise eine Kopie des bösartigen C2-Plugins zuzusenden, was dieser wie zuvor bereitwillig tat. Wir gelangten auch an das neue Passwort („9eba6538“), und so ging das Spiel weiter. Leider veröffentlichte der Malware-Schöpfer am 28. April noch eine neue Variante seiner Kreation mit einer aktualisierten Version seines C2-Plugins.

WPUnitE Version 2.0

Wie bei früheren Versionen kommen bei Version 2.0 des C2-Plugins ähnliche Verschleierungstaktiken zum Einsatz. Jedoch haben sich die meisten privaten Befehle geändert:

Funktion zum Parsen von Befehlen des WPUnitE 2.0-C2-Plugins

Zunächst einmal wird das Passwort nicht mehr als Klartext gespeichert. Stattdessen wird es als MD5-Hash gespeichert („7afd6de416cfd1427262d380ef1d4c33“). Die Befehle „GET_STATE“ und „SET_STATE“ gehören der Vergangenheit an. Jetzt gibt es die neuen Befehle „GET_CLIENTS“, „GET_ORDERS“ und „SET_KEY“, die allesamt Passwortauthentifizierung erfordern. „GET_CLIENTS“ ersetzt „GET_STATE“. Hiermit wird im Grunde eine Liste aller Keys auf dem Server in Serienform und mit BASE64-Kodierung zurückgegeben. Im Gegensatz zu „GET_STATE“ werden bei „GET_CLIENTS“ jedoch alle Keys nach dem Export gelöscht. So kann keine Sicherung aller Keys mehr abgegriffen werden. Man hat lediglich alle Keys, da die letzte Sicherung exportiert wurde. Auf Grundlage der gefundenen Logs schlossen wir, dass der Malware-Schöpfer automatisch die Keys alle 5 Minuten über eine Tor-Verbindung exportiert.

Für die neueste PClock-Variante gibt es kein Heilmittel

Wenn der C2-Server nicht mehr über die Keys verfügt, wie erhalten dann die Opfer, die sich zur Zahlung des Lösegeldes entschlossen haben, aber ihren Key? Hierin liegt der Zweck von „GET_ORDERS“ und „SET_KEY“. Bei Zahlung des Lösegeldes kontaktiert die Malware den C2-Server über den Befehl „GET_KEY“ wie bei früheren Versionen. Mit „GET_KEY“ wird dann geprüft, ob der Key sich auf dem Server befindet, und falls nicht, wird eine „Order“ für den Key erstellt und die Malware auf später vertröstet. Diese „Order“ lassen sich mit Hilfe der Funktionen „GET_ORDERS“ wie Keys exportieren. Sobald der Malware-Schöpfer geprüft hat, dass das Lösegeld gezahlt wurde, hinterlegt er mit der Funktion „SET_KEY“ den korrekten Key wieder auf dem Server. Sobald die Malware erneut um den Entschlüsselungskey anfragt, wird mit GET_KEY der Key abgerufen und die Dateien entschlüsselt.

Da die Keys nicht mehr auf dem Server gespeichert werden, können wir sie leider nicht mehr auslesen. Nach beinahe vier Monaten gelang es dem Malware-Schöpfer endlich, uns auszusperren.

Wie können Sie sich selbst schützen?

Wir können es nicht oft genug sagen, Vorsicht ist besser denn Nachsicht. Wenn Sie Emsisoft nutzen, so können Sie beruhigt sein, denn alle PClock-Varianten wurden von der Verhaltensanalyse in Emsisoft Anti-Malware und Emsisoft Internet Security blockiert. Emsisoft-Kunden waren zu keinem Zeitpunkt dem Risiko einer potenziellen PClock-Infektion ausgesetzt.

Neue PClock-Variante wird von der Verhaltensanalyse von Emsisoft blockiert

Sollten Sie einen WordPress-Blog ihr Eigen nennen und möchten verhindern, dass dieser von Malware-Schöpfern missbraucht wird, so raten wir Ihnen an, sowohl WordPress und Ihre Plugins stets auf dem neuesten Stand zu halten. Darüber hinaus ist es enorm wichtig, dass alle, die darauf Zugriff haben, sichere Passwörter verwenden. In mindestens einem bestimmten Fall erlangte der Malware-Schöpfer unseres Wissens Zugriff auf den Blog auf Grund eines schwachen Administratorpasswortes.

Zu guter Letzt möchten wir unseren Dank unseren Freunden bei BleepingComputer aussprechen sowie den Besitzern der gehackten Websites, die wohlwollend auf unsere Nachrichten reagiert und uns mit Rat und Tat zur Seite gestanden haben.

Wie immer wünschen wir Ihnen eine schöne Zeit (ohne Ransomware)!