
Ryuk ist eine der bekanntesten Varianten von Ransomware in den letzten Jahren. Seit seinem erstmaligen Auftreten im Sommer 2018 hat er , insbesondere im Unternehmensumfeld, das das Hauptziel seiner Angriffe darstellt.
1. Allgemeine Informationen
Dieses Dokument enthält eine Analyse der Ryuk-Ransomware sowie des Bootloaders, der für das Einschleusen der Schadsoftware in Systeme verantwortlich ist.
Die Ryuk-Ransomware tauchte erstmals im Sommer 2018 auf. Ein Unterscheidungsmerkmal von Ryuk im Vergleich zu anderen Ransomware-Varianten ist, dass sie ausschließlich auf Unternehmensumgebungen abzielt.
Mitte 2019 griffen cyberkriminelle Gruppen eine große Anzahl spanischer Unternehmen mit dieser Ransomware an.

Abbildung 1: Auszug aus El Confidencial über den Angriff der Ryuk-Ransomware [1]

Abbildung 2: Auszug aus El País über den Angriff, der mit Hilfe der Ryuk-Ransomware durchgeführt wurde [2]
In diesem Jahr hat Ryuk zahlreiche Unternehmen in verschiedenen Ländern attackiert. Wie Sie in den nachstehenden Abbildungen sehen können, sind Deutschland, China, Algerien und Indien am stärksten betroffen.
Im Vergleich der Anzahl an Cyberangriffen lässt sich feststellen, dass Ryuk Millionen von Nutzern betroffen hat und eine enorme Menge an Daten 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 Nutzer, die von der Ransomware Ryuk betroffen sind (in Millionen).
Entsprechend dem üblichen Vorgehen dieser Bedrohungen präsentiert die Ransomware nach der Verschlüsselung der Dateien dem Opfer eine Lösegeldmitteilung, die in Bitcoin an die angegebene Adresse gezahlt werden muss, um den Zugang zu den verschlüsselten Dateien wiederherzustellen.
Diese Schadsoftware hat sich seit ihrem ersten Auftreten verändert.
Die in diesem Dokument analysierte Variante dieser Bedrohung wurde bei einem Angriffsversuch im Januar 2020 entdeckt.
Aufgrund ihrer Komplexität wird diese Schadsoftware häufig organisierten Cyberkriminalitätsgruppen zugeschrieben, die auch als APT-Gruppen bekannt sind.
Ein Teil des Ryuk-Codes weist auffällige Ähnlichkeiten mit dem Code und der Struktur eines anderen bekannten Ransomware-Trojaners, Hermes, auf, die eine Reihe gemeinsamer Funktionen besitzen. Aus diesem Grund wurde Ryuk ursprünglich mit der nordkoreanischen Gruppe Lazarus in Verbindung gebracht, die zu dieser Zeit verdächtigt wurde, hinter Hermes zu stecken.
Später stellte der Falcon X-Dienst von CrowdStrike fest, dass Ryuk tatsächlich von der Gruppe WIZARD SPIDER [4] entwickelt wurde.
Es gibt mehrere Hinweise, die diese Annahme unterstützen. Erstens wurde diese Ransomware auf der Website exploit.in beworben, einem bekannten russischen Markt für Malware, der 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 Handlungsweise dieser Gruppe entspricht.
Darüber hinaus wurde Ryuk als Ransomware beworben, die auf russischen, ukrainischen und belarussischen Systemen nicht funktioniert. Dieses Verhalten wird durch Funktionen in einigen Versionen von Ryuk bestimmt, bei denen die Sprache des Systems, auf dem diese Ransomware ausgeführt wird, überprüft wird, und ihre Ausführung gestoppt wird, wenn das System in Russisch, Ukrainisch oder Belarussisch eingestellt ist. Schließlich wurde bei der forensischen Analyse eines von der Gruppe WIZARD SPIDER gehackten Computers mehrere "Artefakte" entdeckt, die angeblich bei der Entwicklung von Ryuk als Variante der Ransomware Hermes verwendet wurden.
Auf der anderen Seite vermuteten die Experten Gabriela Nicolo und Luciano Martins, dass die Ransomware möglicherweise von der APT-Gruppe CryptoTech entwickelt wurde [5].
Dies folgt aus der Tatsache, dass einige Monate vor dem Erscheinen von Ryuk diese Gruppe in einem Forum derselben Website Informationen darüber veröffentlicht hat, dass sie eine neue Version der Ransomware Hermes entwickelt haben.
Mehrere Benutzer des Forums fragten sich, ob CryptoTech tatsächlich Ryuk erstellt hat. Daraufhin hat sich diese Gruppe verteidigt und erklärt, dass sie Beweise dafür hat, dass sie 100% dieses Verschlüsselers entwickelt haben.
2. Eigenschaften
Wir beginnen mit dem Loader, dessen Aufgabe es ist, das System zu identifizieren, in dem er sich befindet, um die "richtige" Version des Ryuk-Verschlüsselers zu starten.
Der Hash des Loaders ist wie folgt:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Eine der Besonderheiten dieses Loaders ist, dass er keine Metadaten enthält, d.h. die Ersteller dieser Malware haben keine Informationen darin eingebaut.
Manchmal fügen sie fehlerhafte Daten hinzu, um den Benutzer glauben zu lassen, dass er ein legitimes Programm ausführt. Wie wir später sehen werden, halten es die Angreifer jedoch nicht für notwendig, Metadaten zu verwenden, wenn die Infektion keine Benutzerinteraktion erfordert (wie im Fall dieses Verschlüsselers).

Abb. 6: Metadaten des Samples
Die Probe wurde im 32-Bit-Format kompiliert, sodass sie sowohl auf 32-Bit- als auch auf 64-Bit-Systemen ausgeführt werden kann.
3. Angriffsvektor
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 erhalten.

Abb. 7: Angriffheits-Register
Der Angreifer konnte sich remote ins System einloggen. Danach erstellte er eine ausführbare Datei mit unserer Probe.
Diese ausführbare Datei wurde vor dem Start von der Antivirensoftware blockiert.

Abb. 8: Blockierung der Probe


Abb. 9: Blockierung der Probe
Als die Malware blockiert wurde, versuchte der Angreifer, eine verschlüsselte Version der ausführbaren Datei herunterzuladen, die ebenfalls blockiert wurde.

Abb. 10: Sammlung von Proben, die der Angreifer zu starten versuchte
Schließlich versuchte er, eine andere Malware über eine verschlüsselte PowerShell-Konsole herunterzuladen, um die Antivirenschutzmaßnahmen zu umgehen. Auch dies wurde blockiert.
Abb. 11: PowerShell mit blockiertem schädlichen Inhalt

Abb. 12: PowerShell mit blockiertem schädlichen Inhalt

Abbildung 12: PowerShell mit blockiertem schadhafter Inhalt
4. Loader
Wenn er ausgeführt wird, wird eine ReadMe-Datei im Ordner erstellt. %temp%, was für Ryuk typisch ist. Diese Datei ist ein Lösegeldforderung, die eine E-Mail-Adresse in der Domain protonmail enthält, die in dieser Malware-Familie recht häufig vorkommt: msifelabem1981@protonmail.com
![]()

Abb. 13: Lösegeldforderung
Während der Ausführung des Loaders können Sie sehen, dass mehrere ausführbare Dateien mit zufälligen Namen gestartet werden. Sie werden in einem versteckten Ordner gespeichert. ÖFFENTLICH, aber wenn in dem Betriebssystem die Option „Versteckte Dateien und Ordner anzeigen“, nicht aktiviert ist, bleiben sie versteckt. Darüber hinaus sind diese Dateien 64-Bit, im Gegensatz zur Eltern-Datei, die 32-Bit ist.


Abb. 14: Ausführbare Dateien, die vom Sample gestartet werden
Wie Sie in der obenstehenden Abbildung sehen können, startet Ryuk icacls.exe, das verwendet wird, um alle Zugriffssteuerungslisten (ACL) zu ändern und somit den Zugriff und die Änderung der Flags zu gewährleisten.
Er erhält vollen Zugriff für alle Benutzer auf alle Dateien auf dem Gerät (/T), unabhängig von Fehlern (/C) und ohne Anzeige von Nachrichten (/Q).
![]()
Abb. 15: Ausführungsparameter von icacls.exe, die von dem Beispiel gestartet wurden
Es ist wichtig zu beachten, dass Ryuk überprüft, welche Version von Windows läuft. Dazu
führt er eine Versionsprüfung durch mit GetVersionExW, in der er den Wert des Flags lpVersionInformation, das zeigt, ob die aktuelle Windows-Version neuer ist als Windows XP.


Je nachdem, ob Sie eine neuere Version als Windows XP haben, wird der Loader im lokalen Benutzerverzeichnis gespeichert – in diesem Fall im Ordner %Public%.
![]()
Abb. 17: Versionsprüfung des Betriebssystems
Die gespeicherte Datei ist Ryuk. Anschließend wird sie gestartet, wobei die eigene Adresse als Parameter übergeben wird.

Abb. 18: Ausführung von Ryuk über ShellExecute
Das Erste, was Ryuk tut, ist das Erhalten 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 er, sobald er seine ausführbaren Dateien gestartet hat, sich selbst entfernt, wodurch er keine Spuren seiner Existenz im Verzeichnis hinterlässt, in dem er ausgeführt wurde.

Abb. 20: Datei löschen
5. RYUK
5.1 Präsenz
Ryuk versucht, wie andere schadhafte Software, so lange wie möglich im System zu bleiben. Eine der Methoden, um dies zu erreichen, ist die heimliche Erstellung und Ausführung von ausführbaren Dateien. Eine gängige Praxis hierfür ist die Änderung des Registrierungskeys CurrentVersionRun.
In diesem Fall sehen Sie, dass die erste ausführbare Datei VWjRF.exe
(der Dateiname wird zufällig generiert) startet cmd.exe.

![]()
Abb. 21: Ausführung der Datei VWjRF.exe
Dann wird der Befehl eingegeben RUN mit dem Namen "svchos". Daher könnten Sie, wenn Sie zu irgendeinem Zeitpunkt die Registrierungskeys überprüfen, diese Änderung aufgrund der Ähnlichkeit mit svchost leicht übersehen. Dieser Key sorgt dafür, dass Ryuk im System bleibt. Falls das System noch nicht infiziert war, wird die ausführbare Datei beim Neustart des Systems einen weiteren Versuch starten.
![]()
Abb. 22: Beispiel zur Sicherstellung der Präsenz im Registrierungskey
Wir können auch sehen, dass diese ausführbare Datei zwei Dienste stoppt:
"audioendpointbuilder", die, wie der Name schon sagt, dem Systemaudio entspricht,
![]()
Abb. 23: Die Probe stoppt den Systemaudio-Dienst
und samss, der für das Kontomanagement verantwortlich ist. Das Anhalten dieser beiden Dienste ist ein Charakteristikum von Ryuk. In diesem Fall, wenn das System mit einem SIEM-System verbunden ist, versucht der Verschlüsselungstrojaner, das Senden von irgendwelchen Warnungen zu stoppen. Damit schützt er seine nächsten Schritte, da einige SAM-Dienste nach der Ausführung von Ryuk nicht mehr ordnungsgemäß gestartet werden können.
![]()
Abb. 24: Die Probe stoppt den Samss-Dienst
5.2 Privilegien
Allgemein gesagt beginnt Ryuk mit einer seitlichen Bewegung innerhalb des Netzwerks oder wird von anderer Malware gestartet, wie zum Beispiel oder , die im Falle von Privilegieneskalation diese erhöhten Rechte an den Verschlüsselungstrojaner übergeben.
Vorab, als Vorspiel zum Implementierungsprozess, sehen wir, dass er den Prozess ImpersonateSelfausführt, was bedeutet, dass der Sicherheitsinhalt des Zugriffstokens in den Thread übergeben wird, wo er sofort mit GetCurrentThread.

abgerufen wird.
Abb. 25: Aufruf von ImpersonateSelf DesiredAccess, welches zur Kontrolle des Zugriffs verwendet werden kann, den der Prozess haben wird. In diesem Fall sollte der Wert, den edx erhält, TOKEN_ALL_ACCESS oder alternativ — TOKEN_WRITE.


Abb. 26: Erstellung des Prozess-Tokens
Dann wird er SeDebugPrivilege verwenden und einen Aufruf zur Erlangung von Debug-Rechten für den Prozess durchführen, wodurch er durch die Angabe von PROCESS_ALL_ACCESS, Zugriff auf jeden gewünschten Prozess erhalten kann. Nun, da der Angreifer bereits einen vorbereiteten Prozess hat, bleibt nur der abschließende Schritt.

Abb. 27: Aufruf von SeDebugPrivilege und Funktion zur Privilegieneskalation
Einerseits haben wir LookupPrivilegeValueW, das uns die erforderlichen Informationen über die Privilegien bereitstellt, die wir erhöhen möchten.

Abb. 28: Anforderung von Informationen über Privilegien zur Eskalation
Andererseits haben wir AdjustTokenPrivileges, das es ermöglicht, die erforderlichen Rechte für unseren Prozess zu erhalten. In diesem Fall ist das Wichtigste NewState, dessen Flag die Privilegien bereitstellen wird.


Abb. 29: Anpassung der Rechte für das Token
5.3 Implementierung
In diesem Abschnitt zeigen wir, wie ein Beispiel den zuvor in diesem Bericht genannten Implementierungsprozess durchführt.
Das Hauptziel des Implementierungsprozesses sowie der Eskalation besteht darin, Zugriff auf schattierte Kopien. Dazu muss er mit einem privilegierten Stream arbeiten, der über den Rechten des lokalen Benutzers liegt. Sobald er solche höheren Rechte erhält, wird er die Kopien löschen und Änderungen an anderen Prozessen vornehmen, um eine Rückkehr zu einem früheren Wiederherstellungspunkt im Betriebssystem unmöglich zu machen.
Wie es bei dieser Art von Malware üblich ist, verwendet er zur Durchführung der Implementierung CreateToolHelp32Snapshot, um einen Snapshot der aktuell laufenden Prozesse zu erstellen und versucht, über OpenProcessauf diese Prozesse zuzugreifen. Sobald er Zugriff auf den Prozess erhält, öffnet er auch ein Token mit den Informationen, um die Prozessparameter abzurufen.

Abb. 30: Abruf von Prozessen vom Computer
Wir können dynamisch beobachten, wie er die Liste der laufenden Prozesse im Unterprogramm 140002D9C mit Hilfe von CreateToolhelp32Snapshot erhält. Nachdem er sie erhalten hat, durchläuft er die Liste und versucht, die Prozesse nacheinander mit OpenProcess zu öffnen, bis ihm dies gelingt. In diesem Fall ist der erste Prozess, den er öffnen konnte, „taskhost.exe“.

Abb. 31: Dynamische Ausführung der Prozedur zur Abfrage des Prozesses
Wir können sehen, dass er anschließend Informationen des Prozess-Tokens liest, daher ruft er OpenProcessToken mit dem Parameter "20008"

Abb. 32: Lesen der Informationen des Prozess-Tokens
Er überprüft auch, dass der Prozess, in den er injiziert werden soll, nicht csrss.exe, explorer.exe, lsaas.exe oder dass er über die Berechtigungsgruppe verfügt NT-Behörde.

Abb. 33: Ausgeschlossene Prozesse
Wir können dynamisch sehen, wie er zunächst die Überprüfung mit Hilfe der Informationsdokumente des Prozesses in 140002D9C durchführt, um herauszufinden, ob das Konto, dessen Rechte für die Ausführung des Prozesses verwendet werden, ein Konto von NT AUTHORITY.

Abb. 34: Überprüfung von NT AUTHORITY
Später, außerhalb der Prozedur, überprüft er, dass es sich nicht um csrss.exe, explorer.exe oder lsaas.exe.

Abb. 35: Überprüfung von NT AUTHORITY
Nachdem er einen Snapshot der Prozesse erstellt hat, öffnete er die Prozesse und überprüfte, dass keiner von ihnen ausgeschlossen war, ist er bereit, die Prozesse, die in den Speicher implantiert werden sollen, aufzuzeichnen.
Zunächst reserviert er dafür einen Bereich im Speicher (VirtualAllocEx), schreibt diesen (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.

Abbildung 36: Code für die Implantation
Hier können wir dynamisch beobachten, wie er die PID des Prozesses zur Invocation der Funktion VirtualAllocEx.

Abbildung 37: Aufruf von VirtualAllocEx
5.4 Verschlüsselung
In diesem Abschnitt betrachten wir einen Teil dieses Beispiels, der mit der Verschlüsselung zusammenhängt. Im nächsten Bild sehen Sie zwei Unterprogramme mit den Namen "LoadLibrary_EncodeString" und "Encode_Func", die für die Durchführung des Verschlüsselungsprozesses verantwortlich sind.

Abbildung 38: Verschlüsselungsverfahren
Zunächst sehen wir, wie er eine Zeichenfolge lädt, die später für die Deobfuskation alles Notwendige verwendet wird: Importe, DLLs, Befehle, Dateien und CSP.

Abbildung 39: Deobfuskationskette
Im nächsten Bild sehen Sie den ersten Import, den er im Register R4 deobfuskieren wird. LoadLibrary. Dies wird später zum Laden der benötigten DLLs verwendet. Außerdem können wir eine andere Zeile im Register R12 sehen, die zusammen mit der vorherigen Zeile zur Durchführung der Deobfuskation genutzt wird.

Abb. 40: Dynamische Deobfuskation
Er lädt weiterhin die Befehle, die er später ausführen wird, um Backups, Wiederherstellungspunkte und sichere Boot-Modi zu deaktivieren.

Abb. 41: Laden von Befehlen
Dann lädt er den Speicherort, an dem er 3 Dateien ablegen wird: Windows.bat, run.sct und start.bat.




Abb. 42: Speicherorte der Dateien
Diese 3 Dateien werden verwendet, um die Privilegien zu überprüfen, über die jeder der Speicherorte verfügt. Wenn die erforderlichen Privilegien nicht verfügbar sind, stoppt Ryuk die Ausführung.
Er lädt weiterhin die Zeilen, die den drei Dateien entsprechen. Die erste, DECRYPT_INFORMATION.html, enthält die Informationen, die für die Wiederherstellung der Dateien erforderlich sind. Die zweite, ÖFFENTLICH, enthält den öffentlichen RSA-Schlüssel.

Abb. 43: Zeile DECRYPT INFORMATION.html
Die 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: Eindeutige ID-Zeile, NICHT ENTFERNEN
Schließlich lädt er die erforderlichen Bibliotheken zusammen mit den benötigten Importen und CSP (Microsoft Enhanced RSA und AES-Kryptografie-Anbieter).

Abb. 45: Laden der Bibliotheken
Nachdem die gesamte Deobfuskation abgeschlossen ist, führt er die erforderlichen Aktionen für die Verschlüsselung aus: Durchlaufen aller logischen Laufwerke, Ausführen dessen, was im vorherigen Unterprogramm geladen wurde, Verstärkung der Präsenz im System, Bereitstellung der Datei RyukReadMe.html, Verschlüsselung, Durchlaufen aller Netzlaufwerke, Zugriff auf gefundene Geräte und deren Verschlüsselung.
Alles beginnt mit dem Laden von "cmd.exe" und Aufzeichnung des öffentlichen RSA-Schlüssels.

Abb. 46: Vorbereitung zur Verschlüsselung
Dann erhält er alle logischen Laufwerke mit GetLogicalDrives und deaktiviert alle Backups, Wiederherstellungspunkte und sicheren Boot-Modi.

Abb. 47: Deaktivierung der Wiederherstellungstools
Anschließend verstärkt er seine Präsenz im System, wie oben gesehen, und erstellt die erste Datei RyukReadMe.html in TEMP.

Abb. 48: Veröffentlichung der Lösegeldbenachrichtigung
Im nächsten Bild sehen Sie, wie er eine Datei erstellt, den Inhalt lädt und aufzeichnet:

Abb. 49: Laden und Aufzeichnen des Datei-Inhalts
Um diese Aktionen auf allen Geräten ausführen zu können, verwendet er
"icacls.exe", wie oben gezeigt.

Abbildung 50: Verwendung von icacls.exe
Und schließlich beginnt er mit der Verschlüsselung von Dateien, ausgenommen "*.exe", "*.dll", Systemdateien und andere Orte, die in einer verschlüsselten Whitelist angegeben sind. Dazu verwendet er Importanweisungen: CryptAcquireContextW (wo die Verwendung von AES und RSA angegeben ist), CryptDeriveKey, CryptGenKey, CryptDestroyKey usw. Außerdem wird versucht, seine Aktivitäten auf entdeckte Netzwerkgeräte auszudehnen, indem WNetEnumResourceW verwendet wird, um sie dann zu verschlüsseln.

Abbildung 51: Verschlüsselung von Systemdateien
6. Importe und zugehörige Flags
Im Folgenden finden Sie eine Tabelle mit den relevantesten Importen und Flags, die im Beispiel verwendet werden:

7. IOC

Links
- usersPublicrun.sct
- StartmenüProgrammeAutostartstart.bat AppDataRoamingMicrosoftWindowsStart
- MenüProgrammeAutostartstart.bat

Der technische Bericht über den Ryuk-Verschlüsselungsvirus wurde von Experten des Antiviruslabors PandaLabs erstellt.
8. Quellen
1. "Everis und Prisa Radio erleiden einen schweren Cyberangriff, der ihre Systeme lahmlegt." https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, veröffentlicht am 04/11/2019.
2. „Ein russischer Virus 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 Anhang 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 Anhang der Ryuk-Malware.“ https://www. virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Quelle: habr.com
