Was steckt hinter der Sodinokibi-Ransomware

In letzter Zeit wurde oft über die Ransomware-Attacke Sodinokibi berichtet, doch die technischen Details für diese spezielle Form der Erpressungs-Software fehlten bislang. In diesem Artikel sezieren wir Sodinokibi, beleuchten die Funktionsweise und zeigen, wie Sie Ihr System vor dieser Bedrohung schützen können.

Recherchiert und geschrieben von Ravikant Tiwari und Alexander Koshele

• Sodinokibi wird wahrscheinlich von Angreifern verbreitet, die mit den Entwicklern der berüchtigten GandCrab-Ransomware-Familie in Verbindung stehen. Darknet-Foren zufolge soll GandCrab bald in den Ruhestand geschickt werden.
• Sodinokibi-Ransomware nutzt eine Schwachstelle in Oracle WebLogic (CVE-2019-2725) aus, um Zugang zum Rechner des Opfers zu erhalten. 
• Sodinokibi versucht die Infektion von Computer im Iran, in Russland und in Ländern, die früher zur UdSSR gehörten zu vermeiden.
• Diese Lösegeldforderung verwendet AES- und Salsa20-Algorithmen. AES wird zur Verschlüsselung von Sitzungen und Daten verwendet, die an den Steuerserver gesendet werden. Benutzerdateien werden mit Salsa20 verschlüsselt. 
• Sodinokibi verwendet einen Diffie-Hellman-Schlüsselaustausch-Algorithmus auf der Basis elliptischer Kurven, um die Verschlüsselung zu erzeugen und zu verbreiten. 
• Sobald es in einen Rechner eindringt, löscht es alle Dateien im Backup-Ordner. 
• Derzeit verlangt die Software ein Lösegeld in Höhe von 0,32806964 BTC (entsprechend ca. 2.500 US-Dollar). Mit der Zahlung erhalten Betroffene wieder Zugriff auf die verschlüsselten Dateien. Die Angreifer behaupten, dass sich dieser Betrag verdoppelt, wenn nicht innerhalb von vier Tagen bezahlt wird.

Die Sodinokibi-Ransomware, die wir für diesen Artikel analysierten, wurde mit einem speziellen Packer behandelt. Selbst nach erfolgreichem Entpacken scheint der Sodinokibi-Hauptcode kaum eine lesbare Zeichenketten zu enthalten. Er hat auch keine Importfunktionen für Systembibliotheken und APIs. Statische Antiviren-Scanner, die nach lesbaren Zeichenketten und importierten API-Tabelle suchen, werden daher Schwierigkeiten haben, diese zu erkennen.

Namen vom APIs und andere erforderliche Zeichenketten werden während der Laufzeit mit dem RC4-Algorithmus entschlüsselt. Damit sich die Sache für Antiviren-Software noch schwieriger gestaltet, werden die meisten Operationen an Zeichenketten mit einem DJB-Hash der Zeichenkette statt der Zeichenkette selbst durchgeführt.

Sodinokibi beginnt mit dem Aufbau einer dynamischen Importtabelle und stellt mit Hilfe von wechselseitigen Ausschlüssen (Mutexes) sicher, dass dies die einzige Instanz ist, die derzeit auf dem System läuft. Sobald die Mutex-Prüfung absolviert ist, entschlüsselt sie die in der Binärdatei gespeicherte JSON-Konfiguration mit RC4 und prüft auf den booleschen Schlüsselwert „exp“. Ist dieser auf „true“ gesetzt, versucht Sodinokibi, einen Exploit auszuführen. In unserem Fall wird der Wert des Schlüssels „exp“ auf „true“ gesetzt, so dass die Exploit-Funktion ausgeführt wird.

Abbildung 1: Entschlüsselte JSON-Konfiguration

Der Code für die Ausführung des Exploits prüft zunächst, ob der Patch vom 11. September 2018 (KB4457138) auf dem Rechner installiert ist. Dieser Patch behebt mehrere der unten genannten Sicherheitslücken. Wird der Patch nicht gefunden, führt die Ransomware (je nach Plattformarchitektur) mit der 32- oder 64-Bit-Version des Shellcodes aus. Wir sind der Überzeugung, dass dabei versucht wird, die Privilegien durch den Exploit von CVE-2018-8440 zu steigern.

Abbildung 2: Schnipsel 

Die Schwachstellen, die durch Patch KB4457138 behoben werden, sind in der folgenden Tabelle aufgeführt:

Bietet das System der Ransomware keinen Exploit nicht anfällig ist und läuft die Ransomware immer noch als Nutzer-Prozess mit eingeschränkten Rechten, startet ein RUNAS-Befehl eine weitere Instanz mit Administrator-Rechten und beendet die aktuelle Instanz mit den Nutzer-Rechten. Der vollständige Ablauf ist aus dem untenstehenden Code ersichtlich.

Abbildung 

Konnte sich Sodinokibi erfolgreich im Admin-Modus starten, führt es eine zusätzliche Vorprüfung hinsichtliches des „bro“-Schlüssels in der JSON-Konfiguration und hinsichtlich des Landes durch. Basierend auf der Ländereinstellung des Computers wird versucht, Computer aus den folgenden Ländern nicht zu infizieren.

Abbildung 4: Übereinstimmende Sprach-ID

Exempted Countries list

Nach den erfolgreichen Vorprüfungen wird der Prozess mysql.exe, falls er läuft, beendet. Dadurch erhält die Ransomware den Zugriff zur Verschlüsselung auf die MySQL-Dateien. Es werden dann alle Windows-Schattenkopien (dies ist ein in Windows eingebauter Backup-Mechanismus) gelöscht mit vssadmin und deaktiviert die Windows-Wiederherstellung mit bcdedit (Boot-Richtlinien-Editor) wie unten gezeigt:

vssadmin.exe Delete Shadows /All /Quiet & bcedit /set {default} recoveryenabled No & bcedit /set {default} bootstatuspolice ignorealfailure

Abbildung 5

Bevor Benutzerdateien verschlüsselt werden, durchsucht Sodinokibi das gesamte Dateisystem und die Netzwerkfreigaben nach allen Verzeichnissen mit dem Namen „Backup“ und löscht diese. Interessanterweise überschreibt Sodinokibi vor dem Löschen aller Dateien in diesem Verzeichnis den Inhalt mit zufälligen Bytes. Damit soll eine Wiederherstellung der Dateien unmöglich gemacht werden. Glücklicherweise können Acronis-Backup-Dateien nicht einfach gelöscht werden, da sie mit Kernel-Mode-Treibern geschützt sind. Dieses Verfahren von Acronis Backup soll die unerlaubte Löschung durch Ransomware vereiteln.

Sodinokibi verwendet einen Diffie-Hellman (ECDH)-Algorithmus mit elliptischer Kurve zur Schlüsselgenerierung und zum Schlüsselaustausch und erzeugt eine Private.Key/Public-Key-Schlüsselpaar. Es verwendet diesen, um ein so genanntes „gemeinsames Geheimnis“ zu erzeugen. Das dient wiederum als Schlüssel für die symmetrischen Verschlüsselungsalgorithmen AES und Salsa20 zur Verschlüsselung verschiedener Arten von Daten.

• Die AES-Verschlüsselung wird verwendet, um den privaten Teil des Private-Public-Keys, das sich lokal auf dem Rechner des Benutzers befindet, aber auch über das Netzwerk gesendeten wird, zu verschlüsseln.
• salsa20 hingegen wird zur Verschlüsselung von Benutzerdateien verwendet.

Sodinokibi kommt mit zwei verschiedenen öffentlichen Schlüsseln. Einem ist Teil der JSON-Konfiguration und ein weiterer ist in den Binärcode selbst eingebettet. Diese Schlüssel werden als Public-Keys zur Verschlüsselung des lokalen Private-Keys verwendet. Im Folgenden werden die Schlüsselgenerierung und der Verschlüsselungsprozesses beschrieben.

Schritt 1: Erzeugen es Schlüsselpaar aus einem privaten (geheimen, zufälligen Zahlen) und einem öffentlichen Schlüssel auf dem lokalen Rechner

Abbildung 6: Generierung lokaler öffentlicher und privater Schlüsse

Verschlüsselung des privaten Schlüssels aus Schritt 1 mit dem in der JSON-Konfiguration vorhandenen öffentlichen Schlüsse

Schritt 2: Erzeugen eines weiteren Public-Private-Schlüsselpaares.

Schritt 3: Verwenden des privaten Schlüssel aus Schritt 2 und des öffentlichen Schlüssels (pk-Schlüsselwert) von JSON, um einen gemeinsam genutzten Schlüssel zu erzeugen und diesen zur Erzeugung eines symmetrischen Schlüssels zu hashen.

Abbildung 7: Generierung eines symmetrischen Schlüssels unter Verwendung eines gemeinsam genutzten Schlüssel

Schritt 4: Erzeugen eines 16-Byte-IV (Initialisierungsvektors).

Schritt 5: Verschlüsseln des in Schritt 1 erzeugten privaten Schlüssel mittels AES-Verschlüsselung mit dem in Schritt 3 und 4 erzeugten Schlüssel und IV.

Schritt 6: Berechnen von CRC32 des in Schritt 5 erzeugten verschlüsselten privaten Schlüssels.

Schritt 7: Anfügen von IV und CRC32 am Ende des Puffers, der den verschlüsselten privaten Schlüssel aus Schritt 5 enthält.

Schritt 8: Speichern dieses Puffers in einer als „sk_key“ markierten Mapping-Datei im Speicher.

Abbildung 8: Verschlüsselung des privaten Schlüssels aus Schritt eins mit den öffentlichen Schlüsseln des Angreifers

Verschlüsselung des privaten Schlüssels aus Schritt 1, unter Verwendung des öffentlichen Schlüssels, der in der Binärdatei eingebettet is

Schritt 9: Wiederholen Sie die Schritte 2 bis 7 unter Verwendung eines anderen öffentlichen Schlüssels, der in der Binärdatei für Schritt 3 eingebettet ist.

Schritt 10: Speichern Sie diesen Puffer in einem als "0_key" markierten Mapping-Datei-Offset im Speicher

Die Schlüssel sk_key, 0_key und pk_key werden in Abhängigkeit von den Zugriffsrechten jeweils in den folgenden Registrierungsschlüssel geschrieben.

HKLM\SOFTWARE\recfg\sk_key   OR    HKCU\SOFTWARE\recfg\sk_key

HKLM\SOFTWARE\recfg\0_key   OR   HKCU\SOFTWARE\recfg\0_key

HKLM\SOFTWARE\recfg\pk_key   OR   HKCU\SOFTWARE\recfg\pk_key

Abbildung 9: Verschlüsselter geheimer Schlüssel (gemeinsames Geheimnis) im Register

Generierung von Schlüsseln pro Datei für Salsa2

Schritt 11: Erzeugen eines neues Public/Private-Schlüsselpaars.

Schritt 12: Generieren eines gemeinsamen Schlüssels unter Verwendung des in Schritt 2 generierten öffentlichen Schlüssels für die Sitzung. Dieser wird für einen weiteren symmetrischen Schlüssel zur Verwendung bei der Salsa20-Schlüsselgenerierung gehasht.

Schritt 13: Richten Sie einen 256-Bit (32 Byte) Salsa20-Schlüsselstatus ein.

Schritt 14: Generieren Sie einen 8-Bit-IV für Salsa20-Schlüssel

Schritt 15: Generieren Sie einen Salsa20-Schlüssel

Schritt 16: Verwenden Sie diesen Salsa20-Schlüssel_Zustand für die Verschlüsselung von Benutzerdateien mit Salsa20-Verschlüsselung.

Abbildung 10: Generierung eines Salsa20-Schlüssels pro Date

Wiederholung der Schritte 11 bis 16 für jede Datei, die verschlüsselt werden soll.

Abbildung der Verschlüsselung und Entschlüsselung

Um zu verstehen, wie die Schlüssel generiert und zwischen dem Angreifer und der Maschine des Opfers übertragen werden, müssen wir anhand der folgenden Abbildung betrachten, wie der Diffie-Hellman-Algorithmus arbeitet.

Abbildung 11: Schlüsselaustausch bei Diffie-Hellman mit elliptischer Kurve (ECDH)

Sodinokibi-Verschlüsselungsverfahren im Detail

Abbildung 12: Verschlüsselungsprozess

Sodinokibi-Entschlüsselungsprozess im Detail

Der Prozess der Entschlüsselung erfordert die Kenntnis des privaten Schlüssels des Angreifers, der nicht öffentlich bekannt gegeben wird, so dass es nicht möglich ist, die Dateien wiederherzustellen.

Abbildung 13: Entschlüsselungsprozess (das Geheimnis des Angreifers ist der private Schlüssel des Angreifers)

Die vereinfachte Version, wie der Entschlüsselungsprozess der Benutzerdateien aussehen wird, ist in der folgenden Grafik dargestellt.

Abbildung 14 

Zum Verschlüsseln von Benutzerdateien verwendet Sodinokibi I/O-Completion-Ports. Dort legt die Ransomware mehrere Verschlüsselungs-Threads bis maximal zur doppelten Anzahl der auf dem Rechner vorhandenen Prozessorkerne an. Diese Threads werden dem erstellten I/O-Completion-Port zugeordnet. Die Threads verwenden die API-Funktion GetQueuedCompletionStatus und warten darauf, dass ein Completion-Paket an den I/O-Completion-Port in die Warteschlange gestellt wird. Dann fahren sie mit der Dateiverschlüsselung fort.

Sobald die Threads erstellt sind und auf E/A-Paketen warten, beginnt Sodinokibi mit der Durchnumerierung der Benutzerdateien auf allen lokalen Laufwerken und Netzwerklaufwerken mit Ausnahme von CDROM- und RAMDISK-Laufwerken. Dabei ordnet die Software Dateien und Order, die sich nicht unter den Ausnahmen befinden, dem I/O-Completion-Port zu. Dazu nutzt sie die Benutzerfunktion AddFileToIoCompletionPort und die API-Funktion PostQueuedCompletionStatus. Dabei wird ein ein E/A-Paket an die I/O-Completion-Ports geschickt. Dieses veranlasst den Thread, der an diesem I/O-Completion-Port wartet, seine Arbeit wieder aufzunehmen und die Dateiverschlüsselung fortzusetzen. AddFileToIoCompletionPort erzeugt auch einen eindeutigen Salsa20-Schlüssel für jede zu verschlüsselnde Datei. Dieser Salsa20-Schlüssel wird an den Verschlüsselungs-Thread als Teil einer Struktur übergeben, die weitere Metadaten enthält. Die Metadaten werden nach der Verschlüsselung mit dem lpOverlapped-Parameter im API PostQueuedCompletionStatus ebenfalls in die Datei geschrieben. Während der Durchnumerierung wird auch eine Ransomware-Benachrichtigung in allen Ordnern erstellt, die nicht unter die Ausnahmeliste fallen. Sobald keine Dateien mehr übrig sind, wartet der Hauptthread in einer Schleife, bis die Gesamtzahl der verschlüsselten und umbenannten Dateien gleich der Gesamtzahl der Dateien ist, die dem I/O-Completion-Ports zur Verschlüsselung hinzugefügt wurden.

Schließlich setzt die Ransomware ein Flag, dass keine Dateien mehr durchzunumerieren sind und postet mehrere E/A-Vervollständigungspakete. Dadurch nehmen alle weiteren Threads, die auf Dateien warten, ihre Arbeit wieder auf. Zugleich wird die Ausführung der Ransomware sofort beendet.

Abbildung 1

Exempted Folders

• "$windows.~bt"
• "intel"
• "program files (x86)"
• "program files"
• "msocache"
• "$recycle.bin"
• "$windows.~ws"
• "tor browser"
• "boot"
• "system volume information"
• "perflogs"
• "google"
• "application data"
• "windows"
• "programdata"
• "windows.old"
• "appdata"
• "mozilla"

Exempted Files

• "bootfont.bin"
• "boot.ini"
• "ntuser.dat"
• "desktop.ini"
• "iconcache.db"
• "ntldr"
• "ntuser.dat.log"
• "thumbs.db"
• "bootsect.bak"
• "ntuser.ini"
• "autorun.inf"

Exempted File extensions

• "themepack"
• "ldf"
• "scr"
• "icl"
• "386"
• "cmd"
• "ani"
• "adv"
• "theme"
• "msi"
• "rtp"
• "diagcfg"
• "msstyles"
• "bin"
• "hlp"
• "shs"
• "drv"
• "wpx"
• "deskthemepack"
• "bat"
• "rom"
• "msc"
• "lnk"
• "cab"
• "spl"
• "ps1"
• "msu"
• "ics"
• "key"
• "msp"
• "com"
• "sys"
• "diagpkg"
• "nls"
• "diagcab"
• "ico"
• "lock"
• "ocx"
• "mpa"
• "cur"
• "cpl"
• "mod"
• "hta"
• "exe"
• "icns"
• "prf"
• "dll"
• "nomedia"
• "idx"

Der Verschlüsselungs-Thread kümmert sich um das Lesen des Dateiinhalts, die Verschlüsselung, das Zurückschreiben in die gleiche Datei und das Schreiben von Metadaten. Diese enthalten den verschlüsselten Session Private Key enthalten, je Datei den ECDH Public Key und den Salsa20-Schlüssel, die zum Verschlüsseln der Dateien verwendet wurden. Außerdem kümmert er sich um das anschließende Umbenennen durch Anhängen einer zufällig generierten Dateinamen-Erweiterung. Die Dateien werden mit dem Verschlüsselungsalgorithmus Salsa20 (Chacha-Variante) innerhalb der Benutzerfunktion EncryptAndWrite verschlüsselt.

Der Screenshot unten zeigt den Code für die Benutzerfunktion EncryptingThreadRoutine.

Abbildung 16

Abbildung 17: Struktur einer verschlüsselten Datei

Nachdem der Verschlüsselungsprozess abgeschlossen ist, bereitet die Ransomware die Daten für die Übermittlung an den Steuer-Server vor. Diese Daten enthalten verschiedene Felder aus der JSON-Konfiguration, Systeminformationen und die Schlüssel für die Verschlüsselung. Die vorbereiteten Daten werden auch in der Registry  unter „[HKLM|HKCU]\SOFTWARE\recfg\stat“ gespeichert, bevor sie mit AES verschlüsselt und an den Server des Angreifers gesendet werden.

Abbildung 18: Über das Netzwerk gesendete Daten

Die Informationen werden an eine zufällig generierte URL gesendet, die in der Form

where:

Abbildung 19: URL-Generierung

Sodinokibi enthält eine Vorlage seiner Lösegeldforderung mit Platzhaltern für benutzerspezifische Details. Diese Platzhalter werden dynamisch durch den benutzerspezifischen Erweiterungsnamen, die Benutzer-ID (uid – siehe Beschreibung in der obigen Tabelle) und den Schlüssel ersetzt. Die Lösegeldforderung wird in jedem Verzeichnis mit Ausnahme des Verzeichnisses der Whitelist platziert.

Abbildung 20

Es gibt keine kostenlose Methode zur Entschlüsselung nach einem Angriff durch diese Ransomware. Die einzige Möglichkeit besteht darin, den von den Angreifern angebotenen Entschlüsselungsdienst zu nutzen. Auf diesen kann man zugreifen, indem man die Anweisungen in der Lösegeldforderung befolgt, wie das folgende Bild zeigt.

The decryption is below

Figure 21

Zum Schutz vor Ransomware empfehlen wir die Verwendung einer fortschrittlichen Anti-Ransomware-Lösung und den Einsatz einer tagesaktuellen Antiviren-Software. Alle Acronis-Produkte sind mit einer hoch entwickelten Anti-Ransomware-Technologie ausgestattet. Mit den Lösungen von Acronis können Sie vor solchen Angriffen schützen und das Risiko eines Datenverlusts minimieren.

Lösungen für die Cyber-Sicherheit wie die Einzelplatz-Lösung  Acronis True Image 2020 oder die Unternehmenslösung  Acronis Backup sind mit der KI-basierten Anti-Malware-Lösung Acronis Active Protection ausgestattet. Sie können Benutzer vor Sodinokibi-Ransomware schützen.

Figure 22: Acronis Active Protection detects Sodinokibi