Windows carga código ajeno en memoria por sí solo; PhantomBuffer convierte un campo de entrada en una vulnerabilidad para los EDR

Windows carga código ajeno en memoria por sí solo; PhantomBuffer convierte un campo de entrada en una vulnerabilidad para los EDR

En la segunda etapa, el autor recurrió al depurador integrado de Microsoft, capaz de alterar el flujo de ejecución del proceso.

image

Un campo de texto de Windows resultó ser un canal inesperado para la inyección de código ejecutable en un proceso ajeno. El desarrollador bajo el seudónimo Two Seven One Three el 17 de octubre presentó PhantomBuffer, una herramienta experimental para evadir EDR, sistemas de monitorización de amenazas en el equipo. Según el autor, la prueba en un producto de protección no especificado no generó alertas.

Normalmente, la inyección de código requiere asignar memoria en otro proceso, escribir allí la carga útil y ejecutar su código. Las soluciones EDR detectan estas acciones, incluidas las llamadas a VirtualAllocEx y WriteProcessMemory. PhantomBuffer evita ambas llamadas usando mecanismos legítimos de Windows. Un método parecido para ocultar inyección de código antes se mostró mediante DLL.

La base del método es la función SendMessageW, mediante la cual las aplicaciones envían mensajes a ventanas. El mensaje WM_SETTEXT normalmente cambia el texto en un campo de entrada o en el título de una ventana. PhantomBuffer envía así bytes preparados. Windows coloca los datos en la memoria del proceso receptor, y la herramienta luego localiza la región correspondiente mediante ReadProcessMemory, sin invocar WriteProcessMemory.

Para funcionar se necesita un proceso con un elemento gráfico Edit adecuado. La utilidad auxiliar FindTargetWindows busca esas ventanas y, si es necesario, inicia una nueva aplicación. El autor cita Notepad para Windows 10 y Regedit para Windows 11. Luego PhantomBuffer localiza la región con los bytes transmitidos y cambia los permisos de memoria para permitir la ejecución del código allí.

La parte más inusual fue la ejecución de la carga útil. Cambiar directamente el contexto de un hilo mediante SetThreadContext y NtSetContextThread podría ser identificado por las defensas como signo de ataque. Por eso el autor usó el depurador de consola de Microsoft cdb.exe. El depurador se conecta al proceso, mueve el puntero de ejecución del hilo seleccionado a la dirección deseada y se desconecta, dejando que el proceso continúe.

El método tiene limitaciones técnicas. No es posible transmitir sin alteraciones una carga útil que contenga bytes nulos 0x00 a través de WM_SETTEXT, por lo que el autor advierte sobre ese carácter prohibido. Además, no cualquier proceso sirve. Se requiere un elemento gráfico disponible, y Windows limita el envío de mensajes a aplicaciones con un nivel de integridad más alto.

El desarrollador publicó el código fuente de dos utilidades y una demostración en vídeo. Según el autor, PhantomBuffer evitó la detección durante pruebas en EDR de alto nivel, pero no se indican el nombre del producto, las condiciones de las pruebas ni resultados independientes. La publicación describe una prueba de concepto, no una campaña de infección confirmada ni una evasión universal de todas las soluciones de seguridad.

Para detectar acciones similares, el autor recomienda vigilar llamadas inusuales a SendMessageW con WM_SETTEXT y el uso del depurador cdb.exe. Otra señal puede ser el lanzamiento del depurador desde un directorio no estándar. PhantomBuffer demuestra que la ausencia de la operación habitual de escritura en memoria ajena no excluye la inyección de código. Es necesario revisar toda la cadena de comportamiento del proceso.