un nuevo ransomware que despliega herramientas para desactivar soluciones de seguridad

Los investigadores de ESET han descubierto nuevas herramientas basadas en Rust que conducen al despliegue del ransomware Embargo, un actor relativamente nuevo, observado por primera vez por ESET en junio de 2024. El nuevo kit de herramientas consiste en un loader y un killer EDR, llamados MDeployer y MS4Killer respectivamente por ESET. MS4Killer es particularmente notable, ya que se compila a medida para el entorno de cada víctima, apuntando sólo a soluciones de seguridad seleccionadas. Ambas herramientas están escritas en Rust, el lenguaje elegido por el grupo Embargo para desarrollar su ransomware.

Puntos clave de este blogpost:

• Embargo está desarrollando y probando nuevas herramientas basadas en Rust.
• Las diferencias en las versiones desplegadas, los errores y los artefactos sobrantes sugieren que estas herramientas están en desarrollo activo.
• El actor de la amenaza abusa del modo seguro para desactivar las soluciones de seguridad.
• Embargo adapta sus herramientas a cada víctima.

Resumen

En julio de 2024, observamos incidentes de ransomware dirigidos a empresas estadounidenses, en los que el actor de la amenaza utilizaba sus nuevas herramientas. Las versiones de MDeployer y MS4Killer observadas en cada intrusión difieren ligeramente, lo que sugiere que las herramientas se están desarrollando activamente. Curiosamente, detectamos dos versiones diferentes de MDeployer en una sola intrusión, probablemente modificadas tras un primer intento fallido.

Este artículo se centra en el análisis de MDeployer y MS4Killer y en la actividad previa a la ejecución del ransomware Embargo. MDeployer es un loader malicioso utilizado para el despliegue de los ransomware MS4Killer y Embargo. MS4Killer es un EDR killer que abusa de un controlador vulnerable para desactivar los productos de seguridad que se ejecutan en la máquina de la víctima.

Embargo

Embargo, observado por primera vez en la telemetría de ESET en junio de 2024, hizo su aparición pública en mayo de 2024. Aparte de lograr vulnerar objetivos de alto perfil, el grupo llamó la atención por su elección del lenguaje de programación para el payload del ransomware. Embargo eligió Rust, un lenguaje de programación multiplataforma que permite el desarrollo de un ransomware más versátil dirigido tanto a Windows como a Linux. Después de BlackCat y Hive, Embargo es otro grupo que desarrolla payloads de ransomware en Rust.

Por su modus operandi, Embargo parece ser un grupo bien dotado de recursos. Establece su propia infraestructura para comunicarse con las víctimas (Figura 1), pero también permite la comunicación a través de Tox. El grupo presiona a las víctimas para que paguen mediante una doble extorsión y publica los datos robados en su sitio de filtraciones. En una entrevista con un presunto miembro del grupo, el representante del grupo menciona un esquema de pago básico para afiliados, lo que sugiere que el grupo está proporcionando RaaS (ransomware como servicio). Los recientes desórdenes policiales, que afectaron a grupos notorios como BlackCat y LockBit, provocaron cierta reorganización en el espacio RaaS. Estos cambios en el entorno global de RaaS apoyan la aparición de un nuevo actor sofisticado. Dada la sofisticación del grupo, la existencia de un sitio típico de filtraciones y las afirmaciones del grupo, suponemos que Embargo opera efectivamente como proveedor de RaaS.

Las payloads del ransomware de Embargo que observamos durante los incidentes de julio de 2024 comparten estos atributos:

• El ransomware Embargo deja caer su nota de rescate (Figura 2) llamada HOW_TO_RECOVER_FILES.txt en cada directorio cifrado.
• Los archivos cifrados obtienen una extensión aleatoria de seis letras formada por caracteres hexadecimales, por ejemplo, .b58eeb o .3d828a.
• Las payloads crean el mutex IntoTheFloodAgainSameOldTrip.

En un análisis previo de los investigadores de Cyble, las payloads crearon el mutex LoadUpOnGunsBringYourFriends. Cabe destacar que los nombres de ambos mutex se basan en letras de canciones de rock populares. Nuestro análisis coincide con el del artículo de Cyble.

MDeployer

MDeployer es el principal loader malicioso que Embargo intenta desplegar en las máquinas de la red comprometida: facilita el resto del ataque, lo que resulta en la ejecución del ransomware y el cifrado de archivos.

Basándonos en el campo del nombre en la sección IMAGE_EXPORT_DIRECTORY de su cabecera PE, podemos decir que Embargo llama a esta herramienta Deployer. Por lo tanto, decidimos referirnos a ella como MDeployer – EMbargo Deployer.

Su objetivo principal es descifrar dos archivos cifrados a.cache y b.cache (soltados por una etapa anterior desconocida) y ejecutar dos payloads: MS4Killer y el ransomware Embargo.

• Primero intenta descifrar el payload MS4Killer del archivo b.cache, suelta el archivo descifrado en praxisbackup.exe y lo ejecuta.
• A continuación, hace lo mismo con el payload del ransomware, que se descifra de a.cache, se guarda como pay.exe y se ejecuta.
• Cuando el ransomware termina de cifrar el sistema, MDeployer finaliza el proceso de MS4Killer, elimina las payloads descifradas y un archivo de controlador soltado por MS4Killer, y finalmente reinicia el sistema.

Se espera que MS4Killer se ejecute indefinidamente, y MDeployer lo verifica llamando a la función de la API WaitForSingleObject, esperando el valor de retorno WAIT_TIMEOUT. Si no se está ejecutando como debería, MDeployer registra el mensaje sysmon exited early y sale sin ejecutar el segundo payload. Hablaremos del registro más adelante en este blogpost.

En todas las versiones de MDeployer que hemos visto, ambos payloads fueron descifrados utilizando la misma clave RC4 – wlQYLoPCil3niI7x8CvR9EtNtL/aeaHrZ23LP3fAsJogVTIzdnZ5Pi09ZVeHFkiB.

Durante su ejecución, MDeployer interactúa con múltiples archivos. Para facilitar la comprensión, la Figura 3 muestra la relación entre los archivos.

La Tabla 1 enumera sus finalidades.

Tabla 1. Archivos manipulados por MDeployer Ficheros manipulados por MDeployer

Abuso del Modo Seguro

Con una sola excepción entre los incidentes que investigamos, donde lo vimos desplegado como DLL, MDeployer se compiló como un archivo EXE. La variante DLL contiene la capacidad adicional de desactivar las soluciones de seguridad.

Para una visión general del flujo de ejecución de la DLL, consulte la Figura 4.

La primera diferencia se produce justo al principio de la ejecución de la DLL: esta versión comprueba si existe el archivo stop.exe. La existencia de este archivo significa que MDeployer ya se ejecutó en el pasado y, o bien desplegó con éxito el payload del ransomware, o bien salió con un error. Por lo tanto, si se encuentra el archivo, el loader sólo hace su rutina de limpieza y sale. Nótese que las versiones EXE crean el archivo stop.exe, pero nunca comprueban su existencia.

Lo siguiente que hace la versión DLL de MDeployer es comprobar si se ejecutó con privilegios de administrador. Si no lo fue, continúa exactamente igual que la versión EXE. De hecho, las versiones EXE probablemente fueron compiladas usando el código fuente de esta única rama de ejecución.

Sin embargo, si se ejecutó con privilegios de administrador, el loader intenta reiniciar el sistema de la víctima en Modo Seguro para desactivar las soluciones de seguridad seleccionadas.

El Modo Seguro, un modo de diagnóstico del sistema operativo Windows, ejecuta el sistema con una funcionalidad mínima. Por este motivo, la mayoría de las medidas y protecciones de ciberseguridad no están activas en el Modo Seguro, lo que brinda a los actores de amenazas la oportunidad de aprovecharlo para evitar ser detectados. Esta técnica es conocida entre los grupos de ransomware maduros y se ha abusado de ella en el pasado, como informó Forbes en 2022.

La desactivación de la seguridad se produce en dos pasos.

Primer paso

El propósito del primer paso es reiniciar el sistema en modo seguro. El loader logra esto utilizando una combinación de herramientas de línea de comandos de Windows bcdedit, sc, y reg para:

• establecer el Modo a prueba de fallos como modo de arranque predeterminado,
• desactivar Windows Defender en Modo Seguro,
• crear un servicio, irnagentd, que ejecute el loader después de que el sistema se reinicie en Modo Seguro, y
• reinicie el sistema.

Consulte la sección Comandos utilizados por MDeployer para ver la lista completa de comandos ejecutados por el loader.

Paso 2

Una vez en modo seguro, el loader desactiva las herramientas de seguridad seleccionadas renombrando sus directorios de instalación y, a continuación, ejecuta el payload del ransomware Embargo.

Después, realiza una “limpieza en modo seguro”: elimina el archivo pay.exe descifrado del ransomware, crea el archivo de flujo de control stop.exe para evitar el doble cifrado, elimina el servicio de persistencia irnagentd y reinicia el sistema en modo normal.

Desactivador BAT

En uno de los incidentes, también vimos la funcionalidad extra del loader DLL implementada como un script BAT. Este script tiene como objetivo una única solución de seguridad – un tema que encontrarás de nuevo, más adelante en este artículo. Utilizó la misma técnica de reiniciar en Modo Seguro con la ayuda de un servicio de persistencia, irnagentd, y luego renombrar el directorio de instalación del software de seguridad instalado. Incluso utilizó el mismo archivo stop.exe para el flujo de control y registró los mensajes de error en fail.exe(fail.txt en MDeployer).

Esto demuestra una vez más que Embargo modifica sus herramientas para adaptarlas al entorno de cada víctima.

Registro

En caso de que MDeployer encuentre algún error, registra los mensajes de error en el archivo fail.txt y luego crea el archivo stop.exe.

Hay cuatro etapas que el atacante distingue en sus mensajes de registro – utiliza un prefijo diferente para registrar los errores en cada una de ellas:

• [dec] – descifrado de el payload,
• [exec] – ejecución del ransomware,
• [execk] – ejecución de MS4Killer, y
• [kler] – ejecución de MS4Killer (este prefijo se utiliza cuando MS4Killer sale inesperadamente).

En la versión DLL hay prefijos de mensajes de registro adicionales en comparación con las versiones EXE:

• [sc], [sc delete] – creación o eliminación del servicio irnagentd,
• [reg], [reg-del] – modificación del registro de Windows, y
• [setsb] – uso de la herramienta de línea de comandos bcdedit.exe para establecer el Modo Seguro en el siguiente reinicio.

Limpieza

MDeployer tiene varias variantes de una rutina de limpieza que se lanza en diferentes ocasiones. Esto sucede después de que el loader ejecuta con éxito el payload del ransomware, y también si se encuentra algún error durante la ejecución del loader.

Durante la limpieza, el loader finaliza el proceso MS4Killer, elimina las payloads descifradas y el controlador vulnerable soltado por MS4Killer, y crea el archivo de control de flujo stop.exe.

En caso de que la rutina de limpieza haya sido provocada por la existencia de stop.exe, MDeployer también elimina su propio archivo PE.

Finalmente, reinicia el sistema llamando a shutdown -r -f -t 00.

Ejecución

En todos los casos observados, la persistencia del loader se logró mediante una tarea programada, Perf_sys (Figura 5), creada por un usuario del sistema ya elevado BITCH\Administrator.

En uno de los casos, también recogimos un script PowerShell que conducía a la ejecución de MDeployer. El script era notablemente similar al utilizado por WinRM-fs, por lo que asumimos con una confianza media que Embargo utilizó esa herramienta o una similar para entregar el loader desde una máquina desprotegida.

Desarrollo activo

Hay varias inconsistencias y ejemplos de “flujo de control desordenado” en las muestras de loaderes que hemos visto hasta ahora que sugieren que las herramientas del grupo están todavía en desarrollo activo y no “listas para producción”.

El hecho de que MDeployer elimine el controlador vulnerable eliminado por MS4Killer es especialmente interesante porque demuestra que las dos herramientas se están desarrollando conjuntamente. Sin embargo, existe un solapamiento parcial en la funcionalidad: tanto MS4Killer como la versión DLL de MDeployer intentan desactivar las soluciones de seguridad.

No es raro ver cómo el loader elimina los archivos de payload sólo para intentar ejecutar uno de ellos inmediatamente después. Véase la Figura 6, donde MDeployer llama a la función de limpieza, durante la cual se elimina pay.exe, pero luego intenta ejecutar ese mismo archivo.

De hecho, la versión DLL del loader que hemos visto contiene varios errores que impiden que funcione del todo. Esto podría explicar por qué hemos visto varias versiones del loader utilizadas en un solo incidente: es probable que el actor de la amenaza descubra estos problemas sobre la marcha y tenga que adaptarse sobre la marcha.

MS4Killer

MS4Killer es una herramienta típica de evasión de defensas que termina los procesos de productos de seguridad utilizando la técnica conocida como Bring Your Own Vulnerable Driver (BYOVD). Está escrito, al igual que el loader, en Rust. Creemos que MS4Killer se inspiró en gran medida en s4killer, una prueba de concepto (POC) publicada en GitHub, convenientemente escrita también en Rust. Debido al parecido con esta POC existente, nos referimos a esta herramienta como MS4Killer – abreviatura de EMbargo s4killer.

Ampliación de la funcionalidad

s4killer está diseñado para seleccionar un proceso en ejecución y terminarlo desde el kernel. Lo hace instalando y abusando de un driver vulnerable que se almacena en una variable global (sección.rdata en el código compilado). El PID del proceso a terminar se pasa a s4killer como argumento del programa. La terminación se realiza a través de FilterConnectCommunicationPort y FilterSendMessage de la API del minifiltro.

Embargo extendió la funcionalidad POC con las siguientes características:

• MS4Killer se ejecuta en un bucle sin fin, buscando constantemente procesos en ejecución.
• La lista de nombres de procesos a matar está codificada en el binario.
• El blob del controlador incrustado se cifra utilizando RC4.
• Las cadenas binarias se cifran mediante XOR simple, es decir, los mensajes de registro, los nombres de los procesos y la clave RC4 utilizada para descifrar el controlador.
• Durante la fase de terminación del proceso, MS4Killer se genera a sí mismo como un proceso hijo, pasando el PID del proceso a matar como argumento.
• El escaneo de procesos y la terminación de procesos se dividen en múltiples hilos utilizando Rayon, una librería de paralelismo de datos para Rust.

BYOVD

Bring your own vulnerable driver es una técnica bien conocida en la que un actor de amenazas abusa de controladores de kernel firmados y vulnerables para obtener la ejecución de código a nivel de kernel. Los afiliados al ransomware suelen incorporar herramientas BYOVD en su cadena de compromiso para manipular las soluciones de seguridad que protegen la infraestructura atacada. Después de desactivar las herramientas de seguridad, los afiliados pueden ejecutar el payload del ransomware sin preocuparse de que sea detectada.

En este caso concreto, MS4Killer abusa de un controlador de minifiltro antiguo y vulnerable: probmon.sys, versión 3.0.0.4 (Figura 7), firmado por un certificado ya revocado de ITM System Co.,LTD. El controlador está incrustado en el binario de MS4Killer como un blob cifrado con RC4. Informamos a Microsoft del uso indebido de este controlador por parte de ITW.

Descifrado de cadenas

MS4Killer utiliza el cifrado para ocultar a simple vista las cadenas incrustadas en el binario: en concreto, XORs cadenas de mensajes de registro, la clave RC4 utilizada para descifrar el controlador incrustado, y la lista de nombres de proceso para terminar. La Figura 8 muestra un ejemplo de descifrado de mensajes de registro, donde se llama a la API OpenProcessToken de Windows. Si la función falla, una función definida por el usuario (renombrada a xor_str en la Figura 8) desencripta la cadena XORed y almacena el resultado, [-] OpenProcessToken, en su primer argumento pasado por referencia. La cadena descifrada, junto con la información de error, se escribe en la salida estándar.

Carga de probmon.sys

Como se mencionó anteriormente, el controlador legítimo vulnerable está incrustado como un blob cifrado con RC4 (utilizando la clave FGFOUDa87c21Vg+cxrr71boU6EG+QC1mwViTciNaTUBuW4gQbcKboN9THK4K35sL), que también está cifrado con XOR, en el binario de MS4Killer. Hemos observado dos rutas de archivo diferentes en las que MS4Killer deja caer el controlador vulnerable:

• C:\Windows\System32\drivers\Sysprox.sys (Figura 9)
• C:\Windows\Sysmon64.sys

La carga del driver es consistente con s4killer:

1. habilitando el SeLoadDriverPrivilege necesario para cargar y descargar controladores de dispositivos,
2. creación de un servicio mediante CreateServiceW,
3. crear claves de registro adicionales, necesarias para la carga de filtros, en HKLM\SYSTEM\ControlSet001\services\<service_name>, y
4. cargar un controlador de minifiltro en el sistema mediante FilterLoad.

Hemos observado que MS4Killer utiliza tres nombres de servicio diferentes hasta ahora: Sysprox, Proxmon y Sysmon64.

Lista de procesos ocultos

MS4Killer compara constantemente los procesos en ejecución con una lista oculta de nombres de procesos de software de seguridad, que también están cifrados mediante XOR. Justo después de cargar el controlador, MS4Killer desencripta la lista de nombres de procesos (Figura 10).

Estos nombres de proceso hacen referencia a procesos de múltiples productos de seguridad (véase también el Apéndice: Ejemplo de lista de procesos de terminación de MS4Killer). El fragmento de código de la figura 10 muestra que hay duplicados en los nombres de procesos (como ekrn.exe), algunas de las cadenas se descifran en la misma ubicación (véanse las variables hHandle, Luid y lpMem) y hay un nombre de proceso ficticio: firefox.exe. Además, seguir las referencias cruzadas de las variables de cadena descifradas conduce a una lógica de comparación, en la que sólo se utiliza un subkit de nombres de proceso. La figura 11 muestra un fragmento de código en el que, en ese caso concreto, sólo se comparan los nombres de proceso ERAAgent.exe y ekrn.exe, que pertenecen a productos de ESET, con los procesos en ejecución. Una inspección detallada de varias muestras de MS4Killer muestra que, en cada intrusión, sólo se supervisan los procesos de una solución de seguridad concreta, a pesar de que la lista de procesos incrustada siempre contiene nombres de procesos de varios productos de seguridad.

Observamos indicios que sugieren que las muestras de MS4Killer se compilaron poco antes de los ataques reales y se dirigieron únicamente a la solución de seguridad que protegía el equipo de la víctima.

Conclusión

En este blogpost, hemos proporcionado un análisis de las nuevas herramientas de Rust que hemos llamado MDeployer y MS4Killer, que son utilizadas activamente por el nuevo grupo de ransomware – Embargo. Embargo es un nuevo actor en el espacio del ransomware, con la ambición de elevarse al nivel de las bandas experimentadas. Hemos proporcionado argumentos de por qué creemos que el grupo Embargo ofrece RaaS.

El principal objetivo del kit de herramientas de Embargo es garantizar el éxito del despliegue de el payload del ransomware desactivando la solución de seguridad en la infraestructura de la víctima. Embargo pone mucho empeño en ello, replicando la misma funcionalidad en diferentes fases del ataque (BAT script, MDeployer y MS4Killer) contienen funcionalidades de desactivación de la solución de seguridad). También hemos observado la capacidad de los atacantes para ajustar sus herramientas sobre la marcha, durante una intrusión activa, para una solución de seguridad concreta.

Tanto MDeployer como MS4Killer están escritos en Rust. Lo mismo ocurre con el payload del ransomware, lo que sugiere que Rust es el lenguaje utilizado por los desarrolladores del grupo. Hemos observado el despliegue de dos versiones diferentes de MDeployer durante un incidente. El loader desplegado también contenía errores lógicos que interrumpían la correcta funcionalidad de la herramienta. Basándonos en la forma en que las herramientas son modificadas durante las intrusiones y la cercanía de las marcas de tiempo de compilación a las horas de las intrusiones, asumimos que el atacante que despliega las herramientas tiene la capacidad de modificar rápidamente el código fuente y recompilar sus herramientas durante una intrusión.

IoCs

Archivos

Certificado

Rutas adicionales de archivos MDeployer

• C:WindowsDebug.cache
• C:³’³’³’³’³’³’³’³’.cache
• C:³’³’³’³’³’³’³’³’³’.txt
• C:WindowsDebugStop.exe

Comandos utilizados por MDeployer

• reg delete HKLM\SYSTEM\CurrentControlSet\Control\Safeboot\Network\WinDefend /f
• C:\Windows\System32\cmd.exe /c takeown /R /A /F “C:\ProgramData\[redacted]” /D Y
• C:\Windows\System32\cmd.exe /c takeown /R /A /F “C:\Program Files\[redacted]” /D Y
• sc create irnagentd binpath=”C:\Windows\System32\cmd.exe /c start /B rundll32.exe C:\Windows\Debug\dtest.dll,Open” start=auto
• sc delete irnagentd
• reg add HKLM\SYSTEM\CurrentControlSet\Control\Safeboot\Network\irnagentd /t REG_SZ /d Service /f
• C:WindowsSystem32cmd.exe /c bcdedit /set {default} safeboot Minimal
• C:³³System32\cmd.exe /c bcdedit /deletevalue {por defecto} safeboot
• reg delete HKLM\SYSTEM\CurrentControlSet\Control\Safeboot\Network\WinDefend /f
• C:\Windows\System32\cmd.exe /c ping localhost -n 5 > nul & del C:\Windows\Debug\dtest.dll
• shutdown -r -f -t 00
• C:\Windows\praxisbackup.exe
• C:\Windows\Debug\pay.exe

Técnicas ATT&CK de MITRE

Esta tabla se construyó utilizando la versión 15 del marco MITRE ATT&CK.

Apéndice: Ejemplo de lista de procesos de terminación de MS4Killer (en orden alfabético)