Inyección de DLL y secuestro de DLL: riesgos y detección

Cuando se habla de inyección de DLL y secuestro de DLL en Windows, no estamos ante una simple curiosidad técnica, sino frente a una de las vías favoritas de los atacantes para colarse en sistemas, robar datos y moverse con privilegios elevados sin levantar sospechas. Es una familia de técnicas veteranas, pero siguen muy vigentes porque explotan algo tan básico como la forma en que Windows carga bibliotecas en memoria.

Si alguna vez te has preguntado por qué una sola DLL maliciosa puede tumbar toda una organización, este es el motivo: basta con lograr que un proceso legítimo cargue una biblioteca manipulada para que el código del atacante herede todos sus permisos, confunda a muchos antivirus y, en el peor de los casos, permanezca en el sistema durante meses. Vamos a desmenuzar cómo funciona todo esto, qué tipos de técnicas existen, qué riesgos reales implican y qué puedes hacer para detectar y reducir el impacto.

Qué es una DLL y por qué es tan interesante para un atacante

Una DLL (Dynamic-Link Library) es, básicamente, una biblioteca compartida que contiene código y datos reutilizables por varias aplicaciones a la vez. Windows las usa hasta la saciedad para no duplicar código y gestionar de forma más eficiente la memoria, el disco y los recursos del sistema.

Desde el punto de vista del usuario no hay mucho misterio: no se abren como un programa normal, las consume de forma transparente la aplicación que las necesita cuando se ejecuta. Para el sistema, en cambio, son piezas críticas: contienen funciones, recursos gráficos, controladores y toda clase de rutinas que permiten que el software funcione.

La mayoría de estos archivos terminan en .dll, aunque también pueden aparecer como .drv, .drov o incluso ejecutables .exe que actúan como bibliotecas. Un solo archivo puede ser llamado por múltiples procesos a la vez, lo que implica que, si ese archivo está comprometido, el atacante puede colarse simultáneamente en varias aplicaciones.

Ahí está la gracia (y el problema): si consigues que un proceso cargue una DLL manipulada, el código de esa biblioteca se ejecutará con los permisos de ese proceso, ya sea una aplicación de usuario, un servicio privilegiado o incluso software de seguridad que, paradójicamente, debería protegerte.

DLL Hijacking o secuestro de DLL: concepto y funcionamiento

El llamado DLL Hijacking (o secuestro de DLL) es una técnica que explota la forma en que algunas aplicaciones de Windows buscan las bibliotecas que necesitan. En lugar de especificar siempre la ruta exacta de cada DLL, muchos programas dejan que sea el propio sistema el que siga su orden de búsqueda predeterminado.

El problema surge cuando una aplicación intenta cargar una DLL por nombre, sin ruta completa y sin validar su integridad o procedencia. Si un atacante consigue colocar en un directorio accesible un archivo malicioso con el mismo nombre que la DLL esperada, Windows podría cargar la falsa antes que la legítima, dando al atacante el control del proceso.

Esta técnica lleva en juego desde la época de Windows 2000 y sigue funcionando porque el mecanismo básico de búsqueda apenas ha cambiado: el sistema recorre varios directorios en un orden concreto hasta encontrar el archivo. Ese orden es, precisamente, lo que aprovecha un atacante para “colar” su versión alterada más arriba en la lista.

En entornos reales, el secuestro de DLL se ha usado en ataques a la cadena de suministro, comprometiendo proveedores de confianza para distribuir DLL firmadas digitalmente pero maliciosas, como ocurrió en el incidente de SolarWinds, donde una simple biblioteca alterada desencadenó una brecha masiva contra organismos gubernamentales de Estados Unidos.

Orden de búsqueda de DLL en Windows y dónde se aprovecha el fallo

Las aplicaciones de Windows se apoyan en un orden de búsqueda estándar de DLL cuando no se especifica una ruta completa. Este comportamiento depende además de si está activado el llamado “modo de búsqueda segura de DLL”.

Con la búsqueda segura habilitada, el sistema prioriza rutas más confiables. El orden típico es:

• Directorio desde el que se carga la aplicación.
• Directorio del sistema (normalmente C:\Windows\System32).
• Directorio del sistema de 16 bits.
• Directorio de Windows.
• Directorio actual de trabajo del usuario.
• Directorios definidos en la variable de entorno PATH.

Si la búsqueda segura está desactivada, el directorio actual del usuario sube posiciones en esa jerarquía y se consulta antes que ciertas rutas del sistema. Ese pequeño cambio basta para que una DLL colocada por el atacante en el directorio de trabajo sea la que se cargue en lugar de la genuina.

Imagina una aplicación que necesita una DLL concreta alojada en C:\Windows\System32, pero cuyo código no indica de forma explícita esa ruta. El sistema mirará primero el directorio de la aplicación, luego (según la configuración) el directorio actual u otros directorios antes de llegar a System32. Si el atacante deja una copia manipulada en el camino, la aplicación la abrirá creyendo que es la original.

Esto es lo que se conoce como secuestro del orden de búsqueda de DLL. El vector es sencillo: depositar la DLL maliciosa en un directorio que Windows examine antes que el directorio legítimo. La forma de llegar ahí puede variar: ingeniería social, phishing, escritura en rutas compartidas, despliegues a través de proveedores, etc.

Variantes frecuentes de secuestro de DLL

El concepto de base (inyectar una DLL maliciosa en la carga normal del programa) da pie a varias variantes técnicas. Todas buscan lo mismo, pero cambian el detalle de cómo se cuela la biblioteca en el proceso.

Una de ellas se basa en las KnownDLLs, que es una lista de DLL del sistema conocidas y gestionadas a través del registro de Windows. Cuando una aplicación solicita una de estas bibliotecas, el cargador consulta primero este conjunto especial. Manipulando claves de registro relacionadas, un atacante puede evitar que su DLL pase por el filtro de KnownDLLs y obligar al sistema a resolver el nombre contra su propia versión maliciosa.

Otra técnica popular es la carga lateral de DLL (DLL side-loading), que explota el directorio WinSxS (C:\Windows\WinSxS). Este almacén contiene múltiples versiones de la misma biblioteca para evitar conflictos entre aplicaciones. Un programa consulta un “manifiesto” que indica qué versiones puede usar. El atacante puede introducir una DLL falsificada en dicho directorio manipulando sus metadatos para que parezca válida para el manifiesto, logrando que se cargue su versión.

Existe también el llamado secuestro de DLL fantasma, que juega con librerías antiguas o poco usadas que algunas aplicaciones siguen intentando cargar en el arranque aunque ya no sean fundamentales. Si el atacante crea una DLL con ese nombre “olvidado” y la coloca en la ruta adecuada, puede conseguir que se ejecute código malicioso sin que nadie preste atención, ya que el archivo original ni siquiera suele existir.

En todos los casos, el objetivo es el mismo: situar la DLL falsa en el lugar correcto, en el momento adecuado y con un nombre que el proceso de destino vaya a buscar, de forma que sea el sistema operativo quien cargue y ejecute el código del atacante dentro del proceso legítimo.

Inyección de DLL: cuando el atacante fuerza la carga en memoria

Además del secuestro pasivo del orden de búsqueda, existe la inyección activa de DLL en procesos. Aquí el atacante no espera a que el programa se equivoque de ruta, sino que utiliza la API de Windows para forzar que un proceso cargue su biblioteca.

La idea es sencilla pero potente: al inyectar una DLL en un proceso en ejecución, el malware hereda sus privilegios y accede a su espacio de memoria. A partir de ahí puede registrar pulsaciones de teclado, capturar pantallas, robar datos, interceptar llamadas a funciones de seguridad, instalar más malware o modificar el comportamiento de la propia aplicación.

La inyección suele implicar varias fases: preparar la DLL (con un DllMain que ejecute el payload al cargarse), reservar memoria en el proceso de destino para guardar la ruta de esa DLL, escribir esa ruta con WriteProcessMemory y, por último, crear un hilo remoto que invoque LoadLibraryA dentro del proceso objetivo.

La DLL inyectada se ejecuta en el contexto de ese proceso, con sus tokens de seguridad y su nivel de confianza. Eso permite, entre otras cosas, evadir controles de seguridad basados en archivos, ya que el código malicioso sólo existe en memoria, o desactivar soluciones de protección desde dentro de sus propios procesos.

Diferencias entre programar EXE y DLL maliciosos

Cuando un desarrollador de malware decide crear un ejecutable (.exe) o una DLL, el punto de entrada y el modelo de ejecución cambian de forma importante. En un EXE típico, el sistema invoca una función main (o WinMain) al lanzar el proceso; en una DLL el flujo no funciona así.

Las bibliotecas dinámicas usan una función especial llamada DllMain, que es el punto de entrada cuando la DLL se carga, se descarga o cuando se crean/destrozan hilos dentro del proceso que la tiene mapeada. El cargador no “lanza” la DLL como un programa aislado, sino que simplemente llama a DllMain en distintos eventos.

Muchas DLL legítimas exportan varias funciones para que otros módulos las utilicen. En cambio, una DLL maliciosa pensada exclusivamente para inyección puede limitarse a implementar DllMain con el código necesario y no exportar nada, de forma que su ejecución ocurra justo al ser cargada sin necesidad de llamadas posteriores explícitas.

Esto implica que el atacante debe cuidar cómo compila y enlaza su DLL: qué dependencias añade, qué opciones de runtime utiliza y cómo gestiona la compatibilidad entre distintas versiones de Windows o entre arquitecturas de 32 y 64 bits.

Entorno de desarrollo típico para DLL maliciosas

Para compilar DLL de prueba o verdaderas cargas maliciosas se recurre con frecuencia a Visual Studio en Windows (incluyendo proyectos en Visual Basic) o a toolchains cruzados como mingw-w64 desde Linux. En el primer caso basta con crear un proyecto C/C++ y configurarlo como biblioteca dinámica para que el IDE genere automáticamente la estructura necesaria.

Dentro de las opciones de compilación, es común ajustar la sección de Code Generation. Por ejemplo, se puede seleccionar Multi-threaded Debug (/MTd) durante el desarrollo para incluir información de depuración y después pasar a Multi-threaded (/MT) en la versión final, integrando la biblioteca de tiempo de ejecución en el propio binario, lo que facilita que se ejecute en más equipos sin dependencias externas.

Desde Linux se puede optar por x86_64-w64-mingw32-gcc para generar ejecutables y DLL para Windows. Es habitual añadir flags de optimización como -O2, reducir el tamaño con -s y seccionar funciones y datos (con -ffunction-sections y -fdata-sections) para eliminar código muerto en el linkado.

También se suelen emplear opciones como -static-libstdc++ and -static-libgcc para enlazar de manera estática las bibliotecas estándar de C y C++, lo que hace que el binario resultante sea más autosuficiente. Otros parámetros como -fno-exceptions, -fmerge-all-constants o -fpermissive ayudan a ajustar el comportamiento del compilador y reducir la superficie de código innecesario.

Inyección remota de DLL: paso a paso técnico

Una de las técnicas clásicas es la inyección remota de DLL, en la que un proceso controlado por el atacante inyecta una biblioteca en otro proceso legítimo. El flujo general suele incluir varias llamadas clave de la API de Windows.

En primer lugar, el proceso malicioso puede habilitar el privilegio de depuración SE_DEBUG_PRIVILEGE para tener derecho a manipular otros procesos. A continuación abre un manejador hacia el proceso de destino con OpenProcess, solicitando permisos como PROCESS_CREATE_THREAD o PROCESS_VM_WRITE para poder escribir en su memoria y crear hilos.

Después se reserva memoria dentro del proceso víctima con VirtualAllocEx, donde se guardará la ruta completa de la DLL a inyectar. El atacante escribe esa ruta en la región recién asignada usando WriteProcessMemory, de forma que el proceso de destino tiene ahora en su espacio de direcciones un buffer con el path de la DLL maliciosa.

Para conseguir que la DLL se cargue, hay que llamar a LoadLibrary dentro de ese proceso. Esta función reside en kernel32.dll, que suele mapearse en la misma dirección en todos los procesos dentro de una misma máquina. El atacante obtiene un manejador al módulo con GetModuleHandle y luego localiza la dirección exacta de LoadLibrary con GetProcAddress.

Por último, crea un hilo remoto con CreateRemoteThread, indicando como punto de entrada la dirección de LoadLibrary y como parámetro el puntero al buffer que contiene la ruta de la DLL. Cuando el hilo arranca en el proceso objetivo, ejecuta LoadLibrary con esa ruta, cargando la DLL maliciosa en su espacio de memoria y disparando su DllMain.

Otras técnicas de inyección de procesos y su peligrosidad

La inyección remota de DLL es solo una pieza del puzzle. Bajo el paraguas de inyección de procesos hay muchas variantes que persiguen exactamente lo mismo: hacer que otro proceso ejecute código arbitrario en su propio contexto.

Entre las más comunes está la inyección de código directa, donde en vez de cargar una DLL se escribe shellcode crudo en la memoria del proceso objetivo. El flujo es similar: se abre el proceso, se reserva memoria con VirtualAllocEx, se escribe el payload con WriteProcessMemory y se dispara su ejecución con CreateRemoteThread u otros mecanismos.

Otra variante es el secuestro de ejecución de hilos, que no crea hilos nuevos sino que toma uno ya existente. El atacante lo suspende con SuspendThread, lee su contexto con GetThreadContext, modifica el puntero de instrucción para señalar a su propio código, y lo reanuda con ResumeThread. Así el código malicioso se ejecuta “disfrazado” de hilo legítimo.

La inyección APC (Asynchronous Procedure Call) utiliza QueueUserAPC para poner en cola una rutina dentro de un hilo que pase por estados de espera. Cuando el hilo procesa su cola de APC, ejecuta el código inyectado sin que sea tan evidente la creación de un hilo remoto nuevo.

Especialmente sigilosa resulta la inyección de DLL reflexiva, donde la propia DLL contiene un cargador incorporado capaz de mapearse a sí misma en memoria sin escribir nada en disco ni usar el mecanismo estándar de LoadLibrary. Esto dificulta la detección basada en actividad del sistema de archivos y eventos de carga de módulos.

Finalmente, el llamado proceso hueco (process hollowing) crea un proceso legítimo en estado suspendido, borra su imagen de memoria original (con funciones como NtUnmapViewOfSection), asigna memoria nueva, escribe dentro el PE malicioso, ajusta el encabezado y las reubicaciones, corrige el contexto del hilo principal con SetThreadContext y reanuda su ejecución. Para el sistema, parece que se está ejecutando la aplicación legítima, pero en realidad el interior ha sido reemplazado por código del atacante.

Fundamentos de memoria de procesos en Windows

Para entender por qué estas técnicas funcionan hay que tener clara la estructura de la memoria virtual de un proceso en Windows. Cada proceso posee su propio espacio de direcciones virtuales aislado, que en 32 bits va aproximadamente de 0 a 0x7FFFFFFF y en 64 bits se extiende mucho más allá.

Este espacio se divide en distintas regiones: el código ejecutable del programa, sus DLL cargadas, las pilas de los hilos, los montones (heaps) y otras áreas reservadas. El Administrador de memoria del sistema se encarga de mapear estas direcciones virtuales a marcos de memoria física a través de la paginación.

Cada región tiene asociadas unas protecciones de acceso que definen qué se puede hacer con ella: PAGE_READ, PAGE_WRITE, PAGE_EXECUTE, combinaciones como PAGE_EXECUTE_READWRITE, etc. Si un proceso intenta acceder de forma no permitida, Windows genera una violación de acceso.

Las técnicas de inyección juegan precisamente con estas protecciones, solicitando memoria con permisos concretos, cambiando atributos con VirtualProtect o VirtualProtectEx, leyendo datos de otros procesos con ReadProcessMemory o liberando regiones con VirtualFreeEx. Muchas detecciones de EDR se basan en observar cadenas sospechosas de estas llamadas entre procesos.

En resumen, el modelo de memoria aislada y gestionada mediante la API facilita que un proceso “toque” la memoria de otro siempre que obtenga los derechos adecuados, algo que el malware explota con soltura mientras intenta mantenerse por debajo del radar de las herramientas de defensa.

Persistencia mediante AppInit_DLLs y riesgos asociados

Más allá de la inyección puntual, algunos malware abusan de mecanismos de Windows para mantenerse persistentes en cada arranque o cada ejecución de determinadas aplicaciones. Uno de los clásicos es el uso de la clave de registro AppInit_DLLs.

Al modificar esta clave, el atacante indica que se cargue una determinada DLL en prácticamente cualquier proceso que haga uso de user32.dll, es decir, en casi todas las aplicaciones con interfaz gráfica. El resultado es que, cada vez que se abre un programa, la DLL maliciosa se inyecta automáticamente antes de que la aplicación comience su ejecución normal.

Un patrón típico observado en muestras reales consiste en que un primer ejecutable malicioso crea otro archivo (por ejemplo, un nuevo .exe) y programa su ejecución periódica mediante el Programador de tareas de Windows. Esa tarea se lanza en cada inicio del sistema, y el segundo binario se encarga de escribir en disco la DLL maliciosa y de configurar AppInit_DLLs para que apunte a ella.

A partir de ese momento, cada proceso gráfico arrastra consigo la DLL, que puede inspeccionar qué aplicación se está cargando y decidir si actúa o se retira discretamente de memoria para no llamar la atención. Por ejemplo, podría ignorar procesos como la calculadora, pero permanecer en navegadores o gestores de correo para robar credenciales e información sensible.

Este tipo de persistencia hace que el código malicioso se ejecute mucho antes de que el usuario pueda siquiera interactuar con la aplicación, lo que dificulta su detección a simple vista y permite a los atacantes tener un control bastante profundo sobre el entorno de usuario.

Detección de secuestro e inyección de DLL

Detectar estas técnicas no es trivial porque, en muchos casos, el código nocivo solo existe en memoria y se ejecuta dentro de procesos legítimos. Sin embargo, hay varias aproximaciones que, combinadas, ofrecen buenas probabilidades de cazar comportamientos anómalos.

Una de las más directas es el análisis de la actividad de carga de DLL mediante herramientas como Process Monitor o Process Explorer. Filtrando por operaciones relacionadas con archivos que terminan en .dll y que devuelven resultados como FILE NOT FOUND, se puede ver cuándo un proceso intenta localizar bibliotecas fuera de los directorios de sistema esperados.

Aplicando filtros adicionales sobre la ruta de carga (por ejemplo, el directorio de la propia aplicación en vez de System32), se pueden identificar DLL externas que se cuelan fuera de la ruta legítima. Esa lista de archivos es un buen punto de partida para revisar si hay bibliotecas manipuladas.

Por otro lado, muchas soluciones EDR modernos monitorizan patrones de API sospechosos: secuencias como OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread o llamadas masivas a QueueUserAPC y SetThreadContext disparan reglas de comportamiento.

También se analizan las regiones de memoria ejecutables dentro de cada proceso, buscando páginas que tengan permisos de ejecución pero cuyo contenido no coincida con el código esperado del binario original. Los escáneres de memoria pueden detectar saltos inusuales, reubicaciones extrañas o bloques de shellcode que no deberían estar ahí.

En el ámbito forense, el examen de volcados de memoria y el cotejo de firmas digitales de DLL cargadas frente a sus equivalentes en disco ofrecen pistas claras de manipulación. Si una biblioteca en memoria difiere de su versión firmada en disco, es una señal roja de posible inyección o parcheo malicioso.

Medidas de prevención y endurecimiento frente a inyección de DLL

Blindar completamente un sistema contra la inyección de DLL y el secuestro de bibliotecas es complicado, pero se pueden poner barreras que dificulten mucho el trabajo al atacante y reduzcan el impacto si consigue entrar.

El primer frente está en los desarrolladores de software: es crucial que las aplicaciones especifiquen rutas absolutas cuando cargan DLL críticas, evitando dejar en manos del orden de búsqueda del sistema la resolución del archivo. Además, conviene validar las firmas digitales de las bibliotecas antes de aceptarlas.

En el lado del sistema, herramientas como AppLocker o Windows Defender Application Control (WDAC) permiten restringir qué ejecutables y DLL están autorizados a cargarse. Combinados con políticas de integridad de código, bloquean módulos sin firmar o con firmas no confiables, frenando muchos intentos de secuestro.

No hay que olvidarse de las medidas de protección de memoria como DEP (Data Execution Prevention), que impide ejecutar código desde regiones marcadas sólo como datos, o ASLR (Address Space Layout Randomization), que dificulta conocer las direcciones exactas de módulos y reduce la fiabilidad de algunos exploits.

Mitigaciones adicionales como Control Flow Guard (CFG) vigilan que las llamadas indirectas de código no salten a lugares arbitrarios, y mecanismos de proceso protegido (PPL) limitan qué procesos pueden abrir manejadores hacia otros, endureciendo la superficie de ataque para las inyecciones entre procesos.

Por último, a nivel organizativo, es esencial mantener antivirus y EDR actualizados, revisar periódicamente permisos de escritura en directorios donde residan ejecutables y DLL, y formar al personal para reducir al máximo los vectores iniciales (phishing, ficheros adjuntos, descargas de orígenes dudosos) que permiten plantar la primera DLL maliciosa en el sistema.

Las técnicas de inyección de DLL, secuestro de bibliotecas e inyección de procesos en general conforman un arsenal veterano pero tremendamente eficaz para los atacantes, capaz de aprovechar detalles de la carga de módulos en Windows para ocultar código en procesos de confianza, escalar privilegios y esquivar controles tradicionales. Conocer a fondo cómo funcionan las DLL, cómo las buscan las aplicaciones, qué APIs se usan para manipular memoria y procesos, y qué mecanismos de prevención y monitorización están disponibles, marca la diferencia entre un entorno en el que una simple DLL alterada puede arrasar sin oposición y otro en el que cualquier intento de colarse deja un rastro ruidoso que las defensas pueden detectar y cortar a tiempo.