Detección de DLL Hijacking mediante aprendizaje automático: casos reales

Introducción

Hace poco, nuestros colegas del Centro de Especialización en IA desarrollaron un modelo de aprendizaje automático que detecta ataques DLL Hijacking (suplantación de DLL). Más adelante, implementamos este modelo en el sistema SIEM de Kaspersky Unified Monitoring and Analysis Platform (Kaspersky SIEM). En otro artículo, nuestros colegas detallaron cómo se creó este modelo y qué logros se alcanzaron en condiciones de laboratorio. Aquí nos centraremos en cómo funciona Kaspersky SIEM y qué pasos preparatorios precedieron a su lanzamiento, y relataremos algunos incidentes reales que ya se han detectado con su ayuda.

Cómo funciona el modelo de Kaspersky SIEM

El trabajo del modelo, en términos generales, consiste en la verificación paso a paso de todas las bibliotecas DLL cargadas por los procesos en el sistema, con posterior validación en la nube de Kaspersky Security Network (KSN). Este enfoque permite combinar información sobre los atributos locales (ruta, nombre de proceso, hashes de archivos) con una base global de conocimiento e indicadores de comportamiento, lo que conduce a una mejora sustancial en la calidad de la detección y reduce la probabilidad de falsos positivos.

El modelo puede funcionar en uno de dos modos: el correlacionador o el colector. El correlacionador es un componente de SIEM que realiza el análisis y la correlación de eventos basándose en reglas o algoritmos predefinidos. Si la detección está configurada en el correlacionador, el modelo verifica los eventos en los que ya se ha activado alguna regla. Esto reduce el volumen de solicitudes que se envían a KSN y aumenta la velocidad de respuesta del modelo.

La estructura es la siguiente:

El colector es un componente de software o hardware de SIEM que garantiza la recopilación, normalización y entrega de eventos provenientes de diversos orígenes al núcleo de la plataforma. Si la detección está configurada en el colector, el modelo procesa todos los eventos de carga de bibliotecas generados por diferentes procesos, si cumplen con las siguientes condiciones:

• Se conoce la ruta al archivo del proceso.
• Se conoce la ruta a la biblioteca.
• Están presentes hashes del archivo y de la biblioteca.

Este método consume más recursos y la respuesta del modelo tarda más que en el correlacionador. Sin embargo, puede ser útil en la búsqueda retrospectiva de amenazas, ya que permite verificar todos los eventos registrados por Kaspersky SIEM. El esquema de funcionamiento del modelo en el colector se ve de la siguiente manera:

Es importante señalar que el modelo no se limita a una evaluación binaria “malicioso/no malicioso”, sino que ordena sus respuestas según el grado de certeza. Esto permite utilizarla como una herramienta flexible en la práctica SOC. Ejemplos de posibles veredictos:

• 0: los datos están siendo procesados
• 1: amenaza no confirmada. Esto significa que, en este momento, el modelo no considera que la biblioteca sea maliciosa.
• 2: la biblioteca genera sospechas
• 3: amenaza confirmada

La regla para detectar el DLL Hijacking en la plataforma Kaspersky SIEM luce así:

La integración del modelo en el correlacionador de Kaspersky SIEM automatiza el proceso de búsqueda de ataques del tipo DLL Hijacking y hace posible su detección a gran escala sin necesidad de que medie el análisis manual de los cientos o miles de bibliotecas cargadas. Además, en combinación con las reglas de correlación y las fuentes de telemetría, el modelo se puede utilizar no solo como un módulo independiente, sino como parte de una protección integral contra ataques a la infraestructura.

Incidentes identificados durante la implementación piloto del modelo en el servicio MDR

Antes de publicarse, el modelo dentro de la plataforma KUMA se puso a prueba en el servicio MDR, donde se entrenó para identificar ataques utilizando grandes volúmenes de datos provenientes de nuestra telemetría. Esta etapa era necesaria para asegurar que la detección funcione no solo en condiciones de laboratorio, sino también en la infraestructura real de los clientes.

Durante la fase piloto, verificamos la resistencia del modelo a las falsas alarmas y su capacidad para clasificar correctamente el comportamiento incluso en escenarios atípicos de carga de DLL. Como resultado, se identificaron varios incidentes reales en los que los atacantes utilizaron un tipo de DLL Hijacking (técnica DLL Sideloading), para obtener persistencia y ejecutar su código en el sistema.

Analicemos con más detalle tres de los más interesantes.

Incidente 1: ToddyCat intenta ejecutar Cobalt Strike haciéndose pasar por una biblioteca del sistema

En uno de los incidentes, los atacantes lograron explotar el servicio SharePoint, que utiliza IIS como servidor web, mediante la vulnerabilidad CVE-2021-27076:

Después de la explotación, el proceso IIS creó archivos que más adelante se utilizaron para ejecutar código malicioso mediante la técnica de carga lateral de DLL (T1574,401 Hijack Execution Flow: DLL).

SystemSettings.dll es el nombre de la biblioteca asociada con la aplicación Configuración de Windows (SystemSettings.exe). La biblioteca original contiene el código y los datos que la aplicación utiliza para administrar y ajustar varios parámetros del sistema. Sin embargo, la biblioteca creada por los atacantes tiene una funcionalidad maliciosa y solo aparenta ser del sistema.

Más tarde, para afianzarse en el sistema y lanzar el ataque de carga lateral de DLL, se creó una tarea en el programador que se hacía pasar por una actualización del navegador Edge. Su función es ejecutar el archivo SystemSettings.exe, ubicado junto a la biblioteca maliciosa:

La tarea debe realizarse a diario.

Al iniciar el proceso SystemSettings.exe, se carga una DLL maliciosa. En el momento de la carga, los datos sobre el proceso y la biblioteca se enviaron a nuestro modelo para que los analizara e identificara un posible ataque.

Ejemplo del evento de carga de SystemSettings.dll, evaluado por el módulo DLL Hijacking de Kaspersky SIEM

El resultado obtenido ayudó a nuestros analistas a detectar la DLL sospechosa y analizarla en detalle. Se descubrió que esta biblioteca es un implante de Cobalt Strike. Al cargarla, el proceso SystemSettings.exe intentaba conectarse con el centro de comando de los atacantes:

Después de establecer la conexión, los atacantes comenzaron a explorar el host con el fin de obtener toda la información posible para llevar a cabo el ataque.

Basándonos en las TTP de los atacantes, como la carga de Cobalt Strike en forma de DLL, el uso de la técnica DLL Sideloading (1, 2) y la explotación de SharePoint, podemos decir con un alto grado de confianza que detrás del ataque estaba el grupo APT ToddyCat. Gracias a la rápida respuesta de nuestro modelo, pudimos reaccionar a tiempo y bloquear esta actividad, impidiendo que los delincuentes causaran daño a la organización.

Incidente 2: infostealer disfrazado de administrador de políticas

Otro ejemplo que el modelo detectó después de conectar al cliente al monitoreo de MDR: un archivo del sistema legítimo, ubicado en ubicado en la carpeta de la aplicación, intentó cargar una biblioteca sospechosa que se encontraba junto a él.

El archivo SettingSyncHost.exe es un proceso de host del sistema que sirve para sincronizar configuraciones entre diferentes dispositivos de un mismo usuario. Por lo general, sus versiones para sistemas de 32 y 64 bits se encuentran en las carpetas C:\Windows\System32\ y C:\Windows\SysWOW64\, respectivamente. En el incidente, la ubicación del archivo era diferente a la habitual.

Ejemplo de evento de carga de policymanager.dll, evaluado por el módulo DLL Hijacking de Kaspersky SIEM

El análisis del archivo de la biblioteca que cargó este proceso mostró que es un programa malicioso diseñado para robar información de los navegadores.

Gráfico del funcionamiento de policymanager.dll en el entorno aislado

El archivo accede de forma directa a los archivos de los navegadores que contienen datos de los usuarios.

El archivo de la biblioteca está en la lista de archivos que se utilizan para implementar la técnica de DLL Hijacking, publicada en el proyecto HijackLibs. El proyecto contiene una lista de procesos y bibliotecas comunes que se utilizan en ataques del tipo DLL Hijacking, que se puede emplear para detectar ataques de este tipo.

Incidente 3: cargador malicioso disfrazado de una solución de seguridad

Otro incidente, detectado gracias a nuestro modelo, ocurrió cuando el usuario conectó una unidad USB extraíble:

Ejemplo de un evento de carga de la biblioteca wsc.dll desde una unidad USB, evaluado por el módulo DLL Hijacking de Kaspersky SIEM

En el directorio del disco conectado había carpetas ocultas y accesos directos con iconos que se suelen utilizar para representar carpetas. Dado que, por defecto, la extensión de los archivos en el disco no se muestra, el usuario podría haber confundido el acceso directo con una carpeta y ejecutarlo. A su vez, el acceso directo abría la carpeta oculta correspondiente y ejecutaba el archivo ejecutable con el siguiente comando:

El archivo CEFHelper.exe es un archivo ejecutable legítimo de Avast Antivirus, que mediante el DLL Sideloading carga la biblioteca wsc.dll, que es un cargador malicioso:

Fragmento del código del archivo malicioso

El cargador abre un archivo llamado AvastAuth.dat, que contiene una puerta trasera cifrada. La biblioteca lee los datos del archivo en la memoria, los descifra y los ejecuta. Después, la puerta trasera intenta conectarse con el centro de comando remoto.

El archivo de la biblioteca que contiene el cargador malicioso está en la lista de bibliotecas conocidas que se utilizan para el DLL Sideloading, presentada en el sitio del proyecto HijackLibs.

Conclusión

Como resultado de la incorporación del modelo en el producto, se adquirió la capacidad de detectar de manera temprana y precisa los intentos de DLL Hijacking, que antes podían pasar inadvertidos. Ya en la fase piloto, el modelo demostró su eficacia al detectar varios incidentes en los que se aplicaba esta técnica. En el futuro, su precisión aumentará gracias a la acumulación de datos y a la actualización de los algoritmos en KSN, lo que convierte este mecanismo en un elemento fiable de la protección proactiva de los sistemas corporativos.

IoC

Archivos legítimos utilizados para el DLL Hijacking:
E0E092D4EFC15F25FD9C0923C52C33D6 carga SystemSettings.dll
09CD396C8F4B4989A83ED7A1F33F5503 carga policymanager.dll
A72036F635CECF0DCB1E9C6F49A8FA5B carga wsc.dll

Archivos maliciosos
EA2882B05F8C11A285426F90859F23C6   SystemSettings.dll
E83F331BD1EC115524EBFF7043795BBE   policymanager.dll
831252E7FA9BD6FA174715647EBCE516   wsc.dll

Path
C:\ProgramData\SystemSettings.exe
C:\ProgramData\SystemSettings.dll
C:\Program Files\Chiniks\SettingSyncHost.exe
C:\Program Files\Chiniks\policymanager.dll
D:\RECYCLER.BIN\1\CEFHelper.exe
D:\RECYCLER.BIN\1\wsc.dll