Ryuk es una de las variantes de ransomware más conocidas en los últimos años. Desde su aparición por primera vez en el verano de 2018, ha acumulado , especialmente en el entorno empresarial, que es su principal objetivo.
1. Información general
Este documento contiene un análisis de la variante de ransomware Ryuk, así como del cargador responsable de introducir el malware en el sistema.
El ransomware Ryuk apareció por primera vez en el verano de 2018. Una de las diferencias de Ryuk con otros ransomwares es que está diseñado para atacar entornos corporativos.
A mediados de 2019, grupos de cibercriminales atacaron a un gran número de empresas españolas utilizando este ransomware.
Fig. 1: Extracto de El Confidencial sobre el ataque del ransomware Ryuk [1]
Fig. 2: Extracto de El País sobre el ataque realizado con el ransomware Ryuk [2]
Este año, Ryuk ha atacado a un gran número de empresas en varios países. Como se puede ver en los siguientes gráficos, Alemania, China, Argelia e India fueron los más afectados.
Comparando el número de ciberataques, podemos ver que millones de usuarios han sido afectados por Ryuk y se ha comprometido una enorme cantidad de datos, lo que ha llevado a graves pérdidas económicas.
Fig. 3: Ilustración de la actividad global de Ryuk.
Fig. 4: 16 países más afectados por Ryuk
Fig. 5: Número de usuarios atacados por el ransomware Ryuk (en millones)
De acuerdo con el principio habitual de funcionamiento de este tipo de amenazas, este ransomware muestra a la víctima una notificación de rescate después de completar el cifrado, que debe ser pagado en bitcoins a la dirección proporcionada para recuperar el acceso a los archivos cifrados.
Este malware ha cambiado desde su primera aparición.
La variante de esta amenaza analizada en este documento fue detectada durante un intento de ataque en enero de 2020.
Debido a su complejidad, este malware se atribuye a menudo a grupos organizados de cibercriminales, conocidos también como grupos APT.
Una parte del código de Ryuk muestra una notable similitud con el código y la estructura de otro conocido ransomware, Hermes, con el que comparte varias funciones. Por esta razón, Ryuk fue inicialmente vinculado con el grupo norcoreano Lazarus, que en ese momento era sospechoso de estar detrás del ransomware Hermes.
Posteriormente, el servicio Falcon X de CrowdStrike destacó que, en realidad, Ryuk fue creado por el grupo WIZARD SPIDER [4].
Existen varias pruebas que respaldan esta suposición. Primero, este ransomware fue publicitado en el sitio web exploit.in, que es un conocido mercado ruso de malware y anteriormente estuvo relacionado con algunos grupos APT rusos.
Este hecho desestima la teoría de que Ryuk podría haber sido desarrollado por el grupo APT Lazarus, ya que no coincide con la forma de actuar de dicho grupo.
Además, Ryuk fue publicitado como un ransomware que no funcionaría en sistemas rusos, ucranianos y bielorrusos. Este comportamiento se determina por una función encontrada en algunas versiones de Ryuk, que verifica el idioma del sistema en el que se ejecuta el ransomware y detiene su funcionamiento si el sistema tiene configurado el idioma ruso, ucraniano o bielorruso. Finalmente, durante el análisis forense de una máquina que fue comprometida por el grupo WIZARD SPIDER, se encontraron varios "artefactos" que se presume fueron utilizados en el desarrollo de Ryuk como una variante del ransomware Hermes.
Por otro lado, los expertos Gabriela Nicolo y Luciano Martins sugirieron que el ransomware pudo haber sido desarrollado por el grupo APT CryptoTech [5].
Esto se deriva del hecho de que unos meses antes de la aparición de Ryuk, este grupo publicó en el foro del mismo sitio información sobre que habían desarrollado una nueva versión del ransomware Hermes.
Varios usuarios del foro se preguntaron si realmente CryptoTech había creado Ryuk. Después de esto, este grupo se defendió y afirmó que tenía pruebas de que desarrollaron el 100% de este ransomware.
2. Características
Comenzamos con el cargador, cuya función es identificar el sistema en el que se encuentra, para que se pueda ejecutar la "versión correcta" del ransomware Ryuk.
El hash del cargador es el siguiente:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Una de las características de este cargador es que no contiene ningún metadato, es decir, los creadores de este programa malicioso no incluyeron ninguna información.
A veces incluyen datos erróneos para hacer que el usuario crea que está ejecutando una aplicación legítima. Sin embargo, como veremos más adelante, en caso de que la infección no requiera la interacción del usuario (como en este caso con el ransomware), los atacantes no consideran necesario utilizar metadatos.
Fig. 6: Metadatos de la muestra
La muestra fue compilada en formato de 32 bits para que pudiera ejecutarse tanto en sistemas de 32 bits como de 64 bits.
3. Vector de penetración
La muestra que descarga y ejecuta Ryuk entró en nuestro sistema a través de una conexión remota, y los parámetros de acceso se obtuvieron gracias a un ataque RDP previo.
Fig. 7: Registro del ataque
El atacante logró acceder al sistema de forma remota. Luego, creó un archivo ejecutable con nuestra muestra.
Este archivo ejecutable fue bloqueado por la solución antivirus antes de su ejecución.
Fig. 8: Bloqueo de la muestra
Fig. 9: Bloqueo de la muestra
Cuando el archivo malicioso fue bloqueado, el atacante intentó descargar una versión encriptada del archivo ejecutable, que también fue bloqueada.
Fig. 10: Conjunto de muestras que el atacante intentó ejecutar
Finalmente, intentó cargar otro archivo malicioso a través de una consola encriptada
PowerShell para evadir la protección antivirus. Pero también fue bloqueado.
Fig. 11: PowerShell con contenido malicioso bloqueado
Fig. 12: PowerShell con contenido malicioso bloqueado
4. Cargador
Cuando se ejecuta, escribe un archivo ReadMe en la carpeta %temp%, lo cual es típico de Ryuk. Este archivo es un requerimiento de rescate que contiene una dirección de correo electrónico en el dominio protonmail, que es bastante común en esta familia de programas maliciosos: msifelabem1981@protonmail.com
Fig. 13: Requerimiento de rescate
Durante la ejecución del cargador, puede ver que inicia varios archivos ejecutables con nombres aleatorios. Se almacenan en una carpeta oculta PUBLIC, pero si la opción «Mostrar archivos y carpetas ocultos» no está activa en el sistema operativo., entonces seguirán ocultos. Además, estos archivos son de 64 bits, a diferencia del archivo principal, que es de 32 bits.
Fig. 14: Archivos ejecutables que son iniciados por la muestra
Como pueden ver en la figura anterior, Ryuk ejecuta icacls.exe, que se utilizará para modificar todas las listas de control de acceso (ACL), asegurando así el acceso y la modificación de los flags.
Obtiene acceso completo bajo todos los usuarios a todos los archivos en el dispositivo (\/T) independientemente de los errores (\/C) y sin mostrar ningún mensaje (\/Q).
Fig. 15: Opciones de ejecución de icacls.exe iniciadas por la muestra
Es importante tener en cuenta que Ryuk verifica qué versión de Windows está en ejecución. Para ello,
realiza una verificación de la versión utilizando GetVersionExW, donde verifica el valor del flag lpVersionInformation, que indica si la versión actual de Windows es posterior a Windows XP..
Dependiendo de si tiene una versión más reciente que Windows XP, el cargador escribirá en la carpeta del usuario local — en este caso, en la carpeta %Public%.
Fig. 17: Verificación de la versión del sistema operativo
El archivo escrito es Ryuk. Luego lo ejecuta, pasando su propia dirección como parámetro.
Fig. 18: Ejecución de Ryuk a través de ShellExecute
Lo primero que hace Ryuk es obtener los parámetros de entrada. Esta vez hay dos parámetros de entrada (el archivo ejecutable en sí y la dirección del dropper), que se utilizan para eliminar sus propias huellas.
Fig. 19: Creación del proceso
También pueden ver que tan pronto como lanza sus archivos ejecutables, se elimina a sí mismo, de esta manera no deja rastro de su presencia en la carpeta donde fue ejecutado.
Fig. 20: Eliminación del archivo
5. RYUK
5.1 Presencia
Ryuk, al igual que otros malware, intenta permanecer en el sistema el mayor tiempo posible. Como se mostró anteriormente, una de las formas de lograr este objetivo es la creación y ejecución ocultas de archivos ejecutables. Para esto, la práctica más común es modificar la clave del registro CurrentVersionRun.
En este caso, pueden ver que para este propósito el primer archivo ejecutable VWjRF.exe
(el nombre del archivo se genera aleatoriamente) ejecuta cmd.exe..
Fig. 21: Ejecución del archivo VWjRF.exe
Luego se introduce el comando RUN con el nombre "svchos". Así, si en algún momento desea verificar las claves del registro, podrá hacerlo fácilmente sin notar este cambio, dada la similitud de este nombre con svchost. Gracias a esta clave, Ryuk garantiza su presencia en el sistema. Si el sistema aún no ha sido infectado, al reiniciar, el archivo ejecutable intentará nuevamente.
Fig. 22: Muestra que garantiza la presencia en la clave del registro
También podemos observar que este archivo ejecutable detiene dos servicios:
"audioendpointbuilder", que, como su nombre indica, corresponde al audio del sistema,
Fig. 23: Muestra que detiene el servicio de audio del sistema
y samss, que es el servicio de gestión de cuentas. Detener estos dos servicios es una característica de Ryuk. En este caso, si el sistema está vinculado a un sistema SIEM, el encriptador intenta detener el envío de cualquier alerta. Así, protege sus siguientes pasos, ya que algunos servicios SAM no podrán iniciar correctamente después de la ejecución de Ryuk.
Fig. 24: Muestra que detiene el servicio Samss
5.2 Privilegios
En general, Ryuk comienza con un movimiento horizontal dentro de la red o se inicia por otro malware, como o , que, en caso de escalada de privilegios, transfieren estos derechos elevados al encriptador.
Previamente, como preludio al proceso de implementación, vemos que ejecuta el proceso ImpersonateSelf, lo que significa que el contenido de seguridad del token de acceso será transferido al hilo, donde será recibido inmediatamente mediante GetCurrentThread.
Fig. 25: Llamada a ImpersonateSelf
Luego vemos que vinculará el token de acceso con el hilo. También observamos que uno de los flags es DesiredAccess, que puede utilizarse para controlar el acceso que tendrá el hilo. En este caso, el valor que recibirá edx debería ser TOKEN_ALL_ACESS o de lo contrario — TOKEN_WRITE.
Fig. 26: Creación del token de hilo
Luego utilizará SeDebugPrivilege y hará una llamada para obtener derechos de depuración Debug sobre el hilo, lo que resultará en que, al indicar PROCESS_ALL_ACCESS, podrá acceder a cualquier proceso requerido. Ahora, dado que el encriptador ya tiene un hilo preparado, solo queda proceder a la etapa final.
Fig. 27: Llamada a SeDebugPrivilege y función de escalado de privilegios
Por un lado, tenemos LookupPrivilegeValueW, que nos proporciona la información necesaria sobre los privilegios que queremos elevar.
Fig. 28: Solicitud de información sobre privilegios para su escalado
Por otro lado, tenemos AdjustTokenPrivileges, que permite obtener los derechos necesarios para nuestro hilo. En este caso, lo más importante es NewState, cuyo flag proporcionará privilegios.
Fig. 29: Configuración de derechos para el token
5.3 Inyección
En esta sección mostraremos cómo una muestra lleva a cabo el proceso de inyección mencionado anteriormente en este informe.
El objetivo principal del proceso de inyección, al igual que el de escalado, es obtener acceso a réplicas ocultas. Para ello, necesita trabajar con un hilo con derechos superiores a los del usuario local. Una vez que obtenga esos derechos más altos, eliminará las copias y realizará cambios en otros procesos para hacer imposible volver a un punto de restauración anterior en el sistema operativo.
Como suele ser el caso con este tipo de malware, para llevar a cabo la inyección utiliza CreateToolHelp32Snapshot, por lo que toma una instantánea de los procesos en ejecución y trata de acceder a esos procesos usando OpenProcess. Una vez que accede al proceso, también abre el token con su información para obtener los parámetros del proceso.
Fig. 30: Obtención de procesos desde la computadora
Podemos ver dinámicamente cómo obtiene la lista de procesos en ejecución en la subrutina 140002D9C utilizando CreateToolhelp32Snapshot. Después de obtenerlos, recorre la lista, tratando de abrir los procesos uno por uno utilizando OpenProcess hasta que logra hacerlo. En este caso, el primer proceso que pudo abrir es "taskhost.exe".
Fig. 31: Ejecución dinámica de procedimiento para obtener el proceso
Podemos ver que posteriormente lee la información del token del proceso, por lo que llama a OpenProcessToken con el parámetro "20008"
Fig. 32: Lectura de información del token del proceso
También verifica que el proceso en el que se inyectará no sea csrss.exe, , explorer.exe, lsaas.exe o que tenga un conjunto de permisos NT authority.
Fig. 33: Procesos excluidos
Podemos ver dinámicamente cómo primero realiza la verificación utilizando la información del token del proceso en 140002D9C con el fin de saber si la cuenta cuyo privilegio se utiliza para ejecutar el proceso es una cuenta AUTORIDAD NT.
Fig. 34: Verificación de AUTORIDAD NT
Y luego, fuera del procedimiento, verifica que no sea csrss.exe, explorer.exe o lsaas.exe.
Fig. 35: Verificación de AUTORIDAD NT
Después de hacer un snapshot de los procesos, abrió los procesos y verificó que ninguno de ellos esté excluido, está listo para grabar en memoria los procesos que serán inyectados.
Para ello, primero reserva un área en la memoria (VirtualAllocEx), escribe en ella (WriteProcessmemory) y crea un hilo (CreateRemoteThread). Para trabajar con estas funciones, utiliza los PIDs de los procesos seleccionados, que obtuvo previamente mediante CreateToolhelp32Snapshot.
Fig. 36: Código para inyección
Aquí podemos observar dinámicamente cómo utiliza el PID del proceso para llamar a la función VirtualAllocEx.
Fig. 37: Llamada a VirtualAllocEx
5.4 Cifrado
En esta sección, revisaremos la parte de este ejemplo relacionada con el cifrado. En la siguiente imagen se pueden ver dos subprogramas llamados "LoadLibrary_EncodeString" y "Encode_Func", que son responsables de realizar el procedimiento de cifrado.
Fig. 38: Procedimientos de cifrado
Al principio, podemos ver cómo carga una cadena que más tarde se utilizará para desofuscar todo lo necesario: importaciones, DLL, comandos, archivos y CSP.
Fig. 39: Cadena de desofuscación
En la siguiente imagen se muestra la primera importación, que desofusca en el registro R4, LoadLibrary. Esto se usará más tarde para cargar las DLL necesarias. También podemos ver otra cadena en el registro R12, que se utiliza junto con la cadena anterior para llevar a cabo la desofuscación.
Fig. 40: Desofuscación dinámica
Continúa cargando los comandos que ejecutará más tarde para desactivar copias de seguridad, puntos de restauración y modos seguros de inicio.
Fig. 41: Carga de comandos
Luego carga la ubicación donde arrojará 3 archivos: Windows.bat, run.sct y start.bat.
Fig. 42: Ubicaciones de archivos
Estos 3 archivos se utilizan para verificar los privilegios que tiene cada una de las ubicaciones. Si los privilegios requeridos no están disponibles, Ryuk detiene la ejecución.
Continúa cargando cadenas correspondientes a los tres archivos. El primero, DECRYPT_INFORMATION.html, contiene información necesaria para recuperar los archivos. El segundo, PUBLIC, contiene la clave pública RSA.
Fig. 43: Línea DECRYPT INFORMATION.html
Tercera, UNIQUE_ID_DO_NOT_REMOVE, contiene la clave cifrada que se utilizará en el siguiente subprograma para realizar el cifrado.
Fig. 44: Línea UNIQUE ID DO NOT REMOVE
Finalmente, carga las bibliotecas necesarias junto con las importaciones requeridas y CSP (Microsoft Enhanced RSA y AES Cryptographic Provider).
Fig. 45: Carga de bibliotecas
Después de que se complete toda la deofuscación, pasa a ejecutar las acciones requeridas para el cifrado: recorrer todos los discos lógicos, realizar lo que se cargó en el subprograma anterior, aumentar su presencia en el sistema, desplegar el archivo RyukReadMe.html, cifrar, recorrer todos los discos de red, conectarse a dispositivos detectados y cifrarlos.
Todo comienza con la carga de "cmd.exe." y la escritura de la clave RSA pública.
Fig. 46: Preparándose para el cifrado
Luego obtiene todos los discos lógicos usando GetLogicalDrives y desactiva todas las copias de seguridad, puntos de restauración y modos seguros de arranque.
Fig. 47: Desactivación de herramientas de recuperación
Después de esto, refuerza su presencia en el sistema, como vimos anteriormente, y escribe el primer archivo RyukReadMe.html en TEMP.
Fig. 48: Publicación del aviso de rescate
En la siguiente figura se puede ver cómo crea un archivo, carga el contenido y lo escribe:
Fig. 49: Carga y escritura de contenido del archivo
Para poder realizar estas mismas acciones en todos los dispositivos, utiliza
"icacls.exe", como mostramos anteriormente.
Fig. 50: Uso de icacls.exe
Y, finalmente, comienza a cifrar archivos excepto los archivos "*.exe", "*.dll", archivos del sistema y otras ubicaciones especificadas en forma de lista blanca cifrada. Para esto utiliza las importaciones: CryptAcquireContextW (donde se especifica el uso de AES y RSA), CryptDeriveKey, CryptGenKey, CryptDestroyKey etc. También se intenta extender su acción a dispositivos de red detectados utilizando WNetEnumResourceW y luego cifrarlos.
Fig. 51: Cifrado de archivos del sistema
6. Importaciones y banderas correspondientes
A continuación se presenta una tabla con los importes y banderas más relevantes utilizados por la muestra:
7. IOC
Enlaces
- usersPublicrun.sct
- Inicio MenúProgramasIniciostart.bat AppDataRoamingMicrosoftWindowsInicio
- MenuProgramasIniciostart.bat
El informe técnico sobre el ransomware Ryuk está elaborado por expertos del laboratorio antivirus PandaLabs.
8. Referencias
1. “Everis y Prisa Radio sufren un grave ciberataque que secuestra sus sistemas.” https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Publicada el 04/11/2019.
2. “Un virus de origen ruso ataca a importantes empresas españolas.” https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Publicada el 04/11/2019.
3. “VB2019 paper: La venganza de Shinigami: la larga cola del malware Ryuk.” https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publicada el 11/12/2019.
4. “Caza de Grandes Juegos con Ryuk: otro ransomware dirigido lucrativo.” https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Publicada el 10/01/2019.
5. “VB2019 paper: La venganza de Shinigami: la larga cola del malware Ryuk.” https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Fuente: habr.com
