Ryuk est l'une des variantes de ransomware les plus connues des dernières années. Depuis son apparition à l'été 2018, il a accumulé , surtout dans le secteur des affaires, qui est sa principale cible.
1. Informations générales
Ce document contient une analyse de la variante de ransomware Ryuk, ainsi que du chargeur responsable de l'introduction du logiciel malveillant dans le système.
Le ransomware Ryuk est apparu pour la première fois à l'été 2018. Une des caractéristiques qui distingue Ryuk des autres ransomwares est qu'il vise à attaquer des environnements d'entreprise.
Au milieu de l'année 2019, des groupes de cybercriminalité ont attaqué un grand nombre d'entreprises espagnoles à l'aide de ce ransomware.
Fig. 1 : Extrait d'El Confidencial concernant l'attaque du ransomware Ryuk [1]
Fig. 2 : Extrait d'El País sur l'attaque menée avec le ransomware Ryuk [2]
Cette année, Ryuk a attaqué un grand nombre d'entreprises dans divers pays. Comme vous pouvez le voir sur les illustrations ci-dessous, l'Allemagne, la Chine, l'Algérie et l'Inde ont été particulièrement touchées.
En comparant le nombre d'attaques cybernétiques, nous pouvons voir que Ryuk a touché des millions d'utilisateurs et a compromis une énorme quantité de données, entraînant des pertes économiques considérables.
Fig. 3 : Illustration de l'activité mondiale de Ryuk.
Fig. 4 : 16 pays les plus touchés par Ryuk
Fig. 5 : Nombre d'utilisateurs attaqués par le ransomware Ryuk (en millions)
Conformément au principe de fonctionnement habituel de ce type de menaces, ce ransomware affiche à la victime un avis de rançon après avoir terminé le chiffrement, indiquant que le paiement doit être effectué en bitcoins à l'adresse spécifiée pour restaurer l'accès aux fichiers chiffrés.
Ce logiciel malveillant a évolué depuis sa première apparition.
La variante de cette menace analysée dans ce document a été découverte lors d'une tentative d'attaque en janvier 2020.
En raison de sa complexité, ce logiciel malveillant est souvent attribué à des groupes criminels cybernétiques organisés, également connus sous le nom de groupes APT.
Une partie du code de Ryuk présente des similitudes notables avec le code et la structure d'un autre ransomware connu, Hermes, avec lequel il partage plusieurs fonctionnalités. C'est pourquoi Ryuk a d'abord été associé au groupe nord-coréen Lazarus, qui était alors suspecté d'être derrière le ransomware Hermes.
Par la suite, le service Falcon X de CrowdStrike a noté que Ryuk avait en réalité été créé par le groupe WIZARD SPIDER.
Il existe plusieurs éléments de preuve à l'appui de cette hypothèse. Tout d'abord, ce ransomware a été promu sur le site exploit.in, qui est un marché bien connu des logiciels malveillants en Russie et qui a déjà été lié à certains groupes APT russes.
Ce fait exclut la théorie selon laquelle Ryuk aurait pu être développé par le groupe APT Lazarus, puisque cela ne correspond pas à la façon dont agit ce groupe.
De plus, Ryuk était présenté comme un ransomware qui ne fonctionnerait pas sur les systèmes russes, ukrainiens et biélorusses. Ce comportement est déterminé par une fonction présente dans certaines versions de Ryuk, qui vérifie la langue du système sur lequel le ransomware est exécuté et arrête son fonctionnement si le système est configuré en russe, ukrainien ou biélorusse. Enfin, lors de l'analyse d'une machine compromise par le groupe WIZARD SPIDER, plusieurs « artefacts » ont été découverts, qui auraient été utilisés lors du développement de Ryuk comme une variante du ransomware Hermes.
D'autre part, les experts Gabriela Nicolo et Luciano Martins ont suggéré que le ransomware avait peut-être été développé par le groupe APT CryptoTech.
Cela découle du fait que quelques mois avant l'apparition de Ryuk, ce groupe avait publié sur le forum du même site des informations selon lesquelles ils avaient développé une nouvelle version du ransomware Hermes.
Plusieurs utilisateurs du forum se sont demandé si CryptoTech avait réellement créé Ryuk. Par la suite, ce groupe s'est défendu en affirmant qu'il possédait des preuves qu'il avait développé 100 % de ce ransomware.
2. Caractéristiques
Nous commençons par le chargeur, dont la tâche est d'identifier le système dans lequel il se trouve, afin de pouvoir exécuter la « bonne » version du ransomware Ryuk.
Le hachage du chargeur est le suivant :
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Une des particularités de ce chargeur est qu'il ne contient aucune métadonnée, c'est-à-dire que les créateurs de ce programme malveillant n'ont inclus aucune information.
Parfois, ils incluent des données erronées pour amener l'utilisateur à penser qu'il exécute une application légitime. Cependant, comme nous le verrons plus tard, dans le cas où l'infection ne nécessite pas d'interaction avec l'utilisateur (comme c'est le cas avec ce ransomware), les cybercriminels estiment qu'il n'est pas nécessaire d'utiliser des métadonnées.
Fig. 6 : Métadonnées de l'échantillon
L'échantillon a été compilé au format 32 bits pour pouvoir être exécuté à la fois sur des systèmes 32 bits et 64 bits.
3. Vecteur d'infiltration
L'échantillon qui télécharge et exécute Ryuk est entré dans notre système via une connexion distante, et les paramètres d'accès ont été obtenus grâce à une attaque RDP préalable.
Fig. 7 : Registre de l'attaque
Le cybercriminel a réussi à accéder au système à distance. Après cela, il a créé un fichier exécutable avec notre échantillon.
Ce fichier exécutable a été bloqué par la solution antivirus avant son exécution.
Fig. 8 : Blocage de l'échantillon
Fig. 9 : Blocage de l'échantillon
Lorsque le fichier malveillant a été bloqué, le cybercriminel a tenté de télécharger une version chiffrée du fichier exécutable, qui a également été bloquée.
Fig. 10 : Ensemble d'échantillons que le cybercriminel a tenté d'exécuter
Enfin, il a essayé de télécharger un autre fichier malveillant via une console chiffrée
PowerShell pour contourner la protection antivirus. Mais il a également été bloqué.
Fig. 11 : PowerShell avec contenu malveillant bloqué
Fig. 12 : PowerShell avec contenu malveillant bloqué
4. Chargeur
Lorsqu'il s'exécute, il enregistre un fichier ReadMe dans le dossier %temp%, ce qui est typique pour Ryuk. Ce fichier est une demande de rançon, contenant une adresse e-mail dans le domaine protonmail, qui apparaît assez souvent dans cette famille de logiciels malveillants : msifelabem1981@protonmail.com
Fig. 13 : Demande de rançon
Lors de l'exécution du chargeur, vous pouvez voir qu'il lance plusieurs fichiers exécutables avec des noms aléatoires. Ils sont stockés dans un dossier caché PUBLIC, mais si l'option « Afficher les fichiers et dossiers cachés » n'est pas activée dans le système d'exploitation «Показывать скрытые файлы и папки», ils resteront cachés. De plus, ces fichiers sont en 64 bits, contrairement au fichier parent, qui est en 32 bits.
Fig. 14 : Fichiers exécutables lancés par l'échantillon
Comme vous pouvez le voir sur l'image ci-dessus, Ryuk exécute icacls.exe, qui sera utilisé pour modifier toutes les listes de contrôle d'accès (ACL), garantissant ainsi l'accès et la modification des drapeaux.
Il obtient un accès complet sous tous les utilisateurs à tous les fichiers sur l'appareil (/T) indépendamment des erreurs (/C) et sans afficher de messages (/Q).
Fig. 15 : Paramètres d'exécution de icacls.exe lancés par l'échantillon
Il est important de noter que Ryuk vérifie quelle version de Windows est en cours d'exécution. Pour cela, il
effectue une vérification de version avec GetVersionExW, dans laquelle il vérifie la valeur du drapeau lpVersionInformation, indiquant si la version actuelle de Windows est plus récente que Windows XP.
En fonction de la version que vous utilisez, plus récente que Windows XP, le chargeur écrira dans le dossier utilisateur local — dans ce cas, le dossier %Public%.
Fig. 17 : Vérification de la version du système d'exploitation
Le fichier enregistré est Ryuk. Ensuite, il l'exécute en passant son propre adresse comme paramètre.
Fig. 18 : Exécution de Ryuk via ShellExecute
La première chose que fait Ryuk est d'obtenir les paramètres d'entrée. Cette fois, il y a deux paramètres d'entrée (le fichier exécutable lui-même et l'adresse de dropper), qui sont utilisés pour supprimer ses propres traces.
Fig. 19 : Création du processus
Vous pouvez également voir qu'une fois qu'il a exécuté ses fichiers exécutables, il se supprime, ne laissant aucune trace de sa présence dans le dossier où il a été exécuté.
Fig. 20 : Suppression du fichier
5. RYUK
5.1 Présence
Ryuk, comme d'autres logiciels malveillants, essaie de rester dans le système le plus longtemps possible. Comme indiqué ci-dessus, l'une des façons d'atteindre cet objectif est de créer et d'exécuter des fichiers exécutables de manière furtive. Pour cela, la pratique la plus courante consiste à modifier la clé de registre CurrentVersionRun.
Dans ce cas, vous pouvez voir que, pour cet objectif, le premier fichier exécutable VWjRF.exe
(le nom du fichier est généré de manière aléatoire) exécute cmd.exe.
Fig. 21 : Exécution du fichier VWjRF.exe
Ensuite, la commande est introduite RUN s'appelant "svchos" Donc, si vous souhaitez vérifier les clés de registre à tout moment, vous pourrez facilement ne pas remarquer ce changement, compte tenu de la similitude de ce nom avec svchost. Grâce à cette clé, Ryuk maintient sa présence dans le système. Si le système n'a pas encore été infecté, lorsque vous redémarrez le système, le fichier exécutable essaiera à nouveau.
Fig. 22 : L'échantillon maintient une présence dans la clé de registre
Nous pouvons également voir que ce fichier exécutable arrête deux services :
"audioendpointbuilder", qui, comme son nom l'indique, correspond à l'audio système,
Fig. 23 : L'échantillon arrête le service audio système
et samss, qui est le service de gestion des comptes. L'arrêt de ces deux services est une caractéristique de Ryuk. Dans ce cas, si le système est lié à un système SIEM, le ransomware essaie d'arrêter l'envoi de quelles que soient les alertes. Ainsi, il protège ses prochaines étapes, car certains services SAM ne pourront pas démarrer correctement après l'exécution de Ryuk.
Fig. 24 : L'échantillon arrête le service Samss
5.2 Privilèges
En général, Ryuk commence par un déplacement horizontal dans le réseau ou il est lancé par un autre logiciel malveillant, tel que ou , qui, en cas d'escalade des privilèges, transmettent ces droits augmentés au ransomware.
Au préalable, en guise de prélude au processus d'injection, nous voyons qu'il exécute le processus ImpersonateSelf, ce qui signifie que le contenu de sécurité du jeton d'accès sera transmis au thread, où il sera immédiatement récupéré par GetCurrentThread.
Fig. 25 : Appel de ImpersonateSelf
Ensuite, nous voyons qu'il liera le jeton d'accès au thread. Nous voyons également que l'un des drapeaux est DesiredAccess, qui peut être utilisé pour contrôler l'accès qu'aura le thread. Dans ce cas, la valeur que recevra edx doit être TOKEN_ALL_ACESS sinon TOKEN_WRITE.
Fig. 26 : Création du jeton de thread
Ensuite, il utilisera SeDebugPrivilege et fera un appel pour obtenir les droits de débogage Debug par rapport au thread, ce qui lui permettra, en spécifiant PROCESS_ALL_ACCESS, d'accéder à n'importe quel processus requis. Maintenant, étant donné que le ransomware a déjà préparé le thread, il ne reste plus qu'à passer à l'étape finale.
Fig. 27: Appel de SeDebugPrivilege et fonction d'escalade des droits
D'une part, nous avons LookupPrivilegeValueW, qui nous fournit les informations nécessaires sur les privilèges que nous souhaitons élever.
Fig. 28: Demande d'informations sur les privilèges pour leur élévation
D'autre part, nous avons AdjustTokenPrivileges, qui permet d'obtenir les droits nécessaires pour notre flux. Dans ce cas, le plus important est NewState, dont le drapeau fournira des privilèges.
Fig. 29: Configuration des droits pour le jeton
5.3 Injection
Dans cette section, nous montrerons comment un échantillon exécute le processus d'injection, déjà mentionné dans ce rapport.
L'objectif principal du processus d'injection, tout comme celui de l'escalade, est d'obtenir un accès aux copies d'ombre. Pour cela, il doit fonctionner avec un flux ayant des droits supérieurs à ceux de l'utilisateur local. Une fois qu'il aura obtenu ces droits supérieurs, il supprimera les copies et modifiera d'autres processus afin de rendre impossible le retour à un point de restauration antérieur dans le système d'exploitation.
Comme c'est souvent le cas avec ce type de logiciels malveillants, pour effectuer l'injection, il utilise CreateToolHelp32Snapshot, donc il fait un cliché des processus actuellement en cours et tente d'accéder à ces processus via OpenProcess. Une fois qu'il a accès au processus, il ouvre également le jeton avec ses informations pour obtenir les paramètres du processus.
Fig. 30: Obtention des processus de l'ordinateur
Nous pouvons voir dynamiquement comment il obtient la liste des processus en cours dans le sous-programme 140002D9C à l'aide de CreateToolhelp32Snapshot. Après les avoir obtenus, il parcourt la liste, essayant d'ouvrir les processus un par un via OpenProcess jusqu'à ce qu'il réussisse. Dans ce cas, le premier processus qu'il a pu ouvrir est "taskhost.exe".
Fig. 31: Exécution dynamique de la procédure pour obtenir le processus
Nous pouvons voir qu'ensuite il lit les informations du jeton du processus, donc il appelle OpenProcessToken avec le paramètre "20008"
Fig. 32: Lecture des informations du jeton du processus
Il vérifie également que le processus dans lequel il va être injecté n'est pas csrss.exe, explorer.exe, lsaas.exe ou qu'il possède un ensemble de droits NT authority.
Fig. 33: Processus exclus
Nous pouvons voir dynamiquement comment il effectue d'abord la vérification avec les informations du jeton du processus dans 140002D9C pour savoir si le compte dont les droits sont utilisés pour exécuter le processus est un compte NT AUTHORITY.
Fig. 34 : Vérification de NT AUTHORITY
Et plus tard, en dehors de la procédure, il vérifie que ce n'est pas csrss.exe, explorer.exe ou lsaas.exe.
Fig. 35 : Vérification de NT AUTHORITY
Après avoir pris un instantané des processus, ouvert les processus et vérifié qu'aucun d'entre eux n'est exclu, il est prêt à écrire en mémoire les processus qui seront injectés.
Pour cela, il réserve d'abord une zone en mémoire (VirtualAllocEx), y écrit (WriteProcessMemory) et crée un thread (CreateRemoteThread). Pour travailler avec ces fonctions, il utilise les PID des processus sélectionnés, qu'il a obtenus au préalable grâce à CreateToolhelp32Snapshot.
Fig. 36 : Code pour l'injection
Ici, nous pouvons observer dynamiquement comment il utilise le PID du processus pour appeler la fonction VirtualAllocEx.
Fig. 37 : Appel de VirtualAllocEx
5.4 Cryptage
Dans ce chapitre, nous explorerons une partie de cet échantillon liée au cryptage. Sur l'image suivante, vous pouvez voir deux sous-programmes appelés "LoadLibrary_EncodeString" et "Encode_Func", qui sont responsables de l'exécution de la procédure de cryptage.
Fig. 38 : Procédures de cryptage
Au début, nous pouvons voir comment il charge une chaîne qui sera utilisée plus tard pour déobfusquer tout ce qui est nécessaire : imports, DLL, commandes, fichiers et CSP.
Fig. 39 : Chaîne de déobfuscation
Sur l'image suivante, le premier import qu'il déobfusque se trouve dans le registre R4, LoadLibrary. Cela sera utilisé plus tard pour charger les DLL nécessaires. Nous pouvons également voir une autre chaîne dans le registre R12, qui est utilisée avec la chaîne précédente pour effectuer la déobfuscation.
Fig. 40 : Déobfuscation dynamique
Il continue de charger les commandes qu'il exécutera plus tard pour désactiver les sauvegardes, les points de restauration et les modes de démarrage sûrs.
Fig. 41 : Chargement des commandes
Ensuite, il charge l'emplacement où il déposera 3 fichiers : Windows.bat, run.sct et start.bat.
Fig. 42 : Emplacements des fichiers
Ces 3 fichiers sont utilisés pour vérifier les privilèges dont disposent chacun des emplacements. Si les privilèges requis ne sont pas disponibles, Ryuk arrête l'exécution.
Il continue de charger les chaînes correspondant aux trois fichiers. Le premier, DECRYPT_INFORMATION.html, contient les informations nécessaires à la restauration des fichiers. Le deuxième, PUBLIC, contient la clé publique RSA.
Fig. 43 : Chaîne DECRYPT INFORMATION.html
Le troisième, UNIQUE_ID_DO_NOT_REMOVE, contient une clé chiffrée qui sera utilisée dans le sous-programme suivant pour effectuer le chiffrement.
Fig. 44 : Ligne UNIQUE ID DO NOT REMOVE
Enfin, il charge les bibliothèques nécessaires avec les imports requis et le CSP (Microsoft Enhanced RSA et AES Cryptographic Provider).
Fig. 45 : Chargement des bibliothèques
Après que toute la dé-obfuscation soit terminée, il passe à l'exécution des actions requises pour le chiffrement : parcourir tous les disques logiques, exécuter ce qui a été chargé dans le sous-programme précédent, renforcer sa présence dans le système, déposer le fichier RyukReadMe.html, chiffrer, explorer tous les disques réseau, se connecter aux dispositifs détectés et les chiffrer.
Tout commence par le chargement de "cmd.exe" et l'enregistrement de la clé RSA publique.
Fig. 46 : Préparation au chiffrement
Il récupère ensuite tous les disques logiques à l'aide de GetLogicalDrives et désactive toutes les sauvegardes, points de restauration et modes de démarrage sécurisés.
Fig. 47 : Désactivation des outils de récupération
Après cela, il renforce sa présence dans le système, comme nous l'avons vu ci-dessus, et enregistre le premier fichier RyukReadMe.html dans TEMP.
Fig. 48 : Publication de l'avis de rançon
Sur l'illustration suivante, vous pouvez voir comment il crée un fichier, charge son contenu et l'enregistre :
Fig. 49 : Chargement et enregistrement du contenu du fichier
Pour être capable d'exécuter ces mêmes actions sur tous les dispositifs, il utilise
"icacls.exe", comme nous l'avons montré ci-dessus.
Fig. 50 : Utilisation de icacls.exe
Et enfin, il commence à chiffrer les fichiers sauf les fichiers "*.exe", "*.dll", les fichiers système et d'autres emplacements spécifiés sous forme de liste blanche chiffrée. Pour cela, il utilise les imports : CryptAcquireContextW (où l'utilisation de AES et RSA est spécifiée), CryptDeriveKey, CryptGenKey, CryptDestroyKey etc. Une tentative est également faite d'étendre son action aux dispositifs réseau détectés à l'aide de WNetEnumResourceW et ensuite de les chiffrer.
Fig. 51 : Chiffrement des fichiers système
6. Imports et flags correspondants
Ci-dessous se trouve un tableau listant les imports et flags les plus pertinents utilisés par l'échantillon :
7. IOC
Liens
- usersPublicrun.sct
- Menu DémarrerProgrammesDémarragestart.bat AppDataRoamingMicrosoftWindowsDémarrer
- MenuProgrammesDémarragestart.bat
Le rapport technique sur le ransomware Ryuk a été élaboré par les experts du laboratoire antivirus PandaLabs.
8. Liens
1. "Everis et Prisa Radio subissent une grave cyberattaque qui séquestre leurs systèmes."https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Publiée le 04/11/2019.
2. "Un virus d'origine russe attaque des entreprises espagnoles importantes."https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Publiée le 04/11/2019.
3. "Article de VB2019 : La revanche de Shinigami : la longue traîne du malware Ryuk."https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publiée le 11/12/2019.
4. "Chasse au gros gibier avec Ryuk : un ransomware ciblé lucratif de plus."https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Publiée le 10/01/2019.
5. "Article de VB2019 : La revanche de Shinigami : la longue traîne du malware Ryuk."https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Source : habr.com
