Cómo el grupo ToddyCat intentó ocultarse detrás de un antivirus

Los grupos APT recurren a diferentes técnicas para evadir los mecanismos de seguridad y ocultar sus actividades malisiosas en los sistemas infectados. La mayoría de estas técnicas son reconocidas y detectadas tanto por soluciones EPP como por herramientas EDR de monitoreo y respuesta a amenazas. Por ejemplo, para ocultar su actividad en sistemas Windows, los atacantes pueden utilizar rootkits a nivel de kernel, como los controladores maliciosos. Sin embargo, en los sistemas operativos Windows modernos, los controladores en modo kernel solo se cargan si tienen una firma digital de Microsoft. Los delincuentes evaden este mecanismo de protección utilizando controladores legítimos que tienen la firma requerida, pero que también presentan funciones vulnerables que les permiten realizar acciones maliciosas en el contexto del kernel. Los instrumentos de monitoreo detectan la instalación de estos controladores y verifican la legitimidad de las aplicaciones que los ejecutan. ¿Pero qué pasa si una solución de seguridad ejecuta acciones peligrosas? Parece más fiable y levanta menos sospechas en el monitoreo del sistema.

Esto es por lo que apostaron los atacantes de APT ToddyCat al ejecutar su instrumento malicioso escudándose detrás de una solución de seguridad.

Detección

A principios de 2024, durante la investigación de incidentes relacionados con la actividad del grupo APT ToddyCat, encontramos un archivo sospechoso llamado version.dll en el directorio temporal de varios dispositivos.

Es una biblioteca DLL de 64 bits escrita en C++ y se trata de un instrumento complejo llamado TCESB, que antes no estaba presente en los ataques de ToddyCat. Está diseñado para ejecutar en secreto una carga útil, evadiendo las medidas de protección y monitoreo del dispositivo.

Los productos de Kaspersky detectan este instrumento como Trojan.Win64.ToddyCat.a y Trojan.Win64.ToddyCat.b.

Cómo se carga el instrumento

Uso de DLL como proxy (DLL Proxying)

El análisis estático de la biblioteca DLL mostró que todas sus funciones exportadas importan funciones con los mismos nombres del archivo del sistema version.dll (Version Checking and File Installation Libraries).

Lista de funciones exportadas por el instrumento TCESB

Esto indica que los atacantes hacen uso de DLL como proxy (Hijack Execution Flow, T1574) para ejecutar código malicioso. Una DLL maliciosa exporta todas las funciones de una DLL legítima, pero en lugar de implementarlas, redirige las llamadas de estas funciones a la DLL original. De este modo, la aplicación que carga la biblioteca maliciosa seguirá funcionando sin errores, mientras que el código malicioso se ejecutará en segundo plano dentro del mismo proceso.

Esquema de ejecución de la técnica de uso de DLL como proxy

Sin embargo, esto no es suficiente para ejecutar el malware. Para que un archivo DLL malicioso pueda tomar el control, la aplicación que lo cargue debe contener código malicioso. El código busca imágenes de bibliotecas dinámicas en carpetas donde no deberían estar. Si una de estas carpetas contiene una biblioteca maliciosa, la aplicación vulnerable la cargará en lugar de la legítima. Microsoft ha ofrecido recomendaciones para prevenir la carga maliciosa de DLL.

Vulnerabilidad CVE-2024-11859 en el escáner para línea de comandos de ESET

No logramos encontrar de inmediato el archivo que carga el instrumento TCESB. Estudiamos los directorios del sistema en los dispositivos donde se encontraron bibliotecas DLL maliciosas. En uno de ellos, en la misma carpeta que TCESB, se encontraba un archivo ejecutable sin extensión llamado ecls. Creemos que el operador cometió un error en el nombre del archivo al transferirlo al dispositivo y transfirió dos copias. Después de la actividad maliciosa, el archivo con la extensión correcta fue eliminado, pero el segundo permaneció en el sistema. Este archivo resultó ser un componente de la solución EPP de ESET: un escáner que se ejecuta desde la línea de comandos (ESET Command line scanner). El análisis dinámico mostró que carga de manera insegura la biblioteca del sistema version.dll: primero verifica la presencia del archivo en el directorio actual y luego lo busca en los directorios del sistema. Esto puede llevar a que se cargue una biblioteca DLL maliciosa, abriendo una vulnerabilidad. Elaboramos un informe describiendo la falla en detalle y lo enviamos a la empresa ESET como parte del procedimiento de divulgación coordinada de vulnerabilidades (Coordinated Vulnerability Disclosure). ESET registró la vulnerabilidad CVE-2024-11859 y el 21 de enero 2025 lanzó una actualización para el archivo ecls, que soluciona este problema. El 4 de abril, la información sobre esta vulnerabilidad fue publicada en los informes de seguridad de ESET.

Para analizar el instrumento TCESB, lo ejecutamos en un entorno virtual. En el espacio de direcciones del proceso ESET Command line scanner se puede ver dos archivos version.dll. Uno de ellos es una biblioteca del sistema y el otro es una DLL del instrumento TCESB.

Bibliotecas maliciosas y legítimas en la memoria del proceso ecls.exe

Funcionalidad principal

Para determinar las funciones principales del instrumento malicioso, estudiamos las cadenas de texto de su DLL.

Fragmento de la lista de cadenas de texto que contiene el instrumento TCESB

Las líneas no están ofuscadas. Notamos que la mayoría pertenece al instrumento malicioso de código abierto EDRSandBlast, diseñado para burlar las soluciones de seguridad. Los productos Kaspersky lo detectan con el veredicto HEUR:HackTool.Win64.EDRSandblast.a. Los atacantes de la APT ToddyCat crearon la DLL TCESB, modificando el código original para darle más funciones al malware. El instrumento resultante es capaz, entre otras cosas, de modificar las estructuras del kernel del sistema operativo para desactivar las notificaciones del sistema cuando, por ejemplo, se creen o carguen procesos.

Búsqueda de direcciones en la memoria del kernel

Para encontrar las estructuras que se necesitan para desactivar las notificaciones en la memoria del kernel, el instrumento TCESB determina la versión del kernel de Windows en el contexto en el que fue ejecutado. Para hacerlo, utiliza la función GetNtoskrnlVersion().

Función para obtener la versión del kernel de Windows, implementada en TCESB

Luego, para obtener información sobre los desplazamientos en la memoria de las estructuras correspondientes a la versión del kernel del sistema operativo, TCESB utiliza uno de dos orígenes de datos: un archivo CSV o un archivo PDB.

Primero, el instrumento verifica el archivo CSV que se encuentra en la sección de recursos propios. En él se almacenan tablas de información sobre varias versiones populares del kernel y sus desplazamientos.

TCESB busca línea por línea una coincidencia con la versión vigente del kernel de Windows obtenida anteriormente.

Fragmento de la función para obtener y leer un archivo CSV de los recursos del instrumento TCESB

Analizamos el archivo CSV en el repositorio de EDRSandBlast y el historial de sus cambios. El contenido del CSV de TCESB es idéntico a los datos del CSV de la versión EDRSandBlast del 13 de agosto de 2022, mientras que en el commit del malware original del 6 de octubre de 2023 tiene agregadas cadenas que no están presentes en el recurso de TCESB. Esto indica el período de tiempo en que los creadores del instrumento TCESB utilizaron el código EDRSandBlast.

Si en el archivo CSV faltan datos sobre las estructuras de la versión necesaria del kernel, TCESB lee sus direcciones desde el archivo PDB. Para obtenerlo, el malware accede al archivo C:\Windows\System32\ntoskrnl.exe, que contiene información sobre la versión del archivo del kernel, e inserta los datos en la siguiente plantilla, formando una URL:

Esta es la dirección del servidor que contiene información de depuración de Microsoft, al que TCESB envía una solicitud GET para descargar el archivo PDB. El archivo recibido se guarda en el directorio de TCESB, desde donde se extraen los datos sobre los desplazamientos de las estructuras necesarias en la memoria del kernel.

El controlador vulnerable

TCESB aplica la técnica BYOVD (Bring Your Own Vulnerable Driver, Exploitation for Defense Evasion, T1211) para modificar las estructuras del kernel que almacenan las retrollamadas que se usan para notificar a las aplicaciones sobre eventos del sistema. Para ello, instala en el sistema un controlador vulnerable a través de la interfaz del Administrador de dispositivos (Device Manager), utilizando un archivo INF con la información necesaria para la instalación.

Fragmento de código descompilado que instala el controlador TCESB

TCESB utiliza el controlador de un programa de Dell DBUtilDrv2.sys, que contiene la vulnerabilidad CVE-2021-36276. Está diseñado para actualizar los controladores, BIOS y firmware del PC.

Lanzamiento de la carga útil

Después de instalar el controlador vulnerable en el sistema, TCESB inicia un ciclo que cada dos segundos busca un archivo de carga útil con un nombre específico en el directorio actual; esto es porque al momento de iniciar la herramienta, la carga útil podría no estar presente. Es probable que esto permita al operador asegurarse de que el instrumento funcione sin errores antes de transferir el archivo de carga útil, así lo hace sin riesgo de ser detectado. Tan pronto como el archivo aparece, se lo remite a la función de descifrado.

Fragmento de código descompilado de TCESB

TCESB crea su propio archivo de registro, donde detalla todas las etapas de ejecución.

Ejemplo del contenido de un archivo de registro

Hemos estudiado dos muestras del instrumento TCESB. No pudimos obtener los archivos de carga útil, pero la investigación muestra que tienen diferentes nombres ( kesp y ecore) y ninguno tiene una extensión.

Al analizar el código de la herramienta, descubrimos que los datos del archivo de carga útil están cifrados con AES-128.

Fragmento de código para definir el algoritmo de cifrado

La clave de descifrado se encuentra en los primeros 32 bytes del archivo de carga útil, al que sigue el bloque de datos cifrado. A continuación mostramos el fragmento de código en el que se lee la clave:

Fragmento de código usado para leer una clave desde un archivo de carga útil

La clave obtenida permite descifrar el bloque de datos:

Fragmento de código para leer y descifrar el archivo de carga útil

Los datos leídos se colocan en la memoria y se ejecutan.

Conclusiones

Descubrimos un instrumento complejo que el grupo APT ToddyCat intentó utilizar para ocultar sus acciones en sistemas comprometidos. El instrumento utiliza una cadena de vulnerabilidades, así como una versión antigua de un conocido malware de código abierto, que fue modificado por los atacantes para ampliar su funcionalidad.

Esquema de funcionamiento del instrumento

Para detectar la actividad de estas herramientas, se recomienda vigilar los eventos de instalación de controladores con vulnerabilidades conocidas. Se pueden encontrar listas de tales controladores, por ejemplo, en el sitio web del proyecto loldrivers. Además, es importante monitorear los eventos de carga de símbolos de depuración del kernel de Windows en aquellos dispositivos donde no se espera realizar la depuración del kernel del sistema operativo. También recomendamos verificar la presencia de una firma digital en todos los archivos de bibliotecas del sistema que se descarguen, utilizando las herramientas del sistema operativo.

Indicadores de compromiso

Hashes de archivos maliciosos

D38E3830C8BA3A00794EF3077942AD96       version.dll 008F506013456EA5151DF779D3E3FF0F       version.dll

Archivo legítimos para usar una DLL como proxy

8795271F02B30980EBD9950FCC141304       Escaner de ESET para línea de comandos

Archivos legítimos para BYOVD

B87944DCC444E4C6CE9BB9FB8A9C0DEF       dbutildrv2.INF DE39EE41D03C97E37849AF90E408ABBE       DBUtilDrv2.cat DACB62578B3EA191EA37486D15F4F83C       dbutildrv2.sys