Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Nuevo ataque de inyección en Windows evade EDR sin WriteProcessMemory


Un investigador de seguridad llamado Two Seven One Three ha revelado un nuevo método de inyección de procesos en Windows denominado console named-pipe injection. Esta técnica permite evadir la detección de los sistemas EDR al evitar el uso de las APIs VirtualAllocEx y WriteProcessMemory, comúnmente asociadas con la inyección de código remoto. En su lugar, el ataque envía el payload a través de la entrada estándar redireccionada de un proceso de consola hijo, reutilizando memoria que Windows ya ha asignado.



Un método de inyección de procesos de Windows revelado por el investigador de seguridad Two Seven One Three esquiva dos APIs estrechamente asociadas con la inyección de código remoto: VirtualAllocEx y WriteProcessMemory.

Denominada inyección de tuberías con nombre (named-pipe) de consola, esta técnica entrega los bytes de la carga útil a través de la entrada estándar redireccionada de un proceso de consola hijo y reutiliza memoria que Windows ya ha poblado. Esto puede interrumpir las detecciones basadas en la secuencia familiar de asignar-escribir-ejecutar.

La inyección de procesos ejecuta código arbitrario dentro de otro proceso, enmascarando potencialmente la actividad detrás de una aplicación legítima.

MITRE ATT&CK rastrea este comportamiento como T1055, mientras que las implementaciones convencionales suelen abrir o crear un objetivo, asignar memoria remota, copiar el código con WriteProcessMemory e iniciar o secuestrar un hilo. Los EDR suelen correlacionar las señales de memoria y de hilos de esta cadena.

 

La inyección de procesos de Windows evade el EDR

Esta variación explota la comunicación entre procesos de Windows en lugar de una escritura directa entre procesos. Un inyector crea un hijo de consola interactiva, como nslookup.exe o netsh.exe, redirecciona su entrada estándar a una tubería y envía la carga útil con WriteFile.

Microsoft documenta que un proceso padre puede asignar el extremo de lectura de una tubería como el controlador de entrada estándar de un hijo y conservar el extremo opuesto para la escritura.

Los bytes existen entonces en el espacio de direcciones del programa de consola mientras este procesa la entrada. La prueba de concepto añade un marcador distintivo al principio de la carga útil, busca esa firma en la memoria accesible y calcula el punto de entrada del shellcode más allá del marcador.

La imagen del código muestra controladores heredables configurados en STARTUPINFO, seguidos de CreateProcess con flujos redireccionados.

Después de localizar el búfer, el inyector llama a VirtualProtectEx para hacer que las páginas comprometidas existentes sean ejecutables. Luego suspende un hilo, cambia su puntero de instrucción y reanuda la ejecución.

Microsoft indica que VirtualProtectEx cambia las protecciones en otro proceso y requiere PROCESS_VM_OPERATION; recomienda suspender un hilo antes de cambiar su contexto.

La demostración del investigador de seguridad Two Seven One Three muestra que se encontraron 368 bytes dentro de una región de nslookup.exe; su protección cambió de lectura-escritura a ejecución-lectura-escritura, y el hilo principal fue redireccionado a esa dirección.

Las cargas útiles deben evitar los bytes de retorno de carro, salto de línea y el sustituto Ctrl+Z, ya que el análisis de la consola puede tratarlos como terminadores de comando o entrada de fin de archivo. El descubrimiento de memoria, los cambios de protección remota y la manipulación del contexto del hilo también siguen siendo detectables.

A diferencia de las investigaciones relacionadas con el envenenamiento de parámetros de procesos, este enfoque no requiere lanzar el proceso hijo suspendido ni colocar datos con un formato inusual en los campos de la línea de comandos o del entorno.

Los investigadores de SensePost, Max Hirschberger y Ogulcan Ugur, afirmaron que su técnica independiente evadió cuatro de los principales productos EDR, pero eso no valida esta implementación más reciente.

Los defensores deberían ir más allá de las alertas de una sola API y correlacionar el comportamiento completo. Las señales de alto valor incluyen un proceso padre inusual que lanza un binario de consola interactiva con controladores redireccionados, escrituras de entrada estándar similares a binarios, escaneo de memoria, una transición remota de VirtualProtectEx a permisos ejecutables y un SetThreadContext seguido de la reanudación.

Los IDs de evento de Sysmon 17 y 18 proporcionan telemetría de tuberías con nombre, aunque las tuberías anónimas de entrada estándar pueden requerir una visibilidad más rica a nivel de endpoint y de controlador.

Los equipos de seguridad deberían establecer una línea base de la automatización de la consola y buscar combinaciones raras en lugar de marcar cada conhost.exe, nslookup.exe u operación de tubería.

La investigación muestra una lección importante para las herramientas de ingeniería que detectan inyecciones de procesos dañinas. Una detección fiable requiere observar cómo se crean los procesos, cómo se comparten los controladores, cómo se protege la memoria y cómo cambian los flujos de control. No debería depender de un solo método.



Fuentes:
https://cybersecuritynews.com/windows-process-injection-evades-edr/

0 comments :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.