Escondidos a plena vista con la inyección de App Domain Manager

Una función poco conocida del framework .NET permite a los atacantes ejecutar código malicioso dentro de aplicaciones confiables firmadas por Microsoft, sin explotar una falla de software ni soltar un payload independiente. Al manipular archivos de configuración o variables de entorno, los adversarios pueden redirigir silenciosamente cómo se inicializan las aplicaciones .NET, lo que permite una ejecución de código encubierta bajo la apariencia de una aplicación .NET legítima.

Durante una sesión en vivo de la serie Huntress Tradecraft Tuesday, los analistas del SOC Casey Smith y John Hammond examinaron esta técnica, conocida como inyección de App Domain Manager, y demostraron cómo encaja perfectamente en el tema más amplio de vivir de la tierra, donde los atacantes abusan de binarios nativos del sistema operativo y de aplicaciones confiables para ejecutar código, mantener persistencia o moverse lateralmente dentro de una red comprometida.

La sesión abrió con historias que dominaban los titulares de noticias, incluido el compromiso dirigido de la cadena de suministro de Notepad++ y la explotación continua de SolarWinds Web Help Desk. En ambos casos, los atacantes se apoyaron en gran medida en herramientas confiables y funciones legítimas del sistema, en lugar de implementaciones evidentes de malware. Ese contexto preparó el terreno para la discusión principal: los atacantes tienen cada vez más éxito al doblegar la lógica de las aplicaciones existentes a su voluntad, en lugar de introducir binarios obviamente maliciosos.

Según Smith, analista sénior de Inteligencia de Amenazas aquí en Huntress, la inyección de App Domain Manager opera dentro del proceso de inicialización del framework .NET. Cuando se inicia una aplicación .NET, el runtime verifica las instrucciones de configuración que definen cómo debe inicializarse el dominio de la aplicación.

Explicó que los desarrolladores usan este mecanismo legítimamente para controlar los límites de aislamiento y el comportamiento de inicio, pero advirtió que la misma función puede reutilizarse con fines maliciosos. Al colocar un archivo de configuración especialmente diseñado junto a un ejecutable objetivo, un atacante puede indicarle al runtime que cargue un ensamblado arbitrario antes de que se ejecute la lógica normal de la aplicación. El código inyectado se ejecuta bajo el contexto de un proceso legítimo, a menudo firmado por Microsoft.

La técnica no depende de los patrones clásicos de inyección de DLL, como la manipulación remota de memoria o el abuso de manejadores de procesos. En cambio, Smith explicó cómo manipular archivos de configuración o variables de entorno para influir en el comportamiento de resolución de ensamblados. Esta distinción importa porque la cadena de ejecución parece natural y el proceso visible es legítimo.

Smith advirtió que la técnica es importante porque funciona contra cualquier aplicación de .NET Framework, aprovecha binarios confiables firmados por Microsoft, y puede usarse para ejecución remota de código o local.

También señaló que la inyección de App Domain Manager representa una técnica de etapa posterior dentro de una cadena de ataque. Si se detecta, indica que el atacante ya cuenta con acceso inicial y un control considerable.

Figura 1: Pasos necesarios para realizar una inyección


La demostración abarcó tres variaciones. La más simple consistió en copiar un ejecutable .NET confiable en un directorio con permisos de escritura, colocar un archivo .exe.config coincidente junto a él, y especificar un ensamblado malicioso para cargar.

Cuando se ejecuta desde ese directorio, la aplicación carga la DLL controlada por el atacante antes de continuar con la ejecución normal. La misma técnica puede extenderse a la carga remota apuntando la configuración a una ruta HTTP o UNC y especificando el token de autenticación de clave pública requerido.

Smith explicó que el runtime descargará y ejecutará el ensamblado remoto, lo que crea un mecanismo para la ejecución remota de código que sigue operando bajo la apariencia de un binario confiable.

Figura 2: Apuntar a una ruta con permisos de escritura en Windows para aprovechar cómo el Microsoft Common Language Runtime normalmente encuentra un binario


Una tercera variación usa variables de entorno en lugar de archivos de configuración. Según la documentación publicada por Microsoft, un atacante puede establecer APPDOMAIN_MANAGER_ASM y APPDOMAIN_MANAGER_TYPE para influir globalmente en el comportamiento de resolución de ensamblados .NET en procesos secundarios. Como las variables de entorno se propagan a los procesos generados, esto permite encadenar múltiples aplicaciones .NET. En la práctica, esto significa que, una vez establecidas las variables, cualquier ejecutable .NET iniciado en esa sesión podría cargar el ensamblado del atacante.

Figura 3: Un pequeño cambio de configuración puede desencadenar ejecución remota


Smith y Hammond señalaron que la técnica ha aparecido en informes públicos, incluidas evaluaciones de equipos rojos de la agencia de ciberseguridad del gobierno de EE. UU., CISA, y en investigaciones de la industria. Se ha utilizado para movimiento lateral y ejecución bajo procesos confiables, particularmente en entornos donde se implementan listas de aplicaciones permitidas o controles de ejecución tradicionales.

Debido a que el binario inicial sigue firmado y es legítimo, los defensores deben apoyarse en artefactos de comportamiento en lugar de una simple detección basada en firmas, explicaron los investigadores.


Figura 4: El aviso de CISA señala esta técnica en evaluaciones públicas de equipos rojos

Desde una perspectiva defensiva, Smith y Hammond destacaron que las rutas de ejecución inusuales son una señal principal a investigar, en particular cuando binarios .NET confiables que normalmente residen en directorios del sistema se inician desde ubicaciones con permisos de escritura o inesperadas.

Los investigadores sugieren que los archivos .exe.config nuevos o modificados también deben tratarse como sospechosos, ya que los atacantes dependen de estos cambios de configuración para redirigir cómo se cargan los ensamblados, y la actividad de carga remota puede dejar artefactos en ubicaciones del perfil de usuario, como la caché de WinInet y la caché de ensamblados .NET bajo AppData.

Para analizar y validar este comportamiento, Smith dijo que los defensores deben habilitar el registro de Fusion para capturar actividad detallada de resolución de ensamblados y usar herramientas como Process Monitor para observar los patrones de acceso a archivos e identificar cuándo se están cargando ensamblados maliciosos.

Figura 5: Los defensores pueden buscar rutas extrañas, DLL sueltas y conexiones de red salientes para encontrar señales de infecciones


Smith también recomienda monitorear las modificaciones de variables de entorno cuando sea posible, y aclara que las variables relacionadas con APPDOMAIN_MANAGER no deberían aparecer normalmente en entornos de producción. Si aparecen, los defensores deben investigar de inmediato, ya que esto probablemente indica que el atacante avanzó bastante en el ciclo de vida de la intrusión.

La conclusión general se alinea con el tema de vivir de la tierra (living-off-the-land). Los atacantes siguen prefiriendo técnicas que dependen de componentes del sistema integrados, funciones de desarrollo legítimas y binarios confiables. La inyección de App Domain Manager no explota una vulnerabilidad; usa una función integrada, tal como fue diseñada.

Como resultado, la prevención depende menos de los parches y más de la visibilidad sobre los cambios de configuración, el contexto de ejecución y el comportamiento de carga de ensamblados, explicó Smith.

Figura 6: Contramedidas


Para los defensores, la alerta temprana radica en entender que muchas aplicaciones .NET (incluido el software de terceros) son susceptibles a esta técnica. Las organizaciones que dependen mucho de herramientas basadas en .NET deberían considerar si su telemetría captura la creación de archivos de configuración, el comportamiento de resolución de ensamblados y la manipulación de variables de entorno. Sin esa visibilidad, esta técnica puede operar silenciosamente dentro de procesos que, por lo demás, son confiables.

Esta sesión de Tradecraft Tuesday reforzó una lección constante: los atacantes muchas veces no necesitan nuevos exploits cuando la funcionalidad existente les da suficiente ventaja. Entender cómo se comportan los sistemas legítimos en condiciones normales es esencial para reconocer cuándo ese comportamiento se redirigió de forma sutil.


¿Te gustó lo que acabas de leer? Únete a nosotros cada mes en Tradecraft Tuesday, nuestro webinar en vivo donde exponemos técnicas de hackers y hablamos de temas técnicos con demostraciones en vivo. ¡Reserva tu lugar ahora!

También te podría interesar