Cómo detectar DLLs sospechosas en Windows y frenar ataques

Inicio » Seguridad » Cómo detectar DLLs sospechosas en Windows y frenar ataques

En los últimos años, las DLL se han convertido en uno de los vectores favoritos de los atacantes en Windows. No solo permiten ejecutarse dentro de procesos legítimos, también ayudan a camuflar el malware para esquivar muchas soluciones de seguridad tradicionales. Si administras sistemas, gestionas un SOC o simplemente te preocupa la seguridad de tus equipos, entender cómo detectar DLLs sospechosas ya no es opcional: es imprescindible.

Al mismo tiempo, el ecosistema defensivo ha dado un salto enorme. Modelos de inteligencia artificial como los de Kaspersky (para DLL Hijacking) o DeepDLL de Check Point han elevado mucho el listón en detección basada en comportamiento y contexto, muy por encima de la simple firma o heurística clásica. En este artículo vamos a desgranar, con calma pero sin rodeos, qué son las DLL maliciosas, cómo se usan en ataques reales, qué técnicas emplean los atacantes y cómo puedes combinar buenas prácticas, herramientas avanzadas y análisis manual para detectarlas y frenarlas.

Qué es una DLL y por qué es tan atractiva para el malware

Una DLL (Dynamic Link Library) es, básicamente, un archivo que contiene código y datos reutilizables por múltiples procesos en Windows. El sistema operativo y casi cualquier programa de escritorio o servidor dependen de decenas o cientos de DLL para funciones tan variadas como gestionar memoria, mostrar ventanas, acceder a disco o comunicarse por red.

Esta arquitectura es muy cómoda para los desarrolladores, pero también supone que inyectar código malicioso en una DLL o sustituirla por una versión manipulada permite al atacante «subirse al carro» de un proceso legítimo. El resultado es que el malware se ejecuta con los mismos privilegios y en el mismo contexto que la aplicación víctima, lo que complica mucho su identificación.

Existen DLLs especialmente sensibles desde el punto de vista del análisis de malware. Algunas de las más relevantes son KERNEL32.dll, ADVAPI32.dll, USER32.dll, GDI32.dll, NTDLL.dll, WSock32.dll, WS2_32.dll o WININET.dll. Su presencia no es sospechosa por sí misma, pero en un archivo malicioso suelen ser un chivato de sus capacidades: acceso a archivos, manipulación de procesos, red, ofuscación, etc.

Muchas amenazas modernas no se presentan como un EXE clásico, sino directamente como una DLL maliciosa que se registra o carga de forma encubierta. Esto les permite esquivar controles básicos que solo vigilan ejecutables directos y no analizan con profundidad el comportamiento de las bibliotecas.

Principales técnicas: DLL Hijacking, Side-Loading e Injection

Cuando se habla de detectar DLLs sospechosas en Windows, casi siempre acabamos en tres técnicas clave: DLL Hijacking, DLL Side-Loading y DLL Injection. Todas se apoyan en el mismo principio: aprovechar la forma en que Windows y las aplicaciones resuelven y cargan bibliotecas dinámicas.

En el caso del DLL Hijacking, el atacante coloca una DLL maliciosa con el mismo nombre que una legítima en un directorio que se evalúa antes en el orden de búsqueda de Windows. Si la aplicación llama a LoadLibrary sin especificar la ruta completa, el sistema acaba cargando la copia manipulada. Esta técnica también se conoce como precarga de DLL o plantación binaria.

El DLL Side-Loading es una variante muy parecida: el atacante sitúa su DLL maliciosa en el directorio de la aplicación o en alguna ruta en la que el programa confíe de forma implícita. El ejecutable, al funcionar de manera normal, termina cargando la biblioteca maliciosa como si fuera parte de su propio conjunto de dependencias.

Por su parte, la DLL Injection es más directa: se inyecta una DLL en un proceso que ya está en ejecución, usando técnicas como CreateRemoteThread, SetWindowsHookEx o similares. Esto sitúa el código malicioso dentro del espacio de memoria de una aplicación legítima, algo especialmente usado para keyloggers, robo de credenciales, espionaje o instalación de backdoors persistentes.

Todos estos enfoques comparten un problema común para el defensor: desde el punto de vista de muchos antivirus clásicos, es un proceso “de confianza” cargando una DLL aparentemente normal. Por eso el foco se ha desplazado del archivo aislado al contexto y al comportamiento global.

Cómo funciona el orden de búsqueda de DLL en Windows

Para entender de verdad por qué estas técnicas funcionan, hace falta repasar cómo decide Windows qué DLL cargar cuando una aplicación llama a LoadLibrary sin indicar una ruta absoluta. En esos casos, el sistema recorre una lista de directorios en un orden predefinido, que típicamente incluye:

• Directorio desde el que se cargó la aplicación.
• Directorio del sistema (por ejemplo, C:\Windows\System32).
• Directorio del sistema de 16 bits.
• Directorio de Windows (por ejemplo, C:\Windows\).
• Directorio actual del proceso.
• Directorios definidos en la variable de entorno PATH.

Si un atacante logra controlar uno de esos directorios, puede colocar allí una DLL falsa con el mismo nombre que la original. Si el sistema no encuentra antes la copia legítima, acabará ejecutando la maliciosa. Si la aplicación corre con privilegios elevados (por ejemplo, como administrador o SYSTEM), el ataque puede derivar incluso en una escalada de privilegios local.

Un escenario típico sería una aplicación que busca una DLL en el directorio actual del usuario. Si el directorio está comprometido y contiene una copia maliciosa, esa DLL se cargará con los privilegios del usuario que ejecuta la aplicación. A partir de ahí, el malware tiene vía libre para ejecutar su lógica en el contexto del proceso legítimo.

Microsoft proporciona diversas API y mecanismos para mitigar esto: SetDllDirectory, SetDefaultDllDirectories, AddDllDirectory, las banderas LOAD_LIBRARY_SEARCH de LoadLibraryEx o el modo de búsqueda segura de DLL (SafeDllSearchMode). Todas ellas permiten controlar o endurecer el orden de búsqueda, mover el directorio actual al final, o incluso eliminarlo por completo de la ruta estándar.

Otra función problemática es SearchPath, que se usa a veces para localizar una DLL antes de llamar a LoadLibrary. Si no se activa el modo seguro para SearchPath (SetSearchPathMode con BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE), puede buscar primero en el directorio actual, lo que reabre la puerta al secuestro de DLL aunque el resto del proceso esté bien configurado.

Modelos de IA para detectar DLLs sospechosas: Kaspersky SIEM y DeepDLL

Las soluciones modernas han dado un salto cualitativo apoyándose en el análisis masivo de telemetría y en modelos de machine learning. En el caso de Kaspersky, sus equipos de investigación de IA han desarrollado un modelo específico para detectar DLL Hijacking que ya se integra en su plataforma SIEM, Kaspersky Unified Monitoring and Analysis Platform (KUMA / Kaspersky SIEM).

Este modelo no se limita a ver si una DLL tiene “buena” o “mala” reputación. Analiza información indirecta sobre la biblioteca y el proceso que la carga: rutas de los archivos, si están en ubicaciones estándar, cambios de nombre extraños, tamaño y estructura poco habituales, integridad o ausencia de firma digital, hashes, etc. A esto se suma la validación en la nube de Kaspersky Security Network (KSN), que aporta contexto global y reputación.

El entrenamiento del modelo se basó en registros de carga de DLL recopilados tanto de sistemas internos de análisis automático como de telemetría anónima de KSN, enriquecidos con sus bases de datos de reputación. Tras múltiples iteraciones de ajuste de etiquetas y selección de características, la precisión en la detección de DLL Hijacking aumentó de forma notable, reduciendo falsos positivos y mejorando el tiempo de respuesta.

Por su parte, Check Point ha desarrollado DeepDLL, un motor de IA integrado con ThreatCloud AI que se centra en localizar malware oculto en DLL, haciendo hincapié en DLL Hijacking, Side-Loading e Injection. DeepDLL examina no solo el contenido del archivo, sino también su contexto de llegada: correo electrónico, instaladores MSI, ejecutables descargados o archivos comprimidos.

DeepDLL analiza metadatos, estructura compilada y cadenas de ataque asociadas a cada DLL, alcanzando tasas de detección cercanas al 99,7 % con un volumen muy bajo de falsos positivos. Esto permite parar amenazas incluso cuando la DLL no tiene extensión .dll o intenta camuflarse dentro de otros contenedores como paquetes MSI o archivos firmados.

Funcionamiento del modelo de Kaspersky SIEM: correlacionador y colector

La integración del modelo de detección de DLL Hijacking en Kaspersky SIEM se apoya en dos piezas clave: el correlacionador de eventos y el colector. Ambos pueden utilizar el modelo, pero con enfoques y costes de recursos distintos.

Cuando se configura en el correlacionador, el modelo solo examina los eventos que ya han activado alguna regla previa. De esta forma, se reduce el volumen de solicitudes a la nube KSN y se acelera la respuesta, ya que se trabaja sobre un subconjunto de eventos considerados de interés. Es ideal para detección en tiempo casi real y priorización de alertas en un SOC.

En cambio, al configurarlo sobre el colector, el modelo procesa todos los eventos de carga de bibliotecas que cumplan ciertas condiciones: que se conozca la ruta del proceso, la ruta de la dll y que haya hashes disponibles tanto del ejecutable como de la propia biblioteca. Esto consume más recursos y la respuesta puede ser algo más lenta, pero es muy útil para búsqueda retrospectiva y cazas de amenazas a gran escala.

El modelo no se queda en un simple sí/no. Emite veredictos graduados, lo que permite ajustar playbooks y respuestas en función del nivel de sospecha. Por ejemplo, puede producir valores como 0 (en análisis), 1 (no malicioso por ahora), 2 (sospechoso) y 3 (amenaza confirmada). En Kaspersky SIEM, una regla típica para disparar alertas podría ser:

N.KL_AI_DLLHijackingCheckResult > 1

Gracias a este enfoque, se puede automatizar la búsqueda de ataques de DLL Hijacking sin bucear manualmente entre cientos o miles de eventos de carga de DLL. Además, combinando este modelo con otras reglas de correlación y diversas fuentes de telemetría, se integra dentro de una defensa por capas contra ataques dirigidos y amenazas avanzadas.

Casos reales: DLL maliciosas en ataques dirigidos

Durante la fase piloto del modelo de Kaspersky, se aprovechó el servicio de MDR para entrenarlo y validarlo en entornos de clientes reales. El objetivo era comprobar que la precisión obtenida en laboratorio se mantenía en infraestructuras complejas, con software poco habitual, configuraciones atípicas y patrones de uso muy diferentes entre organizaciones.

En este contexto se identificaron varios incidentes reales en los que los atacantes emplearon DLL Hijacking y sobre todo Side-Loading para lograr persistencia y ejecución de código. Uno de los casos más llamativos estuvo vinculado al grupo APT ToddyCat, muy asociado al uso de Cobalt Strike como implante.

En ese incidente, los atacantes explotaron una vulnerabilidad en SharePoint (CVE-2021-27076), a través de IIS, para que el proceso w3wp.exe terminase creando un binario SystemSettings.exe y una DLL asociada, SystemSettings.dll, en C:\ProgramData\. La DLL original forma parte de la aplicación de Configuración de Windows, pero la copia generada por los atacantes contenía código de Cobalt Strike.

Después, se programó una tarea en el programador de tareas de Windows simulando ser una actualización de Edge, que ejecutaba diariamente C:\ProgramData\SystemSettings.exe. En el momento en que el ejecutable arrancaba, cargaba la DLL maliciosa mediante side-loading, que a su vez intentaba conectar con el servidor de mando y control mediante consultas DNS a dominios como connect-microsoftcom.

Gracias a la puntuación elevada generada por el modelo de DLL Hijacking, el equipo de analistas pudo centrarse rápidamente en esa biblioteca e identificarla como un implante de Cobalt Strike. A partir de ahí, se rastrearon las TTP del ataque completo: enumeración de host, consultas de red, exploración de cuentas y grupos, etc., lo que permitió atribuir la actividad a ToddyCat con un alto grado de confianza y frenar la intrusión.

Otro incidente interesante fue el de una DLL llamada policymanager.dll, cargada por un binario SettingSyncHost.exe ubicado en C:\Program Files\Chiniks\, en lugar de las rutas habituales del sistema (System32 o SysWOW64). El modelo detectó la combinación de ruta poco común, archivo del sistema en ubicación extraña y biblioteca sospechosa.

El análisis posterior mostró que policymanager.dll era en realidad un infostealer centrado en los navegadores, que accedía directamente a ficheros como Local State en el perfil de Google Chrome para extraer datos de usuario. Además, la DLL figuraba en el proyecto HijackLibs, un repositorio que recopila procesos y bibliotecas frecuentemente utilizados en ataques de DLL Hijacking.

En un tercer caso, el modelo saltó al detectar la carga de wsc.dll desde una unidad USB extraíble. El dispositivo contenía carpetas ocultas y accesos directos disimulados como directorios; al hacer doble clic, el usuario lanzaba un acceso directo que abría la carpeta oculta y ejecutaba CEFHelper.exe con parámetros específicos.

CEFHelper.exe resultó ser un binario legítimo de Avast Antivirus, pero se utilizaba para cargar mediante side-loading la DLL maliciosa wsc.dll. Esta actuaba como loader, descifrando una backdoor almacenada en AvastAuth.dat y ejecutándola en memoria, antes de intentar contactar con su servidor de mando y control remoto. De nuevo, HijackLibs listaba wsc.dll entre las bibliotecas más usadas para este tipo de ataque.

Análisis estático de DLL sospechosas: herramientas y trucos

Más allá de los modelos de IA y los EDR, sigue siendo fundamental saber hacer análisis estático de DLL cuando sospechas que algo no cuadra. El objetivo es obtener la máxima información posible del archivo sin ejecutarlo, para valorar su peligrosidad o decidir si merece un análisis dinámico más profundo.

En primer lugar, conviene identificar qué funciones importa y exporta la DLL, qué otras bibliotecas carga y qué dependencias tiene. Herramientas como PEiD, Dependency Walker o PEview siguen siendo clásicas para esto, a pesar de su antigüedad. PEiD, por ejemplo, ayuda a detectar si el archivo está empaquetado o protegido con packers conocidos.

Dependency Walker permite ver la lista de DLL de las que depende el archivo y las funciones concretas que invoca. Si te encuentras con llamadas a WriteFile, CreateProcess, WinExec, InternetOpenUrl, send, recv o similares, puedes empezar a trazar qué tipo de acciones puede realizar la biblioteca (escritura de archivos, ejecución de procesos, comunicaciones de red, etc.).

Con PEview puedes revisar con detalle la estructura PE: cabecera, secciones, tablas de importación y exportación, cadenas, recursos, timestamp, etc. El timestamp puede aportar pistas: fechas incoherentes (como 1970, años futuros o valores idénticos entre muchas muestras) suelen ser un síntoma de ofuscación o compilaciones automatizadas de malware.

Analizar las cadenas (strings) incrustadas también es muy útil. Buscando URLs, rutas, nombres de procesos, órdenes de PowerShell, comandos de sistema o mensajes de error sospechosos puedes intuir la funcionalidad de la DLL incluso sin desensamblar todo el código.

Análisis dinámico y monitorización del sistema

Una vez que el análisis estático te da indicios de peligro, o si necesitas entender el comportamiento completo, entra en juego el análisis dinámico: ejecutar la DLL en un entorno controlado (sandbox, VM aislada) y monitorizar todo lo que hace.

Herramientas como Process Monitor (Procmon) de Sysinternals son especialmente útiles para ver operaciones de carga de DLL, acceso a archivos, registros y red. Para centrarse en posibles vulnerabilidades o comportamientos anómalos, Microsoft recomienda configurar filtros en Procmon que incluyan operaciones como CreateFile y LoadImage, y rutas que contengan extensiones .dll, .exe, .sys, .drv, .cpl, .ocx o .scr.

A la vez, se deben excluir del visor procesos internos como procmon.exe o System, resultados SUCCESS masivos y ciertas operaciones del kernel (IRP_MJ_, FASTIO_) que solo añaden ruido. Así, el investigador puede ver con claridad qué DLL intenta cargar la aplicación, desde qué directorios y con qué resultado.

Un truco habitual es iniciar la aplicación con el directorio actual establecido en una carpeta específica y observar si realiza llamadas a LoadLibrary que terminan buscando DLL en ese directorio. Si es así, puede tratarse de una vulnerabilidad susceptible de ser explotada mediante precarga de DLL.

Complementando Procmon con un EDR moderno, captura de tráfico de red y registro de eventos de seguridad, es posible reconstruir de manera bastante precisa el flujo de ejecución: qué proceso lanza qué DLL, qué comandos se abren, qué conexiones se inician y cómo evoluciona la amenaza dentro del sistema.

Buenas prácticas para desarrolladores: endurecer la carga de DLL

Una parte importante del problema está en el propio software legítimo. Muchos ataques de DLL Hijacking y Side-Loading se basan en aplicaciones que cargan DLL de forma insegura, confiando en el orden de búsqueda por defecto o en directorios que el usuario puede manipular.

Para reducir la superficie de ataque, los desarrolladores deberían, siempre que sea posible, especificar rutas absolutas al usar LoadLibrary, LoadLibraryEx, CreateProcess o ShellExecute. De esta manera, el sistema no necesita recorrer múltiples directorios y se minimiza el riesgo de encontrarse con una DLL plantada por un atacante.

También es recomendable utilizar las banderas LOAD_LIBRARY_SEARCH en LoadLibraryEx o configurar un orden de búsqueda endurecido a nivel de proceso con SetDefaultDllDirectories, combinándolo con AddDllDirectory o SetDllDirectory para incluir únicamente directorios de confianza.

En sistemas que cuenten con el parche KB2533623, estas opciones están disponibles incluso en versiones antiguas como Windows 7 o Windows Server 2008 R2. Además, es buena idea asegurarse de que SafeDllSearchMode está habilitado en el registro (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager), algo que ya viene activado desde Windows XP SP2.

Otra medida práctica consiste en llamar a SetDllDirectory(«») al inicio del proceso para eliminar el directorio actual de la ruta estándar de búsqueda. Esto debe hacerse una sola vez en la inicialización y sabiendo que afecta a todos los hilos del proceso, por lo que se requiere probar la aplicación en profundidad, sobre todo si carga DLL de terceros.

Además, se debe evitar fiarse de la versión del sistema operativo deducida a través de cargas de DLL. Si una aplicación asume que la ausencia de una DLL indica cierta versión de Windows, pero el archivo aparece “mágicamente” en la ruta de búsqueda, podría terminar cargando una copia maliciosa plantada por un atacante en un entorno donde esa DLL no debería existir.

Medidas defensivas en sistemas Windows y entornos corporativos

Al margen del desarrollo seguro, los equipos de seguridad y administradores pueden desplegar varias capas de defensa para detectar y bloquear DLLs sospechosas en la práctica. Algunas de las más eficaces combinan control de aplicaciones, validación de firmas, monitorización avanzada y endurecimiento de permisos.

Una primera capa pasa por verificar firmas digitales de las DLL más sensibles. No es una bala de plata (las firmas pueden ser robadas o las DLL legítimas pueden ser vulnerables), pero ayuda a detectar sustituciones burdas o bibliotecas sin firma que se hacen pasar por componentes de sistema.

El uso de AppLocker o Windows Defender Application Control (WDAC) y características como VBS permite restringir qué ejecutables y DLL pueden cargarse según editor, ruta, hash, etc. Configurar reglas específicas para evitar la carga de DLL desde rutas de usuario, perfiles, carpetas temporales o unidades extraíbles es una medida muy efectiva.

La monitorización continua con un EDR moderno resulta clave. Estos productos pueden detectar patrones de carga de DLL anómalos (por ejemplo, un binario de sistema en una ruta extraña, DLL sin firma en directorios críticos, side-loading desde USB, etc.), correlacionarlos con otros eventos y disparar respuestas automáticas.

Otra pieza de la ecuación es el control de permisos y la higiene de directorios. Evitar que usuarios sin privilegios escriban en ubicaciones sensibles (carpetas de programas, rutas en PATH, directorios de servicios, etc.) reduce drásticamente las oportunidades para plantar DLL maliciosas. Igualmente, es importante revisar y limpiar periódicamente rutas de búsqueda y variables de entorno.

Finalmente, proyectos como HijackLibs proporcionan listas actualizadas de binarios vulnerables y DLL comúnmente abusadas en ataques de Hijacking y Side-Loading. Integrar esas listas en tus herramientas de detección, de forma manual o automatizada, ayuda a centrar la vigilancia en los puntos más explotados por los atacantes.

Todo este conjunto de prácticas, unido al uso de soluciones con IA como Kaspersky SIEM o DeepDLL, permite pasar de una defensa reactiva basada únicamente en firmas, a un modelo proactivo que detecta comportamientos anómalos, incluso cuando el malware es nuevo o está fuertemente ofuscado.

Con todo esto, el panorama de detección de DLL sospechosas en Windows ha cambiado por completo: las DLL siguen siendo un vector muy potente para los atacantes, pero hoy existen herramientas y metodologías maduras para identificarlas y bloquearlas, siempre que se combinen buenas prácticas de desarrollo, políticas de seguridad estrictas y monitorización inteligente apoyada en inteligencia artificial y análisis de comportamiento.