¿Qué es la inyección de DLL? Cómo funciona y cómo detectarla

La inyección de DLL es una técnica en la que el código de una biblioteca de enlace dinámico (DLL) se carga y se ejecuta dentro del espacio de direcciones de otro proceso que ya está en marcha. Esta explicación es deliberadamente defensiva: describe qué es la técnica, por qué la valoran los atacantes, cómo se detecta y cómo eliminar las condiciones de las que depende, sin ofrecer una receta utilizable como arma.

Primero, qué es una DLL

Una biblioteca de enlace dinámico es una biblioteca compartida de código y datos que los programas de Windows cargan en tiempo de ejecución en lugar de compilarla dentro de cada ejecutable. Las DLL están en todas partes y son completamente normales: permiten que varios programas compartan funciones comunes, mantienen pequeños los ejecutables y permiten actualizar los componentes por separado. Una aplicación en marcha suele tener muchas DLL cargadas a la vez en memoria. Algún software legítimo incluso carga bibliotecas en otros procesos a propósito: los depuradores, la instrumentación de rendimiento, las herramientas de accesibilidad y las capas de compatibilidad lo hacen. El mecanismo en sí es una función, no un fallo.

Por qué abusan de ella los atacantes

Los atacantes abusan de la inyección de DLL porque ejecutarse dentro de un proceso de confianza les da dos premios:

• Evasión. El código que se ejecuta dentro de un proceso firmado y de buena reputación (un navegador, una aplicación ofimática, un servicio del sistema) hereda la identidad, la reputación de red y los permisos de ese proceso. Los controles que toman decisiones según el nombre o la firma del proceso ven el anfitrión de confianza, no el código hostil que viaja dentro. No hay ningún proceso independiente obviamente malicioso que un analista pueda detectar.
• Persistencia y sigilo. Vivir dentro de un proceso legítimo ayuda a un atacante a mantener un punto de apoyo que sobrevive a una inspección superficial, y puede permitirle observar o manipular los datos que maneja ese proceso. La actividad hostil queda camuflada por el comportamiento normal del anfitrión.

En resumen, la inyección resulta atractiva precisamente porque toma prestada la confianza que los defensores y el sistema operativo depositan en un proceso existente.

Cómo funciona, a nivel conceptual

A nivel conceptual, la inyección consiste en hacer que un proceso objetivo cargue una biblioteca elegida por el atacante y empiece a ejecutar su código dentro de ese proceso. Tienen que ocurrir dos cosas: el objetivo debe llegar a cargar la biblioteca y la ejecución debe empezar en el contexto del objetivo. En las técnicas documentadas que estudian los investigadores de seguridad y los defensores, lograrlo suele requerir que el atacante ya tenga acceso suficiente para manipular el proceso objetivo, lo que en sí es un dato útil para los defensores, porque significa que la inyección suele ser una fase posterior de una intrusión, no el punto de entrada.

Hay varias categorías conocidas de mecanismos, que se diferencian en cómo se provocan la carga y la ejecución, y están bien catalogadas en bases de conocimiento defensivas como las técnicas de inyección de procesos de MITRE ATT&CK. Este artículo se detiene a propósito en ese nivel de descripción. Reproducir un método funcional no añade nada a la capacidad de un defensor para detectar o prevenir la técnica, y los comportamientos detectables que siguen son los mismos sea cual sea el mecanismo concreto que elija un atacante.

Cómo detectar la inyección de DLL

La buena noticia para los defensores es que la inyección hace ruido si vigilas los eventos adecuados. Deja rastros observables, y las herramientas modernas están hechas para detectarlos:

• Monitorización de la carga de imágenes (módulos). El sistema operativo y el EDR pueden registrar cada biblioteca que carga un proceso. Un proceso que carga una biblioteca sin firmar, inesperada o en una ubicación inusual (un gestor de documentos ofimáticos que de repente carga una DLL desconocida desde una carpeta temporal) es una señal fuerte.
• Comportamiento entre procesos y de memoria. La inyección depende de operaciones que tocan la memoria y la ejecución de otro proceso. El EDR puede señalar las asignaciones de memoria sospechosas, el acceso entre procesos y la creación de hilos remotos que requieren estas técnicas.
• Correlación de comportamientos. Las detecciones más fiables combinan señales: un proceso de confianza que carga una biblioteca inesperada y después hace conexiones de red anómalas o lanza procesos hijos inusuales es mucho más sospechoso que cualquier evento aislado.

Todo esto se apoya en una buena telemetría. Si no se registran los eventos de carga de módulos y las operaciones entre procesos, la inyección se vuelve invisible, así que la primera inversión defensiva es asegurarte de que el endpoint y el EDR capturan de verdad estos eventos para la búsqueda de amenazas y las alertas.

Cómo defenderse

La defensa es por capas, porque el objetivo es eliminar las condiciones de las que depende la inyección y hacer que cualquier intento haga ruido:

• Firma de código y políticas de carga. Configura los procesos y la plataforma para que rechacen bibliotecas sin firmar o no confiables, de modo que no se pueda cargar sin más una biblioteca arbitraria del atacante.
• Control de aplicaciones y listas de permitidos. Permite ejecutar solo código aprobado, lo que reduce el conjunto de bibliotecas que pueden llegar a cargarse.
• Mínimo privilegio. Como la inyección suele necesitar acceso suficiente para manipular un proceso objetivo, ejecutar usuarios y servicios con privilegios mínimos reduce el número de objetivos viables y el radio de impacto si se alcanza alguno.
• Parcheo y bastionado. Mantén los sistemas actualizados para cerrar las vulnerabilidades que los atacantes explotan para conseguir, de entrada, el acceso que requiere la inyección.
• EDR con detección de comportamientos. Despliega una detección en el endpoint que vigile la carga de imágenes y los comportamientos entre procesos descritos, y alerta sobre ellos.

Pensar qué procesos atacaría un atacante y qué acceso necesitaría es justo el tipo de razonamiento que formaliza un modelo de amenazas estructurado. La inyección es una técnica entre muchas en el panorama más amplio de cómo se desarrollan realmente las intrusiones; nuestras explicaciones sobre qué es un exploit y qué es un vector de ataque la ponen en contexto.

La conclusión

La inyección de DLL abusa de una capacidad legítima del sistema operativo para ejecutar código del atacante dentro de un proceso de confianza, lo que le da evasión y persistencia. No es magia ni es invisible: suele requerir un acceso que el atacante ya consiguió, y deja rastros detectables en los eventos de carga de imágenes y entre procesos. Los defensores la vencen registrando esos eventos, imponiendo la firma de código y el control de aplicaciones, aplicando el mínimo privilegio, parcheando y alertando sobre los comportamientos que la inyección no puede evitar. Entiende la técnica para reconocerla y desmontarla: ese es todo el sentido de estudiarla.

Preguntas frecuentes

¿Qué es la inyección de DLL? Una técnica que carga y ejecuta el código de una biblioteca de enlace dinámico dentro de otro proceso que ya está en marcha. La capacidad de fondo es legítima y muy usada; el término suele referirse a su abuso malicioso.

¿Por qué la usan los atacantes? Para la evasión y la persistencia: el código dentro de un proceso de confianza hereda su identidad, su reputación y sus permisos, se confunde con lo normal y evita los controles que se basan en el nombre del proceso.

¿Cómo funciona conceptualmente? Haciendo que un proceso objetivo cargue una biblioteca elegida por el atacante y ejecute su código; suele requerir un acceso que el atacante ya tiene, así que normalmente es una fase posterior de la intrusión, no el punto de entrada.

¿Cómo se detecta? Con la monitorización de la carga de imágenes (módulos), vigilando las operaciones de memoria entre procesos y la creación de hilos remotos, y correlacionando comportamientos; todo ello depende de una buena telemetría del endpoint y del EDR.

¿Cómo te defiendes? Imponiendo la firma de código y políticas de carga, usando el control de aplicaciones y las listas de permitidos, aplicando el mínimo privilegio, parcheando los sistemas y desplegando un EDR que alerte sobre los comportamientos que requiere la inyección.