DLLs sospechosos de Windows: detección, hijacking y defensa

En los últimos años, las DLLs sospechosas de Windows se han convertido en uno de los vectores favoritos de los atacantes. No hablamos solo de malware clásico en formato EXE, sino de librerías aparentemente legítimas que se cuelan en procesos de confianza, se camuflan entre archivos del sistema y pasan por debajo del radar de muchas soluciones de seguridad.

Este auge no es casualidad: técnicas como el secuestro de DLL (DLL Hijacking), la carga lateral (Side-Loading) o la inyección de DLL explotan precisamente cómo Windows busca, carga y reutiliza estas bibliotecas compartidas. Si a esto le sumamos la aparición de motores de inteligencia artificial capaces tanto de detectar como de esconder este tipo de amenazas, tenemos un escenario en el que conviven defensores y atacantes usando estrategias cada vez más sofisticadas.

Qué es una DLL y por qué es tan jugosa para los atacantes

En Windows, una DLL (Dynamic Link Library) es un archivo que contiene código ejecutable, funciones y recursos reutilizables por múltiples programas al mismo tiempo. Su papel es similar al de las bibliotecas .so en sistemas Unix: permite que varias aplicaciones compartan la misma funcionalidad sin duplicar código, ahorrando memoria y espacio en disco.

Las DLLs suelen terminar con extensión .dll, aunque también pueden presentarse como .drv u otros formatos ejecutables, e incluso algunos EXE pueden funcionar, en la práctica, como contenedores de funcionalidades similares. El usuario final no las abre directamente: es el propio sistema o las aplicaciones quienes las cargan cuando las necesitan, normalmente al iniciar o durante la ejecución.

La consecuencia directa es que una sola DLL puede ser utilizada por varios programas a la vez. Si un atacante consigue que una de esas bibliotecas esté manipulada o contenga código malicioso, multiplicará el impacto: varios procesos de confianza podrían estar ejecutando la misma librería comprometida sin levantar sospechas evidentes.

Dentro de Windows existen decenas de DLLs críticas para el funcionamiento del sistema, muchas de ellas objetivo habitual en análisis de malware y en técnicas de ofuscación o inyección de código. Algunas de las más relevantes son:

• KERNEL32.dll: gestiona memoria, archivos, creación de procesos y acceso al hardware.
• Advapi32.dll: incluye funciones avanzadas relacionadas con el registro y la administración de servicios.
• User32.dll: maneja la interfaz gráfica, botones, barras de desplazamiento y eventos de usuario.
• Gdi32.dll: se ocupa de mostrar y manipular elementos gráficos en pantalla.
• Ntdll.dll: actúa como interfaz con el kernel de Windows; suele importarse de manera indirecta a través de KERNEL32.dll.
• WSock32.dll y Ws2_32.dll: proporcionan la funcionalidad de red básica (sockets, comunicaciones).
• Wininet.dll: implementa funciones de red de alto nivel (HTTP, FTP, NTP).

Cuando un ejecutable importa directamente Ntdll.dll para realizar operaciones no documentadas o de bajo nivel, muchas veces es una pista de que se buscan capacidades especiales, como ocultar procesos, evadir controles de seguridad o manipular el sistema de forma más agresiva de lo habitual.

Secuestro de DLL (DLL Hijacking): el truco de hacerse pasar por legítimo

El llamado secuestro de DLL o DLL Hijacking consiste en engañar a una aplicación para que cargue una biblioteca maliciosa en lugar de la legítima, aprovechando la forma en que Windows resuelve las rutas y el orden de búsqueda de estas librerías. Es un método veterano (se conoce desde la época de Windows 2000), pero sigue más vivo que nunca.

En esencia, el atacante coloca un archivo con el mismo nombre que una DLL esperada por un programa, en una ubicación que se evalúe antes que el directorio auténtico en la secuencia de búsqueda. Como Windows no siempre exige rutas absolutas ni verifica por defecto la autenticidad de la DLL, la aplicación termina cargando la copia falsa, activando el código malicioso con los permisos del proceso comprometido.

En sistemas Microsoft, el orden de búsqueda estándar de DLL puede variar según esté activado o no el modo de búsqueda segura (Safe DLL Search Mode), pero, simplificando, suele seguir una jerarquía similar a esta:

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

Cuando el modo de búsqueda segura está desactivado, el directorio actual del usuario puede subir posiciones en esta lista, aumentando el riesgo de que una DLL plantada en una carpeta de trabajo sea cargada antes que la original del sistema.

La clave del ataque está en que muchas aplicaciones no especifican la ruta completa de las DLL que necesitan; simplemente piden “cargar X.dll” y delegan en el sistema el resto. Si un ciberdelincuente consigue dejar su propia X.dll maliciosa en el directorio de la aplicación o en otro punto que se evalúe antes que System32, el sistema no distingue a simple vista entre la genuina y la impostora.

Así, un simple archivo DLL fue capaz de catalizar uno de los ciberataques más graves sufridos por la administración estadounidense, en el que una DLL firmada por un proveedor legítimo (SolarWinds) contenía carga maliciosa que permitió comprometer redes enteras durante meses sin ser detectada.

Variantes de secuestro de DLL y trucos relacionados

Dentro del paraguas del secuestro de DLL hay múltiples variantes que explotan distintos mecanismos internos de Windows. Aunque el objetivo es siempre el mismo (introducir una DLL maliciosa en un proceso legítimo), la forma de llegar a ello cambia ligeramente.

Manipulación de KnownDLLs

Windows mantiene una lista de KnownDLLs, es decir, librerías del sistema que se consideran conocidas y confiables. Cuando un proceso solicita una de estas DLL, el cargador la busca en un directorio especial y la asigna directamente al espacio de direcciones del proceso.

Esta lista se controla mediante claves de registro. Si un atacante consigue modificar configuraciones relacionadas con KnownDLLs, puede excluir sus DLL maliciosas de este mecanismo o manipular la forma en que determinadas librerías se resuelven, abriendo la puerta a sustituciones o cargas inesperadas. Para identificar librerías cargadas y referencias antiguas suele ser útil revisar utilidades como ListDLLs.

Ataques de carga lateral (Side-Loading) en WinSxS

La carpeta WinSxS (Windows Side-by-Side), ubicada normalmente en C:\\Windows\\WinSxS, almacena múltiples versiones de componentes y DLLs. Es clave para la gestión de actualizaciones, copias de seguridad y compatibilidad con diferentes versiones de bibliotecas.

Muchas aplicaciones usan WinSxS para evitar conflictos de versiones de DLL, apoyándose en manifiestos que indican qué versión concreta de cada biblioteca deben cargar en tiempo de ejecución. El problema es que estos manifiestos se basan en metadatos que, en ocasiones, pueden ser manipulados o aprovechados de forma maliciosa.

Investigaciones recientes han demostrado que es posible insertar DLL falsificadas en WinSxS y hacer que determinados binarios legítimos las carguen, explotando precisamente la forma en que se resuelven las dependencias en esa carpeta. Esto amplía mucho el abanico de binarios que se pueden utilizar para ejecutar código malicioso sin necesidad de subir nuevos ejecutables al sistema.

Esta técnica es especialmente peligrosa porque se aprovecha de binarios legítimos ya presentes en la carpeta WinSxS, evita a menudo la escalada de privilegios clásica y genera menos ruido comportamental, aumentando las probabilidades de pasar desapercibida ante muchas soluciones de seguridad.

Secuestro de DLL fantasma

El llamado Ghost DLL Hijacking se basa en DLLs históricas o de uso marginal que ciertas aplicaciones siguen intentando cargar al inicio, aunque no sean estrictamente necesarias. Es una especie de herencia del pasado que muchos programas nunca han “limpiado” de sus rutinas de inicialización.

Si un atacante identifica una de estas DLL olvidadas, solo tiene que crear un archivo con ese mismo nombre y colocarlo en una ruta de búsqueda prioritaria. El programa, al no encontrar la original, acabará tirando de la versión maliciosa, que se cargará sin demasiados controles adicionales.

Análisis estático de DLLs sospechosas: qué mirar sin ejecutarlas

Cuando sospechas que una DLL puede ser maliciosa, hay dos grandes enfoques de análisis: el estático y el dinámico. El análisis estático implica extraer información del archivo sin ejecutarlo, mientras que el dinámico se centra en observar qué hace realmente cuando se carga en un entorno controlado.

En el contexto de DLLs sospechosas, el análisis estático es fundamental para una primera valoración de riesgos. Permite revisar dependencias, funciones expuestas, metadatos, estructura interna y posibles indicios de empaquetado u ofuscación, todo ello sin poner en marcha el código potencialmente peligroso.

Herramientas clásicas como PEiD, Dependency Walker o PEview siguen siendo muy útiles para este tipo de revisión. Por ejemplo, con PEiD puedes examinar el encabezado PE, identificar packers o compresores usados y listar secciones del archivo.

Una de las primeras comprobaciones consistirá en revisar la tabla de importaciones y exportaciones. Ahí verás de qué DLLs depende la biblioteca sospechosa (por ejemplo, KERNEL32.dll, USER32.dll, MSVCRT.dll) y qué funciones concretas llama: escribir archivos (WriteFile), gestionar procesos, manipular memoria, abrir sockets, etc.

Con Dependency Walker podrás navegar por el árbol de dependencias, ver qué DLLs se cargan a su vez, y qué funciones se resuelven en contexto. Si detectas llamadas a funciones sensibles (inyección de código, modificación del registro en zonas críticas, comunicaciones no esperadas), sube el nivel de alerta.

PEview, por su parte, facilita la inspección detallada de la estructura interna del archivo: timestamp de compilación, secciones modificadas, tablas de direcciones de importación, etc. Consultar el sello de tiempo puede ayudarte a correlacionar la DLL con campañas concretas, a comprobar si encaja con otros artefactos del mismo atacante o a identificar si se trata de un binario muy reciente sin apenas referencias públicas.

Carga, ejecución y detección manual de secuestro de DLL

Para ejecutar o registrar DLLs en un entorno Windows, se utilizan utilidades como Regsvr32.exe y Rundll32.exe. La primera sirve para registrar la DLL en el sistema (por ejemplo, como componente COM), mientras que la segunda permite llamar a funciones exportadas concretas desde línea de comandos.

Los atacantes pueden automatizar el uso de estas herramientas mediante scripts (por ejemplo, en VBScript o PowerShell), integrándolas en campañas que abusan de dispositivos USB, tareas programadas o macros de documentos ofimáticos para lanzar DLLs maliciosas sin mucha interacción del usuario.

Si sospechas de un posible secuestro de DLL en un equipo concreto, una forma práctica de investigar es utilizar Process Monitor (Procmon) de la suite Sysinternals. Esta herramienta permite ver en tiempo real todas las operaciones de entrada/salida sobre el sistema de archivos y el registro.

El procedimiento habitual para detectar secuestro de DLL con Process Monitor pasa por:

• Filtrar por la aplicación potencialmente afectada, de modo que solo veas las operaciones relacionadas con ese proceso.
• Añadir un filtro para mostrar únicamente archivos cuya ruta termine en .dll, centrándote en las bibliotecas cargadas.
• Aplicar un filtro donde el resultado sea «NAME NOT FOUND» (NOMBRE NO ENCONTRADO), lo que indica intentos de carga fallidos o rutas alternativas donde se busca la misma DLL fuera de los directorios del sistema.

La lista de eventos resultante te muestras desde rutas externas al sistema, lo que suele ser un síntoma claro de que se está buscando una alternativa en directorios menos controlados. Si, además, filtras por la ruta de la propia aplicación, podrás aislar las DLLs que se están resolviendo desde el mismo directorio del ejecutable, típico comportamiento aprovechado por el secuestro de orden de búsqueda.

Por qué es tan difícil distinguir entre falso positivo y DLL peligrosa

En un entorno real de empresa es habitual que las soluciones de seguridad generen alertas sobre procesos y DLLs en apariencia legítimos. Un ejemplo clásico es ver hilos o interacciones entre procesos críticos como winlogon.exe y csrss.exe, que pueden levantar sospechas pero, muchas veces, responden a funcionamiento normal del sistema.

Para afinar el criterio y no caer en el pánico cada vez que salta una alerta, hay que mirar el contexto completo: origen del archivo, reputación, firma digital, cambios de nombre sospechosos, tamaño y estructura del binario, comportamiento de red, operaciones sobre el disco, etc.

En casos como una alerta de threading entre winlogon.exe y crss.exe, lo razonable es revisar procesos activos, consultas DNS, escrituras en disco y eventos de seguridad. Si todo apunta a un patrón habitual, sin conexiones extrañas ni modificaciones fuera de lo normal, es legítimo catalogarlo como falso positivo, aunque siempre conviene documentar el análisis.

La dificultad principal está en que la línea que separa una DLL legítima de una maliciosa muy bien camuflada es cada vez más fina, sobre todo cuando se usan técnicas avanzadas de ofuscación, empaquetado o secuestro de librerías del propio sistema.

Uso de inteligencia artificial para detectar DLLs sospechosas

Ante este panorama, los fabricantes de seguridad han empezado a apostar fuerte por modelos de aprendizaje automático (Machine Learning) especializados en análisis de DLL y técnicas de hijacking. Estos modelos no se limitan a buscar patrones estáticos clásicos, sino que correlacionan multitud de señales indirectas.

Un ejemplo lo encontramos en el modelo desarrollado por el Kaspersky AI Technology Research Center para detectar secuestro de DLL. En lugar de mirar únicamente el contenido de la biblioteca, el modelo se centra en información contextual: ruta de la DLL y del ejecutable que la carga, cambios de nombre, estructura interna, tamaño, integridad de la firma digital, reputación previa del archivo, etc.

Para entrenar este tipo de modelos, se utilizan grandes volúmenes de datos sobre eventos de carga de DLL recogidos tanto de sistemas internos de análisis como de telemetría anónima, proporcionada por usuarios que participan en redes de seguridad en la nube (como Kaspersky Security Network). El etiquetado se apoya en bases de datos de reputación consolidadas.

Las primeras versiones de estos modelos suelen ser aún imprecisas, pero tras varias iteraciones de entrenamiento, ajuste de características y depuración de etiquetas, se consigue una tasa de acierto muy alta, reduciendo falsos positivos y mejorando la capacidad para identificar patrones sutiles asociados al secuestro de DLL.

En el caso concreto de la plataforma SIEM de Kaspersky (Kaspersky Unified Monitoring and Analysis Platform), el modelo se integra de dos formas posibles: en el motor de correlación de eventos y en el subsistema de recopilación. En el primero, solo analiza eventos que ya han disparado reglas de correlación, aportando una segunda capa de verificación rápida sin saturar la infraestructura. En el segundo, revisa de manera más amplia todos los eventos de carga de DLL que cumplan ciertos criterios, ideal para búsquedas retrospectivas más exhaustivas.

Otros proveedores, como Check Point, han desarrollado motores específicos como DeepDLL, integrado en su ecosistema ThreatCloud AI. Este motor examina metadatos, cadenas de ataque y la propia estructura compilada de los archivos DLL, cruzando la información con el contexto de llegada (correo, descarga desde web, instaladores MSI, archivos comprimidos, etc.).

Según datos de la propia compañía, DeepDLL alcanza tasas de detección cercanas al 99,7% con muy pocos falsos positivos, siendo capaz incluso de identificar muestras que no llevan extensión .dll pero contienen una estructura interna equivalente. Un caso ilustrativo es el bloqueo de una DLL maliciosa incrustada en un instalador MSI, detectada en el momento de la descarga antes de que pudiera ejecutarse.

Lo interesante de estos enfoques basados en IA es que mejoran con el tiempo: cuantos más datos recopilan sobre amenazas y comportamientos benignos, más afinan los modelos, y mejor se adaptan a nuevas técnicas de evasión o variantes aún no documentadas.

Cómo reducir el riesgo de DLL Hijacking en entornos Windows

La responsabilidad de frenar el secuestro de DLL empieza por los propios desarrolladores de software. Una de las mejores prácticas es especificar siempre rutas absolutas para las DLL sensibles, en lugar de confiar en el orden de búsqueda por defecto del sistema. Eso reduce de raíz muchas oportunidades de que una biblioteca maliciosa se cuele en la cadena de carga.

Sin embargo, en la práctica, no todos los proyectos respetan las guías de codificación segura. Por ello, las organizaciones tienen que complementar ese primer nivel con una defensa en profundidad que incluya:

• Antivirus y EDR actualizados, capaces de analizar DLLs en disco, en memoria y en tránsito, incluyendo técnicas de comportamiento e IA.
• Herramientas especializadas como DLLSPY, diseñadas para descubrir vulnerabilidades de secuestro y escalada de privilegios asociadas al uso de DLLs.
• Monitorización continua de la superficie de ataque, tanto en endpoints como en servidores, para identificar rutas y binarios que puedan ser aprovechados en técnicas de Side-Loading o Hijacking.

Un punto crítico es la formación del personal frente a phishing e ingeniería social. Al final, para que una DLL maliciosa haga daño, alguien tiene que introducirla en el ecosistema: abrir un adjunto fraudulento, ejecutar un instalador manipulado, conectar un USB con contenido sospechoso, etc.

Conviene reforzar políticas claras, como disponer de una Política de Seguridad de la Información bien comunicada, obligar a usar autenticación multifactor, y establecer canales para reportar correos o archivos sospechosos a un equipo de referencia antes de interactuar con ellos.

En el entorno de terceros y proveedores, el riesgo aumenta: no todos los partners mantienen el mismo nivel de ciberseguridad. Herramientas de gestión de riesgo de proveedores permiten monitorizar la postura de seguridad de la cadena de suministro, lanzar cuestionarios alineados con marcos normativos y seguir el progreso de las medidas correctivas mediante puntuaciones de riesgo dinámicas.

El papel de las herramientas de limpieza y la protección preventiva

En caso de infección, existen utilidades pensadas únicamente para eliminar malware ya activo en el sistema, como la herramienta de eliminación de software malintencionado de Microsoft (MSRT). Es importante entender que estas herramientas no sustituyen a un antivirus completo.

MSRT, por ejemplo, se centra en detectar y eliminar una lista concreta de amenazas muy extendidas (virus, gusanos, troyanos) que estén en ejecución en el momento del análisis. No pretende cubrir todo el espectro de malware, ni quitar software malicioso que no esté activo, ni encargarse del spyware u otro tipo de amenazas más especializadas.

La recomendación es clara: usar estas herramientas de limpieza como apoyo tras una infección, pero mantener siempre instalado y actualizado un producto antivirus o EDR que bloquee la ejecución del malware desde el principio. Además, hay que tener en cuenta que, si el sistema ya estaba infectado antes de desplegar el antivirus, puede que este solo detecte algunas piezas de malware cuando la herramienta de eliminación intente neutralizarlas. Para guías prácticas sobre herramientas de limpieza y análisis inicial, es útil consultar recursos sobre herramientas de limpieza y análisis.

Todo este ecosistema de defensas, desde el antivirus tradicional hasta los motores basados en IA, pasando por los SIEM y las herramientas de limpieza, debe trabajar coordinado para reducir al mínimo la ventana de oportunidad de los atacantes que se aprovechan de DLLs sospechosas.

A la vista de la cantidad de vulnerabilidades publicadas en los últimos años y de la evolución del secuestro de DLL hacia técnicas más discretas (como el abuso de WinSxS o las cadenas de suministro), resulta imprescindible tratar las DLLs sospechosas de Windows como un vector de ataque prioritario: entender cómo funcionan, saber analizarlas tanto estática como dinámicamente, apoyarse en la inteligencia artificial para detectar patrones sutiles y reforzar la formación y las políticas de seguridad alrededor de ellas es lo que marca la diferencia entre una simple alerta y un incidente de gran impacto que se podría haber evitado.