InjectSetConsole: inyección de código sin WriteProcessMemory

Una vuelta de tuerca a la inyección de procesos en WindowsDurante años, la técnica clásica de process injection en Windows ha seguido una ruta casi ri...

Una vuelta de tuerca a la inyección de procesos en Windows

Durante años, la técnica clásica de process injection en Windows ha seguido una ruta casi ritual: abrir el proceso objetivo con OpenProcess, reservar memoria con VirtualAllocEx, escribir el payload con WriteProcessMemory y lanzar un hilo remoto con CreateRemoteThread. Es una cadena conocida, documentada hasta la saciedad y, precisamente por eso, una de las que los EDR llevan años vigilando con lupa. Cualquier administrador de sistemas que gestione servidores Windows o infraestructura híbrida debería tenerla en el radar.

El proyecto InjectSetConsole propone una variante que merece atención: ¿y si no escribimos directamente en la memoria del proceso remoto? La idea es dejar que sea el propio proceso objetivo quien reciba los datos por su entrada estándar y los almacene en memoria por sí mismo. El atacante deja de ser quien escribe en memoria ajena y pasa a ser quien alimenta un canal legítimo.

Cómo funciona: del pipe anónimo al secuestro de hilo

La mecánica se apoya en primitivas perfectamente legítimas del sistema operativo. Primero se crea un anonymous pipe con CreatePipe y se lanza el proceso objetivo con su stdin conectado a uno de los extremos. Mediante STARTUPINFO y la marca STARTF_USESTDHANDLES, se redirigen stdin, stdout y stderr para que el proceso lea de ese canal como si fuera una entrada normal.

A partir de ahí, el atacante introduce por el pipe un bloque de datos que contiene un marcador reconocible seguido del contenido que pretende ejecutar. El problema es que no sabe de antemano dónde terminarán esos bytes: no hay un VirtualAllocEx que le devuelva una dirección remota. La solución pasa por recorrer la memoria del proceso con VirtualQueryEx y ReadProcessMemory hasta localizar la firma introducida.

Cuando la encuentra, ya conoce la dirección donde el proceso ha almacenado los datos. Es una inversión interesante respecto al enfoque tradicional: primero se introducen los datos y después se descubre dónde han quedado. Como esa región no tiene por qué ser ejecutable, se consulta con VirtualQueryEx y se cambian sus permisos con VirtualProtectEx a PAGE_EXECUTE_READWRITE.

El último paso consiste en conseguir que el procesador llegue hasta esa región. En lugar de crear un hilo nuevo, el PoC localiza el hilo principal del proceso y aplica una técnica de thread hijacking para modificar su contexto de ejecución, redirigiendo el registro de instrucción hacia la dirección encontrada. La cadena completa queda reducida a algo bastante elegante: pipe, proceso con stdin redirigido, búsqueda de patrón, cambio de protección y secuestro de hilo.

Por qué esto importa a quien gestiona servidores

La lección no está en haber encontrado una API mágica que sustituya a WriteProcessMemory. Lo relevante es que cambia el canal por el que los datos llegan a la memoria del proceso. En una inyección tradicional, el atacante escribe directamente en memoria remota. Aquí, el proceso víctima hace parte del trabajo: copia internamente lo que recibe por su entrada estándar.

Esto tiene consecuencias prácticas para la defensa. Una detección basada únicamente en la tríada VirtualAllocEx + WriteProcessMemory + CreateRemoteThread puede dejar pasar esta variante. Sin embargo, la cadena de comportamiento sigue siendo visible si se observa el conjunto:

Creación de procesos con stdin redirigido a un pipe anónimo.
Comunicación inusual mediante tuberías entre procesos.
Inspección de memoria remota con VirtualQueryEx y ReadProcessMemory.
Cambios de protección de memoria en regiones de otro proceso.
Manipulación del contexto de un hilo existente.

Por eso quizá sea más correcto hablar de cambio de superficie de detección que de evasión completa. La pregunta defensiva ya no debería ser solo si se ha usado WriteProcessMemory, sino cómo han aparecido esos datos en memoria y qué proceso los ha colocado ahí.

De la teoría a la protección real de tus servidores

En ALMC trabajamos con pymes, empresas de hosting y administradores que gestionan servidores propios en Barcelona, Lleida, Tarragona o Girona. La realidad es que la mayoría de incidentes no llegan por técnicas tan sofisticadas como esta, sino por accesos no controlados, fuerza bruta contra servicios expuestos y credenciales débiles. Aun así, conviene tener una capa de defensa que reduzca la superficie de ataque antes de que el atacante llegue a plantearse un process injection.

Ahí encaja Abuse Shield, nuestro servicio de protección de servidores. Centraliza en un único panel lo que normalmente se dispersa en scripts sueltos por cada máquina: bloqueo automático de IPs maliciosas, fail2ban gestionado de forma unificada en múltiples servidores y un feed de reputación compartido entre todos ellos. Si una IP ataca una máquina, el resto de tu infraestructura lo sabe al instante y puede bloquearla antes de que lo intente.

La combinación es sensata: entender cómo evolucionan las técnicas de intrusión, como esta variante de inyección, y disponer de una capa operativa que mantenga a raya lo cotidiano. La seguridad de servidores no se improvisa; se construye con visibilidad, automatización y una buena higiene de red. Y en un entorno donde las amenazas cambian de forma, tener la reputación de IP compartida entre todos tus servidores marca la diferencia entre reaccionar tarde y bloquear a tiempo.

Relacionado

¿Tus servidores bajo ataque constante?

Centraliza fail2ban y la reputación de IPs en todos tus servidores. Descubre Abuse Shield de ALMC. Contáctanos para una demo personalizada.

Resultados sin salir de la página.