PoolParty Injection
La nueva técnica de inyección de procesos llamada "PoolParty", presentada por primera vez en la Black Hat Europe 2023, descubierta por investigadores de SafeBreach y analizada a fondo por Alon Leviev, consiste en un conjunto de ocho técnicas que pueden utilizarse para ejecutar cualquier código malicioso en sistemas de Windows sin ser detectados por los EDRs (Endpoint Detection and Response). Consiste en utilizar los Worker Factories de Windows, los cuales son objetos responsables de gestionar los subprocesos de trabajo (Worker Threads) de los grupos de subprocesos (Thread Pools). Estas técnicas sobrescriben las rutinas de inicio con shellcode malicioso para posteriormente ser ejecutados por los subprocesos de trabajo.
Se le da el nombre de PoolParty debido a que tiene raíz en un componente llamado Windows user-mode thread pools, permitiendo insertar cualquier tipo de work itemen un proceso objetivo del sistema.
Proceso para la inyección:
Como una técnica de evasión usada para ejecutar código arbitrario en un proceso objetivo, el proceso de inyección normalmente consiste en tres conceptos:
- Allocation Primitive: Usado para asignar memoria en el proceso objetivo. Utiliza el proceso VirtualAllocEx().
- Writing Primitive: Usado para la escritura de código malicioso en la memoria asignada. Utiliza el proceso WriteProcessMemory().
- Execution Primitive: Usado para ejecutar el código malicioso. Utiliza el proceso CreateRemoteThread().
Los EDRs conocen los procesos de asignación y de escritura, considerándolos como procesos legítimos del sistema, sin embargo, el proceso de ejecución CreateRemoteThread() es detectable por todos los EDRs modernos.
Windows User-Mode Thread Pools
Al estar buscando un componente ajustable que permita cumplir con los objetivos de la investigación de SafeBreach, los investigadores dieron con Windows User-Mode Thread Pools, que resultaron ser el blanco perfecto debido a:
- Todos los procesos de Windows tienen un grupo de subprocesos por default, lo que significa que abusar de este objeto podría ser aplicable contra todos los procesos de Windows.
- Los objetos de trabajo (Worker Threads) y los grupos de subprocesos (Thread Pools) son representados por estructuras, lo que incrementa las posibilidades de tener una ejecución basada en las asignaciones y escrituras primitivas.
- Son soportados múltiples tipos de objetos de trabajo, lo que significa mayores oportunidades.
- El grupo de subprocesos es un objeto considerablemente complejo, además de utilizar kernel y el user-mode, lo que amplía la superficie de ataque.
Arquitectura:
Un grupo de subprocesos (Thread Pool) consta de tres colas de trabajo distintas, cada una dedicada a un diferente tipo de objeto de trabajo (Work Item). Los subprocesos de trabajo (Worker Threads) operan en las diferentes colas para ejecutar los objetos de trabajo. Por otro lado, el grupo de subprocesos contiene un Worker Factory, que es responsable de administrar los subprocesos de trabajo.
Por lo tanto, existen algunas áreas de oportunidad en el grupo de subprocesos que pueden ser utilizadas para los procesos de inyección:
- Worker Factory
- Task Queue
- I/O completion queue
- Timer queue
Las ocho técnicas, o variantes de Pool Party son las siguientes:
- Variante 1 de Pool Party: Worker Factory Start Routine Overwrite
- El blanco es la rutina de inicio, la cual es básicamente el punto de entrada de los Worker Threads. Por lo general, esta rutina sirve como programador de los grupos de subprocesos (Thread Pools), siendo responsable de la ejecución de los objetos de trabajo. Esta rutina puede ser controlada llamando al Worker Factory Creating System, lo que además aceptará un identificador o handle para el proceso por el cual fue creado el Worker Factory.
- En lugar de crear otro Worker Factory, se puede utilizar la API DuplicateHandle() para obtener acceso a la que pertenezca al proceso objetivo.
- Para obtener la información del Worker Factory, se puede utilizar NtQueryWorkerFactoryInformation(). Esto llamará a _QUERY_WORKERFACTORYINFOCLASS, la cual contiene la clase de información WorkerFactoryBasicInformation, que contiene el valor de la rutina de inicio. Una vez teniendo la rutina de inicio, es posible sobrescribirla con código malicioso.
- Variante 2 de Pool Party: Remote TP_WORK Work Item Insertion
- Se logra atacando los grupos de subprocesos (Thread Pools), con el objetivo de insertar un objeto de trabajo (Work Item) a un proceso objetivo, pues los objetos de trabajo son ejecutados por los subprocesos de trabajo (Worker Threads).
- Se ataca al grupo de subprocesos TP_WORK, el cual contiene una estructura llamada TP_TASK. Este grupo de subprocesos funciona con el work item SubmitThreadpoolWork, que llega desde otra API llamada TpPostTask, la cual es responsable de insertar las tareas a la cola. Lo que hace es insertar una tarea maliciosa a esta API, obteniendo la estructura del grupo de subprocesos con NtQueryInformationWorkerFactory().
- Variante 3 de Pool Party: Remote TP_IO Work Item Insertion
- Los work items asíncronos se introducen a la cola I/O completion, la cual sirve como cola para operaciones de I/O (Input/Output) completadas. El kernel muestra que siete llamadas interactúan con las colas I/O completion, entre las cuales nos interesa el NtSetIoCompletion, pues es una cola para las notificaciones.
- El work item TP_IO tiene como estructura ayudante (helper structure) a TP_DIRECT, por lo que se espera que esta estructura esté en la cola de I/O completion. La función que esta asociada a este work item es CreateThreadpoolIo, y podemos llegar a la funcion TpBindFileToDirect. Llamar a esta función en un archivo resultara en completar la cola del archivo, y mientras este esté vacío y con ninguna operación en la cola, se puede utilizar WriteFile() para insertar el código malicioso.
- Debido a que los work items TP_ALPC, TP_JOB Y TP_WAIT también utilizan la estructura TP_DIRECT, este mismo proceso puede ser utilizado en todos los grupos de subprocesos que sean parte de la cola I/O completion, pero además se puede inyectar una estructura TP_DIRECT maliciosa directamente sin redirigir a un archivo u objeto de Windows, utilizando elNtSetIoCompletion, poniendo en cola una notificación direcamente a la cola de I/O completion. Con esto, también están definidas las otras variantes:
- Variante 4 de Pool Party: Remote TP_WAIT Work Item Insertion
- Variante 5 de Pool Party: Remote TP_ALPC Work Item Insertion
- Variante 6 de Pool Party: Remote TP_JOB Work Item Insertion
- Variante 7 de Pool Party: Remote TP_DIRECT Insertion
- Variante 8 de Pool Party: Remote TP_TIMER Work Item Insertion
- Los work items que son timers operan en un temporizador existente, ubicado en la cola de temporizadores (timer queue). Cuando la API SubmitThreadpoolTimer es llamada, el work item se inserta a la cola, y el temporizador tiene la configuración user-supplied. Cuando el temporizador expira, se llamada a una función para sacarlo de la cola, la cual lo ejecuta.
- Para poner un temporizador en la cola correctamente, primero debemos conocer que los conectores entre un temporizador y una cola de temporizador son los campos de TP_TIMER WindowEndLinks y WindowStartLinks, los cuales funcionan como listas de entrada.
- Yendo a cómo funciona la cadena de llamadas de SetThreadpoolTimer, llegamos a la función que pone en cola a los temporizadores llamada TppEnqueueTimer, la cual inserta los campos WindowStartLinks y WindowEndLinks a la cola WindowStart, y a la cola WindowEnd, respectivamente.
- Al poder poner en la cola el work item timer a la cola de temporizadores, y al poder configurar el temporizador que se ubica en la cola con la API SetThreadpoolTimer, sabemos que una vez que el temporizador expira, se ejecuta la función para sacarlo de la cola. Es así que se puede manipular la cola del temporizador para introducir un work item timer malicioso. Se debe configurar el temporizador que utiliza la cola para que expire. Esto necesita un identificador o handle, el cual puede duplicarse utilizando la API DuplicateHandle.
- Esta variante tiene la particularidad que el atacante puede salir del proceso y borrarlo del sistema, haciendo que el sistema parezca limpio y el código malicioso se ejecute cuando el temporizador expire. Estas técnicas para inyectar código malicioso fueron puestas a prueba con los EDR Palo Alto Cortex, SentinelOne EDR, CrowdStrike Falcon, Microsoft Defender for Endpoint y Cybereason EDR, obteniendo un 100% de tasa de éxito, pues ningún EDR pudo detectar ni prevenir los ataques de PoolParty. Estos resultados ya fueron reportados a los desarrolladores de los EDR y se espera que hagan actualizaciones o parcheos ante este tipo de ataques.
Recomendaciones:
- Aumentar la vigilancia de los procesos y subprocesos inusuales o sospechosos, especialmente aquellos que interactúan como funciones críticas del sistema como VirtualAllocEx() y WriteProcessMemory().
- Mantener los sistemas operativos y el software de seguridad como los EDRs actualizados con los últimos parches.
- Educar al personal sobre las últimas tácticas de ataque y fomentar una cultura de seguridad para prevenir ataques de ingeniería social que podrían facilitar la inyección de código.
- Control de accesos riguroso.
- Protección eficaz de la red.
- Uso de firewalls.
- Uso de soluciones de protección de correo electrónico.
- Uso de Sistemas CDR (Content Disarm and Reconstruction).
- Limitación de privilegios.
Respuesta de los fabricantes de EDR:
- Los desarrolladores de Palo Alto Cortex nos ha confirmado al equipo de Inteligencia de Amenazas Alestra que tienen estas técnicas identificadas y las han resuelto en la versión 8.2.X del agente.
- Según Help Net Security, SentinelOne confirma que están conscientes de la nueva técnica y que sus productos detectan y eliminan esta amenaza de manera efectiva en los dispositivos protegidos por sus soluciones.
- Los desarrolladores de CrowdStrike Falcon están trabajado desde octubre en una nueva versión que tiene un nuevo sensor que provee visibilidad y detección para esta técnica en específico.
- Los investigadores de SafeBreach han notificado a Microsoft, a los desarrolladores de Cybereason EDR y a otros fabricantes de soluciones EDR sobre el problema, pero ninguno de ellos ha hecho ninguna declaración pública aun.
Indicadores de compromiso:
El hecho de que estas técnicas hayan sido descubiertas recientemente por los investigadores de SafeBreach, ocasiona que no haya mucha información sobre el uso indebido de los métodos PoolParty.
No hay evidencias de algún ataque que haya utilizado estas técnicas, por lo que no hay indicadores de compromiso públicos por el momento. El equipo de Alestra se encuentre en constante monitoreo para encontrar indicios relacionados con la amenaza, buscando obtener los indicadores de compromiso.
Conclusiones:
Las nuevas técnicas definidas como “PoolParty” demuestra la evolución continua de las amenazas cibernéticas y la importancia de mantenerse al día con las últimas estrategias de defensa. Aunque los EDRs continúen evolucionando para detectar nuevas técnicas para inyectar código malicioso, los ciberdelincuentes seguirán explorando nuevos e innovadores métodos para el proceso de inyección. La combinación de monitoreo proactivo, actualizaciones regulares, control de acceso estricto y educación en seguridad se perfila como el mejor enfoque para mitigar los riesgos asociados con esta y otras técnicas avanzadas de ataque. Mantenerse informado y preparado es esencial en un panorama de amenazas en constante evolución.
Referencias bibliográficas:
https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/
https://thehackernews.com/2023/12/new-poolparty-process-injection.html
https://gridinsoft.com/blogs/poolparty-injection-techniques/
https://www.helpnetsecurity.com/2023/12/12/pool-party-process-injection/
https://www.blackhat.com/eu23/briefings/schedule/index.html?_gl=1*36b53o*_gcl_au*MTkyMjQyMDc1MS4xNzAyMzA2MzA4#thepool-party-you-will-never-forget-new-process-injection-techniques-using-windows-thread-pools-3544
