Ryuk ist einer der bekanntesten Ransomware-Varianten der letzten Jahre. Seit seinem ersten Auftauchen im Sommer 2018 hat er , insbesondere im Unternehmensumfeld, welches das Hauptziel seiner Angriffe ist.
1. Allgemeine Informationen
Dieses Dokument enthält eine Analyse der Ransomware-Variante Ryuk sowie des Downloaders, der dafür verantwortlich ist, die Malware in das System zu laden.
Die Ransomware Ryuk tauchte erstmals im Sommer 2018 auf. Eine der Unterschiede von Ryuk im Vergleich zu anderen Ransomwares ist, dass sie auf Angriffe auf Unternehmensumgebungen abzielt.
Mitte 2019 griffen Cyberkriminelle eine große Anzahl spanischer Unternehmen mit dieser Ransomware an.
Abb. 1: Auszug aus El Confidencial zur Ryuk-Ransomware-Attacke [1]
Abb. 2: Auszug aus El País über den Angriff, der mit der Ryuk-Ransomware durchgeführt wurde [2]
In diesem Jahr hat Ryuk eine große Anzahl von Unternehmen in verschiedenen Ländern angegriffen. Wie Sie an den nachstehenden Abbildungen sehen können, wurden Deutschland, China, Algerien und Indien am stärksten betroffen.
Im Vergleich der Anzahl von Cyberangriffen sehen wir, dass Millionen von Nutzern unter Ryuk gelitten haben und eine enorme Datenmenge kompromittiert wurde, was zu erheblichen wirtschaftlichen Schäden führte.
Abb. 3: Illustration der globalen Aktivität von Ryuk.
Abb. 4: 16 Länder, die am stärksten von Ryuk betroffen sind.
Abb. 5: Anzahl der von der Ryuk-Ransomware angegriffenen Nutzer (in Millionen)
Nach dem üblichen Muster solcher Bedrohungen zeigt diese Ransomware nach Abschluss der Verschlüsselung dem Opfer eine Lösegeldbenachrichtigung an, die in Bitcoin an die angegebene Adresse zu zahlen ist, um den Zugang zu den verschlüsselten Dateien wiederherzustellen.
Diese Malware hat sich seit ihrem ersten Auftauchen verändert.
Die in diesem Dokument analysierte Variante dieser Bedrohung wurde bei dem Versuch einer Attacke im Januar 2020 entdeckt.
Aufgrund ihrer Komplexität wird diese Malware häufig organisierten Cyberkriminalitätsgruppen zugeordnet, die auch als APT-Gruppen bekannt sind.
Ein Teil des Ryuk-Codes weist bemerkenswerte Ähnlichkeiten mit dem Code und der Struktur des anderen bekannten Ransomware Hermes auf, mit dem er eine Reihe gemeinsamer Funktionen hat. Genau aus diesem Grund wurde Ryuk zunächst mit der nordkoreanischen Gruppe Lazarus in Verbindung gebracht, die zu diesem Zeitpunkt verdächtigt wurde, hinter der Ransomware Hermes zu stecken.
Später stellte der Falcon X-Dienst von CrowdStrike fest, dass Ryuk tatsächlich von der Gruppe WIZARD SPIDER [4] erstellt wurde.
Es gibt mehrere Beweise zur Unterstützung dieser Annahme. Erstens wurde diese Ransomware auf der Website exploit.in beworben, die ein bekannter russischer Markt für Malware ist und zuvor mit einigen russischen APT-Gruppen in Verbindung gebracht wurde.
Diese Tatsache schließt die Theorie aus, dass Ryuk von der APT-Gruppe Lazarus entwickelt worden sein könnte, da dies nicht dem entspricht, wie die Gruppe agiert.
Darüber hinaus wurde Ryuk als Ransomware beworben, die nicht auf russischen, ukrainischen und belarussischen Systemen funktioniert. Dieses Verhalten wird durch eine Funktion bestimmt, die in einigen Versionen von Ryuk entdeckt wurde, bei der überprüft wird, welche Sprache das System hat, auf dem diese Ransomware läuft, und er stoppt seine Ausführung, wenn das System Russisch, Ukrainisch oder Belarussisch ist. Schließlich wurden bei der forensischen Analyse eines Computers, der von der Gruppe WIZARD SPIDER gehackt wurde, mehrere „Artefakte“ gefunden, die angeblich bei der Entwicklung von Ryuk als Variante der Ransomware Hermes verwendet wurden.
Auf der anderen Seite schlugen die Experten Gabriela Nicolo und Luciano Martins vor, dass die Ransomware möglicherweise von der APT-Gruppe CryptoTech [5] entwickelt wurde.
Das folgt aus der Tatsache, dass diese Gruppe einige Monate vor dem Auftreten von Ryuk auf dem Forum derselben Website Informationen veröffentlicht hatte, dass sie eine neue Version der Ransomware Hermes entwickelt haben.
Mehrere Nutzer des Forums fragten sich, ob CryptoTech tatsächlich Ryuk erstellt hat. Danach verteidigte sich die Gruppe und erklärte, dass sie Beweise dafür habe, dass sie 100 % dieser Ransomware entwickelt hat.
2. Merkmale
Wir beginnen mit dem Loader, dessen Aufgabe es ist, das System zu identifizieren, in dem er sich befindet, um die „richtige“ Version der Ransomware Ryuk starten zu können.
Der Hash des Loaders lautet:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Eine Besonderheit dieses Downloaders ist, dass er keine Metadaten enthält, d.h. die Entwickler dieses schädlichen Programms haben keine Informationen eingebettet.
Manchmal fügen sie falsche Daten hinzu, um den Benutzer glauben zu machen, dass er angeblich eine legitime Anwendung ausführt. Wie wir später sehen werden, glauben die Angreifer jedoch nicht, dass es notwendig ist, Metadaten zu verwenden, wenn die Infektion keine Interaktion mit dem Benutzer erfordert (wie im Fall dieses Verschlüsselers).
Abbildung 6: Metadaten der Probe
Die Probe wurde im 32-Bit-Format kompiliert, damit sie sowohl auf 32-Bit- als auch auf 64-Bit-Systemen ausgeführt werden kann.
3. Eindringungsvektor
Die Probe, die Ryuk herunterlädt und ausführt, gelangte über eine Remote-Verbindung in unser System, und die Zugangsdaten wurden durch einen vorherigen RDP-Angriff erlangt.
Abbildung 7: Angriffs-Registry
Es gelang dem Angreifer, sich remote in das System einzuloggen. Danach erstellte er eine ausführbare Datei mit unserer Probe.
Diese ausführbare Datei wurde vor dem Start durch eine Antivirenlösung blockiert.
Abbildung 8: Blockierung der Probe
Abbildung 9: Blockierung der Probe
Als die schädliche Datei blockiert wurde, versuchte der Angreifer, eine verschlüsselte Version der ausführbaren Datei herunterzuladen, die ebenfalls blockiert wurde.
Abbildung 10: Satz von Proben, die der Angreifer zu starten versuchte
Schließlich versuchte er, eine weitere schadhafte Datei über die verschlüsselte Konsole
PowerShell zu laden, um die Antivirenabwehr zu umgehen. Diese wurde ebenfalls blockiert.
Abbildung 11: PowerShell mit blockiertem schädlichen Inhalt
Abbildung 12: PowerShell mit blockiertem schädlichen Inhalt
4. Downloader
Wenn er ausgeführt wird, schreibt er eine Datei ReadMe in den Ordner %temp%, was typisch für Ryuk ist. Diese Datei ist eine Lösegeldforderung, die eine E-Mail-Adresse im protonmail-Domain enthält, die in dieser Familie von schädlichen Programmen recht häufig vorkommt: msifelabem1981@protonmail.com
Abbildung 13: Lösegeldforderung
Während die Downloader ausgeführt werden, können Sie sehen, dass er mehrere ausführbare Dateien mit zufälligen Namen startet. Diese werden in einem versteckten Ordner gespeichert ÖFFENTLICH, aber wenn die Option „Versteckte Dateien und Ordner anzeigen“ in das Betriebssystem nicht aktiv ist., dann bleiben sie verborgen. Darüber hinaus sind diese Dateien 64-Bit, im Gegensatz zur 32-Bit-Originaldatei.
Abb. 14: Ausführbare Dateien, die vom Sample gestartet werden
Wie Sie auf der obigen Abbildung sehen können, führt Ryuk icacls.exe aus, das verwendet wird, um alle Zugriffssteuerungslisten (ACL) zu ändern und somit den Zugriff und die Änderung von Flags sicherzustellen.
Es erhält vollen Zugriff für alle Benutzer auf alle Dateien auf dem Gerät (\/T), unabhängig von Fehlern (\/C) und ohne irgendwelche Meldungen anzuzeigen (\/Q).
Abb. 15: Ausführungsparameters von icacls.exe, die vom Sample gestartet wurden
Es ist wichtig zu beachten, dass Ryuk prüft, welche Windows-Version ausgeführt wird. Dazu
führt es eine Versionsprüfung mit GetVersionExW, in der er den Wert des Flags lpVersionInformation, überprüft, das anzeigt, ob die aktuelle Windows-Version neuer ist als Windows XP.
Je nachdem, ob Sie eine neuere Version als Windows XP haben, wird der Loader in den Ordner des lokalen Benutzers schreiben — in diesem Fall in den Ordner %Public%.
Abb. 17: Überprüfung der Betriebssystemversion
Die geschriebene Datei ist Ryuk. Dann wird sie gestartet, indem seine eigene Adresse als Parameter übergeben wird.
Abb. 18: Ausführung von Ryuk über ShellExecute
Das erste, was Ryuk tut, ist das Abrufen der Eingabeparameter. Diesmal gibt es zwei Eingabeparameter (die ausführbare Datei selbst und die Adresse des Droppers), die verwendet werden, um eigene Spuren zu beseitigen.
Abb. 19: Prozess erstellen
Sie können auch sehen, dass, sobald er seine ausführbaren Dateien gestartet hat, er sich selbst entfernt, sodass er keine Spuren seiner Anwesenheit in dem Ordner hinterlässt, in dem er ausgeführt wurde.
Abb. 20: Datei löschen
5. RYUK
5.1 Präsenz
Ryuk versucht, ähnlich wie andere Malware, so lange wie möglich im System präsent zu bleiben. Wie oben gezeigt, ist eine der Methoden, um dieses Ziel zu erreichen, das heimliche Erstellen und Ausführen von ausführbaren Dateien. Zu diesem Zweck ist eine gängige Praxis das Ändern des Registrierungsschlüssels CurrentVersionRun.
In diesem Fall sehen Sie, dass zu diesem Zweck die erste ausführbare Datei VWjRF.exe
(der Dateiname wird zufällig generiert) cmd.exe startet. Abb. 21: Ausführung der Datei VWjRF.exe.
Dann wird der Befehl eingegeben
mit dem Namen " RUN svchossvchos". So, wenn Sie jederzeit die Registrierungsschlüssel überprüfen möchten, werden Sie diese Änderung wahrscheinlich leicht übersehen, da der Name diesem von svchost ähnelt. Über diesen Schlüssel sichert Ryuk sein Vorhandensein im System. Wenn das System bisher nicht infiziert war, wird die ausführbare Datei bei einem Neustart des Systems den Versuch wiederholen.
Abb. 22: Probe stellt das Vorhandensein im Registrierungsschlüssel sicher
Wir können auch sehen, dass diese ausführbare Datei zwei Dienste stoppt:
"audioendpointbuilder", der, wie der Name bereits verrät, mit dem Systemaudio verbunden ist,
Abb. 23: Probe stoppt den Systemaudio-Dienst
und samss, was der Dienst für Kontoverwaltung ist. Das Stoppen dieser beiden Dienste ist ein Merkmal von Ryuk. In diesem Fall, wenn das System mit einem SIEM-System verbunden ist, versucht der Verschlüsselungsalgorithmus, die Übermittlung von irgendeiner Warnungen zu stoppen. Damit schützt er seine nächsten Schritte, da einige SAM-Dienste nach der Ausführung von Ryuk möglicherweise nicht ordnungsgemäß funktionieren können.
Abb. 24: Probe stoppt den Samss-Dienst
5.2 Berechtigungen
Im Allgemeinen beginnt Ryuk mit horizontaler Bewegung innerhalb des Netzwerks oder wird von einem anderen Malware-Programm, wie oder , ausgelöst, die bei einer Berechtigungserhöhung diese erhöhten Rechte an den Verschlüsselungsalgorithmus weiterleiten.
Im Voraus, als Prolog zum Implementierungsprozess, sehen wir, dass er den Prozess ImpersonateSelf, ausführt, was bedeutet, dass der Sicherheitsinhalt des Zugriffstokens in den Thread übertragen wird, wo er sofort mit Hilfe von GetCurrentThread.
empfangen wird. Abb. 25: Aufruf von ImpersonateSelf
Dann sehen wir, dass er das Zugriffstoken mit dem Thread verknüpfen wird. Wir sehen auch, dass einer der Flags – DesiredAccess, verwendet werden kann, um den Zugriff zu steuern, den der Thread haben wird. In diesem Fall sollte der Wert, den edx erhält, TOKEN_ALL_ACESS oder andernfalls – TOKEN_WRITE.
Abb. 26: Erstellung des Thread-Tokens
Dann wird er SeDebugPrivilege verwenden und einen Aufruf machen, um Debug-Rechte im Verhältnis zum Thread zu erhalten, wodurch er, indem er PROCESS_ALL_ACCESS, Zugang zu jedem erforderlichen Prozess erhält. Jetzt, da der Verschlüsselungsalgorithmus bereits einen vorbereiteten Thread hat, bleibt nur noch die abschließende Phase zu beginnen.
Abb. 27: Aufruf von SeDebugPrivilege und Funktion zur Rechteskalation
Einerseits haben wir LookupPrivilegeValueW, das uns die erforderlichen Informationen über die Privilegien liefert, die wir erhöhen möchten.
Abb. 28: Anfrage von Privilegien-Informationen zur Eskalation
Andererseits haben wir AdjustTokenPrivileges, die es ermöglicht, die erforderlichen Rechte für unseren Thread zu erhalten. In diesem Fall ist das Wichtigste NewState, dessen Flag Privilegien gewähren wird.
Abb. 29: Einstellung der Rechte für das Token
5.3 Injektion
In diesem Abschnitt zeigen wir, wie das Muster den Injektionsprozess ausführt, der zuvor in diesem Bericht erwähnt wurde.
Das Hauptziel des Injektionsprozesses, wie auch der Eskalation, ist es, Zugriff auf Schattenkopienzu erlangen. Dazu muss es mit einem Thread arbeiten, der höhere Rechte hat als der lokale Benutzer. Sobald es solche höheren Rechte erhält, wird es Kopien löschen und Änderungen an anderen Prozessen vornehmen, um einen Rückschritt zu einem früheren Wiederherstellungspunkt im Betriebssystem unmöglich zu machen.
Wie es bei dieser Art von Malware üblich ist, verwendet es zur Durchführung der Injektion CreateToolHelp32Snapshot, um einen Snapshot der derzeit laufenden Prozesse zu machen und versucht, auf diese Prozesse mit Hilfe von OpenProcesszuzugreifen. Sobald es Zugriff auf den Prozess erhält, öffnet es auch das Token mit seinen Informationen, um die Prozessparameter zu erhalten.
Abb. 30: Abrufen der Prozesse vom Computer
Wir können dynamisch sehen, wie es die Liste der laufenden Prozesse im Unterprogramm 140002D9C mit CreateToolhelp32Snapshot erhält. Nach dem Abruf geht es die Liste durch und versucht nacheinander, die Prozesse mit OpenProcess zu öffnen, bis es gelingt. In diesem Fall ist der erste Prozess, den es öffnen konnte, "taskhost.exe".
Abb. 31: Dynamische Ausführung der Prozedur zum Abrufen des Prozesses
Wir können sehen, dass es anschließend Informationen über das Token des Prozesses ausliest, indem es OpenProcessToken mit dem Parameter "20008"
Abb. 32: Lesen der Informationen über das Token des Prozesses
Es überprüft auch, dass der Prozess, in den es injiziert, nicht csrss.exe, explorer.exe, lsaas.exe oder dass er ein Satz von Rechten hat, NT-Behörde.
Abb. 33: Ausgeschlossene Prozesse
Wir können dynamisch sehen, wie es zuerst eine Überprüfung mit den Informationen des Prozess-Token in 140002D9C um festzustellen, ob das Konto, dessen Berechtigungen für den Prozess verwendet werden, ein Benutzerkonto ist NT-AUTORITÄT.
Abb. 34: Überprüfung der NT-AUTORITÄT
Und später, außerhalb des Prozesses, überprüft er, dass dies nicht csrss.exe, explorer.exe oder lsaas.exe.
Abb. 35: Überprüfung der NT-AUTORITÄT
Nachdem er ein Snapshot der Prozesse erstellt, die Prozesse geöffnet und überprüft hat, dass keiner von ihnen ausgeschlossen ist, ist er bereit, die Prozesse, die injiziert werden sollen, in den Speicher zu schreiben.
Dafür reserviert er zunächst einen Bereich im Speicher (VirtualAllocEx), schreibt hinein (WriteProcessmemory) und erstellt einen Thread (CreateRemoteThread). Für die Arbeit mit diesen Funktionen verwendet er die PIDs der ausgewählten Prozesse, die er zuvor mit Hilfe von CreateToolhelp32Snapshot.
Abb. 36: Code für die Injektion
Hier können wir dynamisch beobachten, wie er die PID des Prozesses verwendet, um die Funktion VirtualAllocEx.
Abb. 37: Aufruf von VirtualAllocEx
5.4 Verschlüsselung
In diesem Abschnitt werden wir einen Teil dieses Beispiels, der mit der Verschlüsselung zu tun hat, untersuchen. Im nächsten Bild sehen Sie zwei Unterprogramme mit den Namen "LoadLibrary_EncodeString" und "Encode_Func", die für die Durchführung des Verschlüsselungsverfahrens verantwortlich sind.
Abb. 38: Verschlüsselungsverfahren
Zunächst sehen wir, wie er eine Zeichenfolge lädt, die später zur Deobfuskierung aller notwendigen Dinge verwendet wird: Importe, DLL, Befehle, Dateien und CSP.
Abb. 39: Deobfuskierungskette
Im nächsten Bild sehen wir den ersten Import, den er im Register R4 deobfuskisiert, LoadLibrary. Dies wird später verwendet, um die notwendigen DLL zu laden. Außerdem sehen wir eine andere Zeichenfolge im Register R12, die zusammen mit der vorherigen Zeichenfolge zur Deobfuskierung verwendet wird.
Abb. 40: Dynamische Deobfuskierung
Er fährt fort, die Befehle zu laden, die er später ausführen wird, um Backups, Wiederherstellungspunkte und sichere Startmodi zu deaktivieren.
Abb. 41: Laden von Befehlen
Dann lädt er die Standorte, wo er 3 Dateien ablegen wird: Windows.bat, run.sct und start.bat.
Abb. 42: Standorte der Dateien
Diese 3 Dateien werden verwendet, um die Berechtigungen zu überprüfen, über die jeder dieser Standorte verfügt. Wenn die erforderlichen Berechtigungen nicht verfügbar sind, stoppt Ryuk die Ausführung.
Er fährt fort, die Zeichenfolgen zu laden, die den drei Dateien entsprechen. Die erste, DECRYPT_INFORMATION.html, enthält Informationen, die zur Wiederherstellung der Dateien erforderlich sind. Die zweite, ÖFFENTLICH, enthält den öffentlichen RSA-Schlüssel.
Abb. 43: Zeile DECRYPT INFORMATION.html
Dritte, UNIQUE_ID_DO_NOT_REMOVE, enthält den verschlüsselten Schlüssel, der im nächsten Unterprogramm zur Durchführung der Verschlüsselung verwendet wird.
Abb. 44: Zeile UNIQUE ID DO NOT REMOVE
Schließlich lädt es die benötigten Bibliotheken zusammen mit den erforderlichen Imports und CSP (Microsoft Enhanced RSA und AES Cryptographic Provider).
Abb. 45: Laden der Bibliotheken
Nachdem die gesamte Deobfuskation abgeschlossen ist, fährt es mit der Durchführung der erforderlichen Maßnahmen zur Verschlüsselung fort: Durchlaufen aller logischen Laufwerke, Ausführen dessen, was im vorherigen Unterprogramm geladen wurde, Verstärkung der Präsenz im System, Ablage der Datei RyukReadMe.html, Verschlüsselung, Durchlaufen aller Netzlaufwerke, Wechsel zu entdeckten Geräten und deren Verschlüsselung.
Alles beginnt mit dem Laden von "Abb. 21: Ausführung der Datei VWjRF.exe" und dem Schreiben des öffentlichen RSA-Schlüssels.
Abb. 46: Vorbereitung zur Verschlüsselung
Dann erhält es alle logischen Laufwerke mit Hilfe von GetLogicalDrives und deaktiviert alle Backups, Wiederherstellungspunkte und sichere Startmodi.
Abb. 47: Deaktivierung der Wiederherstellungsmittel
Danach verstärkt es seine Präsenz im System, wie oben gezeigt, und schreibt die erste Datei RyukReadMe.html in TEMP.
Abb. 48: Veröffentlichung der Erpressungsnachricht
Im nächsten Bild können Sie sehen, wie es eine Datei erstellt, den Inhalt lädt und ihn aufzeichnet:
Abb. 49: Laden und Schreiben des Inhalts der Datei
Um dieselben Aktionen auf allen Geräten auszuführen, verwendet es
"icacls.exe", wie wir oben gezeigt haben.
Abb. 50: Verwendung von icalcls.exe
Und schließlich beginnt es mit der Verschlüsselung von Dateien mit Ausnahme von "*.exe", "*.dll", Systemdateien und anderen Orten, die in einer verschlüsselten Whitelist angegeben sind. Dazu verwendet es die Imports: CryptAcquireContextW (wo die Verwendung von AES und RSA angegeben ist), CryptDeriveKey, CryptGenKey, CryptDestroyKey usw. Es wird auch versucht, seine Aktivitäten auf entdeckte Netzwerkgeräte mit Hilfe von WNetEnumResourceW auszuweiten und sie dann zu verschlüsseln.
Abb. 51: Verschlüsselung von Systemdateien
6. Imports und entsprechende Flags
Nachfolgend finden Sie eine Tabelle mit den relevantesten Imports und Flags, die im Muster verwendet werden:
7. IOC
Links
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
Der technische Bericht über den Ryuk-Verschlüsseler wurde von Experten des Antiviruslabors PandaLabs erstellt.
8. Links
1. „Everis und Prisa Radio leiden unter einem schweren Cyberangriff, der ihre Systeme verschlüsselt hat.“https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Veröffentlicht am 04.11.2019.
2. „Ein Virus russischen Ursprungs greift bedeutende spanische Unternehmen an.“https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Veröffentlicht am 04.11.2019.
3. „VB2019-Papier: Shinigamis Rache: der lange Schwanz der Ryuk-Malware.“https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Veröffentlicht am 11.12.2019.
4. „Big Game Hunting mit Ryuk: Ein weiteres lukratives Ziel-Ransomware.“https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Veröffentlicht am 10.01.2019.
5. „VB2019-Papier: Shinigamis Rache: der lange Schwanz der Ryuk-Malware.“https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Quelle: habr.com
