McAfee ATR analiza Sodinokibi, también conocido como REvil Ransomware-as-a-Service: lo que nos dice el código


Episodio 1: lo que nos dice el código

El equipo de Investigación Avanzada de Amenazas (ATR) de McAfee observó una nueva familia de ransomware en la naturaleza, llamada Sodinokibi (o REvil), a fines de abril de 2019. Alrededor de esta misma época, el equipo de ransomware GandCrab anunció que cerrarían sus operaciones. ¿Coincidencia? ¿O hay más en la historia?

En esta serie de blogs, compartimos un nuevo análisis de Sodinokibi y sus conexiones con GandCrab, con nuevas ideas obtenidas exclusivamente de la investigación exhaustiva y exhaustiva de McAfee ATR.

En esta primera entrega compartimos nuestro extenso análisis de malware y posinfección y visualizamos exactamente qué tan grande es la campaña de Sodinokibi.

Fondo

Desde su llegada en abril de 2019, ha quedado muy claro que el nuevo niño en la ciudad, "Sodinokibi" o "REvil" es una seria amenaza. El nombre Sodinokibi se descubrió en el hash ccfde149220e87e97198c23fb8115d5a donde se mencionó "Sodinokibi.exe" como nombre de archivo interno; También se conoce con el nombre de REvil.

Al principio, se observó que el ransomware Sodinokibi se propagaba al explotar una vulnerabilidad en el servidor WebLogic de Oracle. Sin embargo, similar a algunas otras familias de ransomware, Sodinokibi es lo que llamamos Ransomware-as-a-Service (RaaS), donde un grupo de personas mantiene el código y otro grupo, conocido como afiliados, difunde el ransomware.

Este modelo permite a los afiliados distribuir el ransomware de la forma que deseen. Algunos afiliados prefieren ataques masivos mediante campañas de phishing y kits de explotación, donde otros afiliados adoptan un enfoque más específico mediante el acceso RDP de fuerza bruta y la carga de herramientas y scripts para obtener más derechos y ejecutar el ransomware en la red interna de una víctima . Hemos investigado varias campañas para difundir Sodinokibi, la mayoría de las cuales tenían un modus operandi diferente, pero notamos que muchas comenzaron con una violación de un servidor RDP.

¿A quién y dónde golpea Sodinokibi?

Basado en la visibilidad desde MVISION Insights pudimos generar la siguiente imagen de infecciones observadas desde mayo hasta el 23 de agostord2019:

¿Quién es el objetivo? En su mayoría organizaciones, aunque realmente depende de las habilidades y experiencia de los diferentes grupos de afiliados sobre quién y en qué área geográfica operan.

Revertir el Código

En este primer episodio, profundizaremos en el código y explicaremos el funcionamiento interno del ransomware una vez que se haya ejecutado en la máquina de la víctima.

En general, el código está muy bien escrito y diseñado para ejecutarse rápidamente para cifrar los archivos definidos en la configuración del ransomware. El archivo de configuración incrustado tiene algunas opciones interesantes que destacaremos más adelante en este artículo.

Según el análisis de comparación de códigos que realizamos entre GandCrab y Sodinokibi, consideramos que es una hipótesis probable que las personas detrás del ransomware Sodinokibi puedan tener algún tipo de relación con el equipo de GandCrab.

FIGURA 1.1. RESUMEN DEL FALLO DE EJECUCIÓN DE SODINOKIBI

Dentro del código

Descripción de Sodinokibi

Para este artículo investigamos la muestra con el siguiente hash (empaquetado):

El objetivo principal de este malware, como otras familias de ransomware, es cifrar sus archivos y luego solicitar un pago a cambio de una herramienta de descifrado de los autores o afiliados para descifrarlos.

La muestra de malware que investigamos es un binario de 32 bits, con un icono en el archivo empaquetado y sin uno en el archivo desempaquetado. El empaquetador está programado en Visual C ++ y el malware en sí está escrito en ensamblado puro.

Detalles técnicos

El objetivo del empaquetador es descifrar la verdadera parte del malware y usar una técnica RunPE para ejecutarlo desde la memoria. Para obtener el malware de la memoria, una vez finalizado el descifrado y cargado en la memoria, lo volcamos para obtener una versión desempaquetada.

La primera acción del malware es obtener todas las funciones necesarias en tiempo de ejecución y realizar un IAT dinámico para intentar ofuscar la llamada de Windows en un análisis estático.

FIGURA 2. EL MALWARE RECIBE TODAS LAS FUNCIONES NECESARIAS EN EL TIEMPO DE EJECUCIÓN

La siguiente acción del malware es intentar crear un mutex con un nombre codificado. Es importante saber que el malware tiene el 95% de las cadenas encriptadas en su interior. Tenga en cuenta que cada muestra de malware tiene cadenas diferentes en muchos lugares; los valores como claves o semillas cambian todo el tiempo para evitar lo que nosotros, como industria hacemos, es decir, fabricar vacunas o crear un descifrador sin tomar los valores de la muestra específica de malware para descifrar las cadenas.

FIGURA 3. CREACIÓN DE UN MUTEX Y COMPROBAR PARA VER SI YA EXISTE

Si existe el mutex, el malware termina con una llamada a "ExitProcess". Esto se hace para evitar el relanzamiento del ransomware.

Después de esta operación de mutex, el malware calcula un hash CRC32 de una parte de sus datos utilizando una semilla especial que también cambia por muestra. Esta operación CRC32 se basa en una operación polinómica CRC32 en lugar de tablas para hacerlo más rápido y el tamaño del código más pequeño.

El siguiente paso es descifrar este bloque de datos si la verificación CRC32 pasa con éxito. Si la comprobación es un error, el malware ignorará este flujo de código e intentará utilizar un exploit como se explicará más adelante en el informe.

FIGURA 4. CÁLCULO DEL CRC32 HASH DE LA CONFIGURACIÓN CRIPTADA Y LA DESCRIPCIÓN SI PASA EL CHEQUE

En el caso de que el malware pase la verificación CRC32 y se descifre correctamente con una clave que cambia por muestra, el bloque de datos obtendrá un archivo JSON en la memoria que se analizará. Este archivo de configuración tiene campos para preparar las claves más adelante para cifrar la clave de la víctima y más información que alterará el comportamiento del malware.

La verificación CRC32 evita la posibilidad de que alguien pueda cambiar los datos cifrados con otra configuración y no actualiza el valor CRC32 en el malware.

Después de descifrar el archivo JSON, el malware lo analizará con un código de un analizador JSON completo y extraerá todos los campos y guardará los valores de estos campos en la memoria.

FIGURA 5. EJEMPLO PARCIAL DE LA CONFIG ENCRITURA Y LIMPIEZA

Vamos a explicar todos los campos en la configuración y sus significados:

  • pk -> Este valor codificado en base64 es importante más adelante para el proceso de cifrado; Es la clave pública del atacante.
  • pid -> El número de afiliado que pertenece a la muestra.
  • sub -> La subcuenta o ID de campaña para esta muestra que el afiliado utiliza para realizar un seguimiento de sus pagos.
  • dbg -> Opción de depuración. En la versión final, esto se usa para verificar si se han hecho algunas cosas o no; Es una opción de desarrollo que puede ser verdadera o falsa. En las muestras en estado salvaje está en estado falso. Si está configurado, la verificación del teclado posterior no sucederá. Es útil que los desarrolladores de malware demuestren que el malware funciona correctamente en la parte crítica sin detectar sus propias máquinas en función del idioma.
  • rápido -> Si esta opción está habilitada y, de manera predeterminada, muchas muestras la tienen habilitada, el malware cifrará los primeros 1 megabyte de cada archivo de destino, o todos los archivos si es más pequeño que este tamaño. En el caso de que este campo sea falso, encriptará todos los archivos.
  • wipe -> Si esta opción es "verdadera", el malware destruirá los archivos de destino en las carpetas que se describen en el campo json "wfld". Esta destrucción ocurre en todas las carpetas que tienen el nombre o nombres que aparecen en este campo de la configuración en unidades lógicas y recursos compartidos de red. La sobrescritura de los archivos puede ser con datos de basura o datos nulos, dependiendo de la muestra.
  • wht -> Este campo tiene algunos subcampos: fld -> Carpetas que no deben encriptarse; están en la lista blanca para evitar destruir archivos críticos en el sistema y los programas. fls -> Lista de listas blancas de archivos por nombre; estos archivos nunca serán encriptados y esto es útil para evitar destruir archivos críticos en el sistema. ext -> Lista de las extensiones de destino para evitar el cifrado basado en la extensión.
  • wfld -> Una lista de carpetas donde los archivos serán destruidos si la opción de borrar está habilitada.
  • prc -> Lista de procesos a matar para desbloquear archivos que están bloqueados por este / estos programa / s, por ejemplo, "mysql.exe".
  • dmn -> Lista de dominios que se usarán para el malware si la opción de red está habilitada; esta lista puede cambiar por muestra, para enviar información de la víctima.
  • net -> Este valor puede ser falso o verdadero. Por defecto, generalmente es cierto, lo que significa que el malware enviará información sobre la víctima si tiene acceso a Internet a la lista de dominios en el campo "dmn" en la configuración.
  • nbody -> Una gran cadena codificada en base64 que es la plantilla para la nota de rescate que aparecerá en cada carpeta donde el malware puede crearla.
  • nname -> La cadena del nombre del malware para el archivo de nota de rescate. Es una plantilla que tendrá una parte que será aleatoria en la ejecución.
  • exp -> Este campo es muy importante en la configuración. De manera predeterminada, generalmente será "falso", pero si es "verdadero" o si falla la comprobación del hash de la configuración, utilizará el exploit CVE-2018-8453. El malware tiene este valor como falso de forma predeterminada porque este exploit no siempre funciona y puede causar una pantalla azul de la muerte que evita que el objetivo del malware cifre los archivos y solicite el rescate. Si el exploit funciona, elevará el proceso al usuario del SISTEMA.
  • img -> Una cadena codificada en base64. Es la plantilla para la imagen que el malware creará en tiempo de ejecución para cambiar el fondo de escritorio con este texto.

Después de descifrar la configuración del malware, la analiza y el malware verificará el campo "exp" y, si el valor es "verdadero", detectará el tipo de sistema operativo que utiliza los campos PEB que informan la versión mayor y menor del OS.

FIGURA 6. COMPROBACIÓN DE LA VERSIÓN DEL SISTEMA OPERATIVO

Por lo general, solo se puede encontrar un sistema operativo, pero eso es suficiente para el malware. El malware verificará el tiempo de archivo para verificar si la fecha fue anterior o posterior a la instalación de un parche para corregir la vulnerabilidad. Si el tiempo de archivo es anterior al tiempo de archivo del parche, verificará si el sistema operativo es de 64 bits o 32 bits utilizando la función "GetSystemNativeInfoW". Cuando el sistema operativo es de 32 bits, usará un código shell integrado en el malware que es el exploit y, en el caso de un sistema operativo de 64 bits, usará otro código shell que puede usar una "Puerta del Cielo" para ejecutar código de 64 bits en un proceso de 32 bits.

FIGURA 7. COMPRUEBE SI EL SO ES DE 32 O 64 BITS

En el caso de que el campo sea falso o el exploit esté parchado, el malware volverá a verificar la versión del sistema operativo utilizando el PEB. Si el sistema operativo es Windows Vista, al menos obtendrá del token de proceso el nivel de privilegio de ejecución. Cuando el nivel de privilegio descubierto es inferior a 0x3000 (eso significa que el proceso se ejecuta como un administrador real en el sistema o SISTEMA), relanzará el proceso utilizando el comando 'runas' para elevar al proceso 0x3000 del nivel 0x2000 o 0x1000 de ejecución. Después de relanzarse con el comando "runas", la instancia de malware finalizará.

FIGURA 8. COMPRUEBE SI EL SO ES WINDOWS VISTA MINIMAL Y COMPRUEBE EL NIVEL DE EJECUCIÓN

La siguiente acción del malware es verificar si el privilegio de ejecución es SYSTEM. Cuando el privilegio de ejecución es SYSTEM, el malware obtendrá el proceso "Explorer.exe", obtendrá el token del usuario que inició el proceso y se hará pasar por él. Es una degradación de SYSTEM a otro usuario con menos privilegios para evitar afectar el escritorio del usuario de SYSTEM más adelante.

Después de esto, analizará nuevamente la configuración y obtendrá información de la máquina de la víctima. Esta información es el usuario de la máquina, el nombre de la máquina, etc. El malware prepara una identificación de víctima para saber quién se ve afectado en base a dos valores de 32 bits. concat en una cadena en hexadecimal.

La primera parte de estos dos valores es el número de serie del disco duro de la unidad lógica principal de Windows, y el segundo es el valor hash CRC32 que proviene del hash CRC32 del número de serie de la unidad principal lógica de Windows con una semilla codificado ese cambio por muestra.

FIGURA 9. OBTENGA EL NÚMERO DE SERIE DEL DISCO PARA HACER CRC32 HASH

Después de esto, el resultado se utiliza como semilla para hacer que el hash CRC32 tenga el nombre del procesador de la máquina. Pero este nombre del procesador no se extrae utilizando la API de Windows como lo hace GandCrab; en este caso, los autores de malware usan el opcode CPUID para tratar de hacerlo más ofuscado.

FIGURA 10. OBTENGA EL NOMBRE DEL PROCESADOR UTILIZANDO EL CÓDIGO CPUID

Finalmente, convierte estos valores en una cadena en una representación hexadecimal y los guarda.

Más tarde, durante la ejecución, el malware escribirá en el registro de Windows las siguientes entradas en la subclave "SOFTWARE recfg" (esta subclave puede cambiar en algunas muestras, pero generalmente no lo hace).

Las entradas clave son:

  • 0_key -> Tipo binario; Esta es la clave maestra (incluye la clave aleatoria generada por la víctima para encriptar más tarde junto con la clave de los autores del malware).
  • sk_key -> Como entrada 0_key, es la clave privada de la víctima cifrada pero con la clave pública afiliada codificada en la muestra. Es la clave utilizada en el descifrador por el afiliado, pero significa que los autores de malware siempre pueden descifrar cualquier archivo cifrado con cualquier muestra como recurso secundario para descifrar los archivos.
  • pk_key -> Víctima pública derivada de la clave privada.
  • subclave -> Clave pública afiliada para usar.
  • stat -> La información recopilada de la máquina víctima y utilizada para poner en la nota de rescate encriptada y en el envío POST a los dominios.
  • rnd_ext -> La extensión aleatoria para los archivos cifrados (puede tener de 5 a 10 caracteres alfanuméricos).

El malware intenta escribir la subclave y las entradas en la sección HKEY_LOCAL_MACHINE a primera vista y, si falla, las escribirá en la sección HKEY_CURRENT_USER.

FIGURA 11. EJEMPLO DE INSCRIPCIONES DE REGISTRO Y SUBSECCIÓN EN EL HKLM HIVE

La información que el malware obtiene de la máquina víctima puede ser el nombre de usuario, el nombre de la máquina, el dominio al que pertenece la máquina o, si no, el grupo de trabajo, el nombre del producto (nombre del sistema operativo), etc.

Una vez completado este paso, el malware verificará la opción "dbg" recopilada de la configuración y, si ese valor es 'verdadero', evitará verificar el idioma de la máquina pero si el valor es 'falso' (por defecto) , verificará el lenguaje de máquina y lo comparará con una lista de valores codificados.

FIGURA 12. OBTENGA EL IDIOMA DEL TECLADO DEL SISTEMA

El malware verifica la siguiente lista de idiomas en la lista negra (en algunos casos pueden cambiar por muestra):

  • 0x818 – Rumano (Moldavia)
  • 0x419 – ruso
  • 0x819 – Ruso (Moldavia)
  • 0x422 – ucranio
  • 0x423 – Bielorruso
  • 0x425 – Estonio
  • 0x426 – letón
  • 0x427 – lituano
  • 0x428 – Tayiko
  • 0x429 – persa
  • 0x42B – armenio
  • 0x42C – Azerí
  • 0x437 – georgiano
  • 0x43F – Kazajo
  • 0x440 – Kirguís
  • 0x442 –Turcomanos
  • 0x443 – Uzbeko
  • 0x444 – Tártaro
  • 0x45A – Sirio
  • 0x2801 – Árabe (Siria)

Observamos que Sodinokibi, como GandCrab y Anatova, también están en la lista negra del idioma sirio regular y el idioma sirio en árabe. Si el sistema contiene uno de estos idiomas, se cerrará sin realizar ninguna acción. Si se detecta un idioma diferente, continuará en el flujo normal.

Esto es interesante y puede insinuar que un afiliado está involucrado y que domina cualquiera de los idiomas. Esta idea se volvió especialmente interesante más adelante en nuestra investigación.

Si el malware continúa, buscará todos los procesos en la lista en el campo "prc" en la configuración y los terminará en un bucle para desbloquear los archivos bloqueados para este / estos procesos / es.

FIGURA 13. BUSCAR PROCESOS OBJETIVO Y TERMINARLOS

Después de esto, destruirá todos los volúmenes sombra de la máquina víctima y deshabilitará la protección del arranque de recuperación con este comando:

  • exe / c vssadmin.exe Eliminar Shadows / All / Quiet & bcdedit / set default recoveryenabled No & bcdedit / set default bootstatuspolicy ignoreallfailures

Se ejecuta con la función de Windows "ShellExecuteW".

FIGURA 14. COMANDO DE LANZAMIENTO PARA DESTRUIR LOS VOLUMENES DE LAS SOMBRAS Y DESTRUIR LA SEGURIDAD EN LA BOTA

A continuación, verificará el campo de la configuración "borrar" y, si es cierto, destruirá y eliminará todos los archivos con basura aleatoria o con valores NULL. Si el malware destruye los archivos, comenzará a enumerar todas las unidades lógicas y finalmente la red compartirá las carpetas con el nombre que aparece en el campo de configuración "wfld".

FIGURA 15. ARCHIVOS DE LIMPIEZA EN LAS CARPETAS OBJETIVO

En el caso de que un afiliado cree una muestra que haya definido muchas carpetas en este campo, el ransomware puede ser un limpiador sólido de la máquina completa.

La siguiente acción del malware es su función principal, encriptar los archivos en todas las unidades lógicas y recursos compartidos de red, evitar las carpetas y nombres en blanco de los archivos y extensiones, y dejar caer la nota de rescate preparada a partir de la plantilla en cada carpeta.

FIGURA 16. ARCHIVOS DE CRIPTO EN LAS UNIDADES LÓGICAS Y LAS ACCIONES DE LA RED

Después de terminar este paso, creará la imagen del escritorio en tiempo de ejecución con el texto que viene en el archivo de configuración preparado con la extensión aleatoria que afecta a la máquina.

El siguiente paso es verificar el campo "net" desde la configuración y, si es verdadero, comenzará a enviar un mensaje POST a la lista de dominios en el archivo de configuración en el campo "dmn".

FIGURA 17. PREPARE LA URL FINAL ALEATORIA POR DOMINIO PARA HACER EL COMANDO POSTAL

Esta parte del código tiene similitudes con el código de GandCrab, que destacaremos más adelante en este artículo.

Después de este paso, el malware limpia su propia memoria en vars y cadenas, pero no elimina el código del malware, pero elimina los contenidos críticos para evitar volcados o herramientas forenses que pueden recopilar información de la RAM.

FIGURA 18. MEMORIA LIMPIA DE VARS

Si el malware se estaba ejecutando como SYSTEM después del exploit, revertirá sus derechos y finalmente finalizará su ejecución.

FIGURA 19. REVERTIR EL NIVEL DE EJECUCIÓN DE PRIVILEGIO DEL SISTEMA

Comparación de código con GandCrab

Usando la muestra Sodinokibi desempaquetada y una versión v5.03 de GandCrab, comenzamos a usar IDA y BinDiff para observar cualquier similitud. Según el Gráfico de llamadas, parece que hay una superposición general de código del 40 por ciento entre los dos:

FIGURA 20. COMPARACIÓN DE GRÁFICO DE LLAMADAS

La mayor superposición parece estar en las funciones de ambas familias. Aunque los valores cambian, revisar el código revela patrones y flujos similares:

Aunque aquí y allá hay algunas diferencias, la estructura es similar:

Ya mencionamos que la parte del código responsable de la generación aleatoria de URL tiene similitudes con respecto a cómo se genera en el malware GandCrab. Sodinokibi está usando una función para ejecutar esta parte donde GandCrab está usando tres funciones para generar la URL aleatoria. Donde vemos una estructura similar es en las partes de la URL que se generará en ambos códigos de malware. Creamos un visual para explicar mejor la comparación:

FIGURA 21. COMPARACIÓN DE GENERACIÓN DE URL

Observamos cómo, aunque la forma en que ambas familias de ransomware generan la URL puede diferir, los directorios de URL y las extensiones de archivo utilizados tienen una similitud que parece ser más que una coincidencia. Esta observación también fue descubierta por Tesorion en uno de sus blogs.

En general, al observar la estructura y las coincidencias, los desarrolladores del código GandCrab lo usaron como base para crear una nueva familia o, otra hipótesis, es que la gente se apoderó del código fuente filtrado de GandCrab y comenzó el nuevo RaaS Sodinokibi.

Conclusión

Sodinokibi es una nueva amenaza seria de ransomware que está afectando a muchas víctimas en todo el mundo.

Ejecutamos un análisis en profundidad comparando GandCrab y Sodinokibi y descubrimos muchas similitudes, lo que indica que el desarrollador de Sodinokibi tenía acceso al código fuente y las mejoras de GandCrab. Las campañas de Sodinokibi están en curso y difieren en habilidades y herramientas debido a los diferentes afiliados que operan estas campañas, lo que plantea más preguntas por responder. ¿Cómo operan? ¿Y está funcionando el modelo de afiliación? McAfee ATR tiene las respuestas en el episodio 2, "The All Stars".

Cobertura

McAfee está detectando a esta familia con las siguientes firmas:

  • "Rescate-Sodinokibi"
  • "Ransom-REvil!".

Técnicas MITRE ATT & CK

La muestra de malware utiliza las siguientes técnicas MITER ATT & CK ™:

  • Descubrimiento de archivos y directorios
  • Eliminación de archivos
  • Modificar registro
  • Registro de consultas
  • Modificación de registro
  • Consulta de información del usuario
  • Archivos de cripta
  • Destruir archivos
  • Haga conexiones C2 para enviar información de la víctima
  • Modificar la configuración del sistema
  • Elevar privilegios

Regla de YARA

gobernar Sodinokobi

/ *

Esta regla detecta Sodinokobi Ransomware en la memoria en muestras antiguas y quizás futuras.

* /

meta:

autor = "equipo McAfee ATR"

versión = "1.0"

description = "Esta regla detecta Sodinokobi Ransomware en la memoria en muestras antiguas y tal vez en el futuro".

instrumentos de cuerda:

$ a = 40 0F B6 C8 89 4D FC 8A 94 0D FC FE FF FF 0F B6 C2 03 C6 0F B6 F0 8A 84 35 FC FE FF FF 88 84 0D FC FE FF FF 88 94 35 FC FE FF FF 0F B6 8C 0D FC FE FF FF

$ b = 0F B6 C2 03 C8 8B 45 14 0F B6 C9 8A 8C 0D FC FE FF FF 32 0C 07 88 08 40 89 45 14 8B 45 FC 83 EB 01 75 AA

condición:

todos ellos





Enlace a la noticia original