Profundizando en el ransomware Sodinokibi

Si bien el ransomware Sodinokibi ha aparecido en las noticias recientemente, los detalles técnicos de dicha cepa en particular han tenido bastante menos visibilidad. En este artículo, analizaremos Sodinokibi, explicaremos en detalle cómo funciona y revisaremos cómo puede proteger su sistema de esta amenaza.

Investigado y escrito por Ravikant Tiwari y Alexander Koshelev

• Es probable que Sodinokibi esté siendo distribuido por agresores asociados a los que distribuyeron la infame familia de ransomware GandCrab, que se supone ha de retirarse pronto según el foro clandestino donde apareció por primera vez GandCrab.
• El ransomware Sodinokibi se aprovecha de una vulnerabilidad de Oracle WebLogic (CVE-2019-2725) para obtener acceso al equipo de la víctima. Una vez que está dentro, el malware intenta ejecutarse con derechos de usuario elevados para acceder a todos los archivos y recursos del sistema sin ninguna restricción.
• Sodinokibi intenta evitar infectar ordenadores de Irán, Rusia y otros países que antes formaban parte de la URSS.
• Esta cepa de ransomware utiliza algoritmos AES y Salsa20 para encriptar los archivos del usuario, AES se utiliza para encriptar las claves de sesión y los datos que se envían al servidor de control, los archivos del usuario se encriptan mediante el cifrado Salsa20.
• Sodinokibi utiliza un algoritmo de intercambio de claves Diffie-Hellman de curva elíptica para generar y propagar claves de encriptación.
• Una vez que se infiltra en un equipo, elimina todos los archivos de la carpeta de respaldo.
• Actualmente, el ransomware exige 0,32806964 BTC (≈ $2,500) para recuperar el acceso a los archivos encriptados. Afirman que esta cantidad debe pagarse en cuatro días o se duplicará la demanda de rescate.

La muestra de ransomware Sodinokibi que analizamos se empaquetó mediante el uso de un empaquetador personalizado. Incluso después de un desempaquetado exitoso, el código principal de Sodinokibi no parece tener una cadena legible. Tampoco tiene importaciones para bibliotecas del sistema y API, lo que significa que un escáner AV estático que depende de una cadena legible y una tabla API importada tendrá dificultades para detectarlo.

Los nombres de API y otras cadenas requeridas se descifran durante su tiempo de ejecución utilizando el algoritmo RC4. Para lograr que la situación sea aún más compleja para el software antivirus, la mayoría de las operaciones en cadenas se realizan utilizando un hash DJB de la cadena en lugar de la cadena en sí misma.

Sodinokibi comienza construyendo una tabla de importación dinámica y asegurándose de que esta sea la única instancia que se esté ejecutando actualmente en el sistema con la ayuda de mutex. Una vez que pasa la verificación de mutex, descifra la configuración JSON almacenada dentro del binario usando RC4 y busca el valor de clave booleana “exp”. Si se establece en “true”, Sodinokibi intenta ejecutar un exploit. En nuestro caso, el valor de la clave “exp” se establece en true, por lo que procede a ejecutar la función de explotación

Figura 1: Configuración JSON descifrada

El código responsable de ejecutar el exploit primero verifica si el parche del 11 de septiembre de 2018  (KB4457138) se aplica en el equipo. Este parche soluciona varias vulnerabilidades que se mencionan a continuación. Si no se detecta el parche, el ransomware procede a ejecutar una versión de 32 o 64 bits del código shell según la arquitectura de la plataforma. Creemos que intenta elevar su privilegio aprovechándose de CVE-2018-8440.

Figura 2: Fragmento 1

Las vulnerabilidades abordadas por el parche KB4457138 se enumeran en la siguiente tabla:

Si el sistema no es vulnerable y el proceso aún se está ejecutando como un usuario restringido, usará un comando RUNAS para lanzar otra instancia con derechos administrativos y finalizará la instancia actual si se está ejecutando con privilegios limitados. El flujo completo se puede ver en el siguiente código.

Figura 3:

Una vez que Sodinokibi se inicia con éxito en el modo de administrador, realiza una verificación previa adicional basada en la clave “bro” en la configuración JSON y el país. Intentará no infectar equipos de los siguientes países según la configuración regional del equipo.

Figura 4: ID de idioma coincidentes

Lista de países exentos

Después de pasar la verificación previa, finaliza el proceso mysql.exe (si se está ejecutando) para poder obtener acceso a los archivos MySQL para la encriptación, luego elimina todas las COPIAS SOMBRAS de Windows (mecanismo de copia de seguridad integrado de Windows) por medio de vssadmin y deshabilita la recuperación de Windows empleando bcdedit (editor de políticas de arranque) como se muestra a continuación:

vssadmin.exe Delete Shadows /All /Quiet & bcedit /set {default} recoveryenabled No & bcedit /set {default} bootstatuspolice ignorealfailures

Figura 5:

Antes de encriptar los archivos del usuario, Sodinokibi busca en todo el sistema de archivos y en los recursos compartidos de la red todos los directorios denominados “copia de seguridad” y los elimina. Curiosamente, antes de borrar todos los archivos dentro de este directorio, sobrescribe el contenido con bytes aleatorios para hacer imposible la recuperación de archivos. Afortunadamente, los archivos de Acronis Backup no se pueden eliminar fácilmente, ya que están protegidos mediante controladores en modo kernel para frustrar dicha eliminación ilícita por ransomware.

Sodinokibi utiliza un algoritmo de intercambio y generación de claves Diffie-Hellman (ECDH) de curva elíptica para generar un par de claves público-privadas. Utiliza esto para generar un secreto compartido, que se utilizará como clave para los algoritmos de encriptado simétrico AES y Salsa20 que se utilizan para encriptar diferentes tipos de datos.

• La encriptación AES se utiliza para cifrar las claves privadas del par de claves público-privadas, que se genera localmente en el equipo del usuario, así como los datos enviados a través de la red.
• Salsa20, por otro lado, se utiliza para cifrar archivos de usuario.

Sodinokibi se envía con dos claves públicas diferentes, una como parte de la configuración JSON y otra incrustada en el propio binario. Estas claves públicas se utilizarán para encriptar la clave privada generada localmente. A continuación, detallamos los pasos incluidos en el proceso de generación de claves y encriptado.

Paso 1: Generar una sesión privada (número secreto, aleatorio) y un par de claves públicas en el equipo local.

Figura 6: Generación de claves públicas y privadas

Encriptar la clave privada del Paso 1 usando la clave pública presente en la configuración JSON

Paso 2: Generar otro par de claves pública y privada.

Paso 3: Utilizar la clave privada del Paso 2 y la clave pública (valor de clave pk) de JSON para generar una clave compartida y aplicar un hash para generar una clave simétrica.

Figura 7: Generación de una clave simétrica utilizando una clave compartida

Paso 4: Generar un IV de 16 bytes (vector de inicialización).

Paso 5: Encriptar la clave privada generada en el Paso 1 usando el cifrado AES con la Clave y el IV generados en los Pasos 3 y 4.

Paso 6: Calcular el CRC32 de la clave privada encriptada generada en el Paso 5.

Paso 7: Añadir IV y CRC32 al final del búfer que contiene la clave privada encriptada del Paso 5.

Paso 8: Guardar este búfer en un desfase de archivo mapeado marcado como "sk_key" en la memoria.

Figura 8: Encriptar la clave privada del paso uno usando las claves públicas del atacant

Encriptar la clave privada del Paso 1 usando la clave pública presente e incrustada en el binario

Paso 9: Repetir los pasos 2 a 7 utilizando una clave pública diferente que viene incrustada en el binario para el Paso 3.

Paso 10: Guardar este búfer en un desfase de archivo mapeado marcado como “0_key” en la memoria.

Sk_key, 0_key y pk_key se escriben en la siguiente clave de registro, respectivamente, según los derechos de acceso.

HKLM\SOFTWARE\recfg\sk_key   OR    HKCU\SOFTWARE\recfg\sk_key

HKLM\SOFTWARE\recfg\0_key   OR   HKCU\SOFTWARE\recfg\0_key

HKLM\SOFTWARE\recfg\pk_key   OR   HKCU\SOFTWARE\recfg\pk_key

Figura 9: Clave secreta encriptada en registro

Generación de claves de archivo para Salsa20

Paso 11: Generar un nuevo par de claves pública y privada.

Paso 12: Generar una clave compartida usando la clave pública de sesión generada en el Paso 2 y hash para obtener otra clave simétrica para usar en la generación de claves Salsa20.

Paso 13: Configurar un estado de clave Salsa20 de 256 bits (32 bytes)

Paso 14: Generar un IV de 8 bits para la clave Salsa20

Paso 15: Generar una clave Salsa20

Paso 16: Utilizar esta key_state de Salsa20 para encriptar los archivos de usuario mediante la encriptación de Salsa20.

Figura 10: Generación de clave Salsa20 por archivo

Repita los pasos del 11 al 16 para cada archivo que desee encriptar.

Ilustración de encriptación y desencriptación

Para comprender cómo se generan y transfieren las claves entre el atacante y el equipo de la víctima, debemos observar cómo funciona Diffie Hellman con la ayuda de la siguiente imagen.

Figura 11: Intercambio de claves Diffie-Hellman (ECDH) de curva elíptica

El proceso de encriptación de Sodinokibi en detalle

Figura 12: Proceso de encriptación

El proceso de desencriptación de Sodinokibi en detalle

El proceso de desencriptación requerirá el conocimiento de la clave privada del atacante que no se divulga públicamente y, por lo tanto, no es posible restaurar los archivos.

Figura 13: Proceso de desencriptación (el secreto del atacante yace en su clave privada)

La versión simplificada de cómo se verá el proceso de desencriptación de los archivos de usuario figura en el gráfico a continuación.

Figura 14:

Para encriptar archivos de usuario, Sodinokibi utiliza puertos de finalización de E/S y crea varios subprocesos de encriptación hasta un máximo del doble de la cantidad de núcleos de procesador presentes en la máquina y asocia estos subprocesos al puerto de finalización de E/S creado. Estos subprocesos utilizan la función GetQueuedCompletionStatus Win API para esperar a que un paquete de finalización se ponga en cola en el puerto de finalización de E/S antes de continuar con la encriptación de archivos.

Una vez que se crean los subprocesos y se espera que lleguen los paquetes de E/S, Sodinokibi comienza a enumerar los archivos de usuario en todas las unidades locales y recursos compartidos de red, excepto las unidades CDROM y RAMDISK, y comienza a asociar archivos que no están en la carpeta, archivo o lista de extensión de archivo exentos a este puerto de finalización de E/S llamando a la función de usuario AddFileToIoCompletionPort y llama a Win API PostQueuedCompletionStatus para publicar un paquete de E/S en los puertos de finalización de E/S que activará el hilo que espera en este puerto de finalización de E/S para reanudar y proceder a encriptar archivos. AddFileToIoCompletionPort también genera una clave Salsa20 única para cada archivo que se ha de encriptarse y pasa esta clave Salsa20 al hilo de encriptado como parte de la estructura que contiene otros metadatos que deben escribirse en el archivo también después de la encriptación utilizando el parámetro lpOverlapped de Win API PostQueuedCompletionStatus. Durante la enumeración, también crea un archivo de nota de rescate en todas las carpetas que no están en la lista de carpetas exentas. Una vez que no hay más archivos para enumerar, el subproceso principal espera en un bucle hasta que el número total de archivos encriptados y renombrados sea igual al número total de archivos agregados al puerto de finalización de E/S para la encriptación.

Finalmente, establece una bandera que indica que no hay más archivos para enumerar y publica múltiples paquetes de finalización de E/S; al hacer esto, se asegura de que los subprocesos adicionales que esperan archivos se reanuden y rompan el flujo de ejecución para finalizar de inmediato.

Figura 15:

Carpetas exentas

• "$windows.~bt"
• "intel"
• "program files (x86)"
• "program files"
• "msocache"
• "$recycle.bin"
• "$windows.~ws"
• "tor browser"
• "boot"
• "system volume information"
• "perflogs"
• "google"
• "application data"
• "windows"
• "programdata"
• "windows.old"
• "appdata"
• "mozilla"

Archivos exentos

• "bootfont.bin"
• "boot.ini"
• "ntuser.dat"
• "desktop.ini"
• "iconcache.db"
• "ntldr"
• "ntuser.dat.log"
• "thumbs.db"
• "bootsect.bak"
• "ntuser.ini"
• "autorun.inf"

Extensiones de archivos exentos

• "themepack"
• "ldf"
• "scr"
• "icl"
• "386"
• "cmd"
• "ani"
• "adv"
• "theme"
• "msi"
• "rtp"
• "diagcfg"
• "msstyles"
• "bin"
• "hlp"
• "shs"
• "drv"
• "wpx"
• "deskthemepack"
• "bat"
• "rom"
• "msc"
• "lnk"
• "cab"
• "spl"
• "ps1"
• "msu"
• "ics"
• "key"
• "msp"
• "com"
• "sys"
• "diagpkg"
• "nls"
• "diagcab"
• "ico"
• "lock"
• "ocx"
• "mpa"
• "cur"
• "cpl"
• "mod"
• "hta"
• "exe"
• "icns"
• "prf"
• "dll"
• "nomedia"
• "idx"

The encrypting thread takes care of reading the file contents, encrypting it, writing it back to the same file, writing metadata that contains encrypted session Private key the per file ECDH Public key and per file Salsa20 IV used for encrypting the files and then renaming it by appending with a randomly generated extension name. File are encrypted using Salsa20 (Chacha variant) encryption algorithm inside EncryptAndWrite user function.

El hilo de cifrado se encarga de leer el contenido del archivo, cifrarlo, volver a escribirlo en el mismo archivo, escribir metadatos que contienen la Clave privada de sesión la clave pública ECDH por archivo y Salsa20 IV por archivo que se utilizó para cifrar los archivos y luego cambiarle el nombre agregando un nombre de extensión generado aleatoriamente. Los archivos se encriptan utilizando el algoritmo de encriptación Salsa20 (variante Chacha) dentro de la función de usuario EncryptAndWrite.  

TEl siguiente fragmento muestra el código para la función de usuario EncryptingThreadRoutine.

Figura 16:

Figura 17: Estructura de archivo encriptado

Una vez finalizado el proceso de cifrado, el ransomware prepara los datos para enviarlos al servidor de control. Estos datos contienen diferentes campos de la configuración JSON, información del sistema y claves de encriptación. Los datos preparados también se guardan en la clave de registro "[HKLM|HKCU]\SOFTWARE\recfg\stat" antes de encriptarlos con AES y enviarlos al servidor del atacante.

Figura 18: Datos enviados por la red

La información se envía a una URL generada aleatoriamente que tiene el formato

en donde:

Figura 19: Generación de URL

Sodinokibi contiene una plantilla de su nota de rescate con marcadores de posición para detalles específicos del usuario. Estos marcadores de posición se sustituyen dinámicamente con el nombre de extensión específico del usuario, la identificación del usuario (uid; consulte la tabla anterior para obtener una descripción) y la clave. La nota de rescate se coloca en cada directorio excluyendo el de la lista blanca.

Figura 20:

No existe un desencriptador gratuito disponible para este ransomware y la única opción es utilizar el servicio de descencriptado proporcionado por los atacantes, al que se puede acceder siguiendo las instrucciones de la nota de rescate.

La desencriptación aparece a continuación

Figura 21:

Para protegerse contra el ransomware, recomendamos utilizar una solución anti-ransomware avanzada y mantener una solución antivirus actualizada. Todos los productos de Acronis están equipados con tecnología avanzada anti-ransomware y pueden protegerlo contra cualquier ataque de este tipo y minimizar el riesgo de pérdida de datos.

Los productos de ciberprotección como la solución personal Acronis True Image 2020 o la solución empresarial Acronis Backup vienen con la defensa antimalware basada en IA Acronis Active Protection incorporada y, por lo tanto, pueden proteger usuarios contra el ransomware Sodinokibi.

Figura 22: Acronis Active Protection detecta Sodinokibi