Profundizando en Sodinokibi Ransomware

Si bien el ransomware Sodinokibi ha aparecido en las noticias recientemente, los detalles técnicos de esa cepa en particular han sido mucho menos visibles. En este artículo, analizaremos Sodinokibi, arrojaremos luz sobre 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 atacantes afiliados a los que distribuyeron la infame familia de ransomware GandCrab, que se supone que se retirará pronto, según el foro clandestino donde apareció por primera vez GandCrab.
• El ransomware Sodinokibi explota una vulnerabilidad de Oracle WebLogic (CVE-2019-2725) para obtener acceso a la máquina 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 Unión de Repúblicas Socialistas Soviéticas (URSS).
• Esta variedad de ransomware utiliza algoritmos AES y Salsa20 para cifrar los archivos del usuario, AES se utiliza para cifrar las claves de sesión y los datos que se envían al servidor de control, los archivos del usuario se cifran mediante el cifrado Salsa20.
• Sodinokibi utiliza un algoritmo de intercambio de claves Diffie-Hellman de Curva Elíptica para generar y propagar claves de cifrado.
• Una vez que se infiltra en una máquina, borra todos los archivos de la carpeta de copia de seguridad.
• Actualmente, el ransomware exige 0,32806964 BTC (≈ $2.500) para recuperar el acceso a los archivos cifrados. 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ó con 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 la situación aún más desafiante 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í.

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 se 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 la máquina. 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 de shell, según la arquitectura de la plataforma. Creemos que intenta elevar su privilegio explotando CVE-2018-8440.

Figura 2: Fragmento 1

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

Si el sistema no es vulnerable y el proceso aún se está ejecutando como un usuario limitado, 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 código a continuación.

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 que pueda obtener acceso a los archivos MySQL para el cifrado, luego elimina todas las COPIAS SOMBRAS de Windows (mecanismo de copia de seguridad integrado de Windows) usando vssadmin y deshabilita Windows recuperación usando 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 cifrar 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 de Curva Elíptica (ECDH, por sus siglas en inglés) 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 cifrado simétrico AES y Salsa20 que se utilizan para cifrar diferentes tipos de datos.

• El cifrado AES se utiliza para cifrar las claves privadas del par de claves público-privadas, que se genera localmente en la máquina 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 binario. Estas claves públicas se utilizarán para cifrar la clave privada generada localmente. A continuación, detallamos los pasos incluidos en el proceso de generación de claves y cifrado.

Paso 1. Genere una sesión privada (número secreto, aleatorio) y un par de claves públicas en la máquina local.

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

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

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

Paso 3. Utilice 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 usando una clave compartida

Paso 4. Genere un Vector de Inicialización (IV, por sus siglas en inglés) de 16 bytes.

Paso 5. Cifre 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. Calcule el CRC32 de la clave privada cifrada generada en el Paso 5.

Paso 7. Añada el IV y CRC32 al final del búfer que contiene la clave privada cifrada del Paso 5.

Paso 8. Guarde este búfer en un desplazamiento de archivo mapeado marcado como "sk_key" en la memoria.

Figura 8: Cifrado de la clave privada del Paso 1 usando las claves públicas del atacante

Cifrar la clave privada del Paso 1 utilizando la clave pública presente incrustada en el binario

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

Paso 10. Guarde este búfer en un desplazamiento 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 cifrada en el registro

Generar claves por archivo para Salsa20

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

Paso 12. Genere 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. Genere un IV de 8 bits para la clave Salsa20.

Paso 15. Genere una clave Salsa20.

Paso 16. Utilice este key_state de Salsa20 para cifrar los archivos de usuario mediante el cifrado de Salsa20.

Figura 10: Generación de clave Salsa20 por archivo

Repita los Pasos del 11 al 16 para cada archivo que desee cifrar.

Ilustración de cifrado y descifrado

Para comprender cómo se generan y transfieren las claves entre el atacante y la máquina de la víctima, debemos observar cómo funciona Diffie Hellman con la ayuda de la imagen a continuación.

Figura 11: Intercambio de claves Diffie-Hellman de Curva Elíptica (ECDH) 

El proceso de cifrado de Sodinokibi en detalle

Figura 12: Proceso de cifrado

El proceso de descifrado de Sodinokibi en detalle

El proceso de descifrado 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 descifrado (el secreto del atacante es la clave privada del atacante)

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

Figura 14

Para cifrar archivos de usuario, Sodinokibi utiliza puertos de finalización de E/S y crea varios subprocesos de cifrado 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 de 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 el cifrado 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 PostQueuedCompletionStatus de Win API 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 cifrar archivos. AddFileToIoCompletionPort también genera una clave Salsa20 única para cada archivo que se va a cifrar y pasa esta clave Salsa20 al hilo de cifrado como parte de la estructura que contiene otros metadatos que deben escribirse en el archivo también después del cifrado utilizando el parámetro lpOverlapped de Win API PostQueuedCompletionStatus. Durante la enumeración, también crea un archivo de ransom 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 cifrados y renombrados sea igual al número total de archivos agregados al puerto de finalización de E/S para el cifrado.

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 archivo exentas

• "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"

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 sesión cifrada Clave privada, Clave pública ECDH por archivo y el IV Salsa20 por archivo utilizado para cifrar los archivos y luego renombrarlos agregando un nombre de extensión generado aleatoriamente. Los archivos se cifran utilizando el algoritmo de cifrado Salsa20 (variante Chacha) dentro de la función de usuario EncryptAndWrite.

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

Figura 16

Figura 17: Estructura del archivo cifrado

Una vez que se completa 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 cifrado. Los datos preparados también se guardan en la clave de registro “[HKLM|HKCU]\SOFTWARE\recfg\stat” antes de cifrarlos con AES y enviarlos al servidor del atacante.

Figura 18: Datos enviados a través de la red

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

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 hay un descifrador gratuito disponible para este ransomware y la única opción es utilizar el servicio de descifrado proporcionado por los atacantes, al que se puede acceder siguiendo las instrucciones de la nota de rescate.

El descifrado es el siguiente 

Figura 21

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

Los productos de protección cibernética como la solución personal Acronis True Image 2020 o la solución empresarial Acronis Backup vienen con la defensa antimalware basada en inteligencia artificial Acronis Active Protection integrada y, por lo tanto, pueden proteger a los usuarios contra el ransomware Sodinokibi.

Figura 22: Acronis Active Protection detecta Sodinokibi