nccgroup/async-pico-hubAsync PICO Hub es un framework en desarrollo para extender Cobalt Strike con monitoreo de eventos personalizado y BOFs asíncronos en proceso
Async PICOs es un framework para ejecutar archivos Beacon Object File de larga duración y controlados por eventos dentro de un proceso de Beacon de Cobalt Strike. Proporciona ejecución asíncrona, seguimiento de tareas, apagado ordenado y salida asíncrona segura combinando los PICOs de Crystal Palace con un modelo de ejecución en el lado de Beacon.
A diferencia de los BOF asíncronos nativos de Cobalt Strike, los Async PICOs se ejecutan en el proceso de Beacon y pueden activar Beacon para mostrar resultados cuando ocurren eventos.
Los BOF asíncronos nativos de Cobalt Strike resuelven un problema diferente. Los Async PICOs están pensados para tareas de larga duración y controladas por eventos que se ejecutan dentro de Beacon y pueden comunicar resultados de forma segura e inmediata al operador.
Para obtener detalles de implementación y la justificación del diseño, consulte la publicación del blog adjunta:
https://www.nccgroup.com/research/async-picos-and-custom-beacon-wakeups-in-cobalt-strike/
Antes de compilar, se requieren los siguientes componentes:
Una copia local de este repositorio
Una versión compilada de Crystal Palace
Visual Studio con soporte para MSVC y CMake
Tradecraft Garden
Clonar el repositorio
git clone <repo-url>
cd async-pico-hub
Async PICOs dependen de Crystal Palace para la generación de PICO.
Descargue la última versión comprimida de Crystal Palace y compílela siguiendo sus instrucciones. Una vez compilada, coloque los binarios de Crystal Palace dentro de:
pico-tools/crystal-palace/
La estructura esperada debería ser similar a:
pico-tools/
└── crystal-palace/
├── src/
├── lib/
└── ...
Descargue la última versión de Tradecraft Garden y colóquela en
pico-tools/tradecraftgarden
La estructura esperada debería ser similar a:
pico-tools/
└── tradecraftgarden/
├── libtcg/
├── simple_pic/
└── ...
Asegúrese de compilar libtcg y el ejemplo simple_pic para poder compilar Async PICOs.
El proyecto utiliza CMake para simplificar la compilación con MSVC.
Desde la raíz del repositorio, haga clic derecho en la carpeta y seleccione:
Abrir con Visual Studio
Esto carga el proyecto CMake y expone las configuraciones de compilación disponibles.
Las siguientes configuraciones de compilación están disponibles:
x64 Debug
Compila versiones ejecutables locales de PICOs y BOFs para depuración.
Utilice esta configuración cuando depure el comportamiento localmente o recorra el código paso a paso en Visual Studio.
x64 Release
Compila versiones ejecutables locales optimizadas de PICOs y BOFs.
Utilice esta configuración para probar el comportamiento de la versión release fuera de Beacon.
x64 Release Objects
Compila los artefactos de despliegue:
Esta es la configuración utilizada para producir objetos para Cobalt Strike.
Una vez completada la compilación, los artefactos generados se pueden encontrar en:
build/x64-ReleaseObject/obj/
Este directorio contiene los PICOs y BOFs compilados listos para usar.
Async PICOs requieren que Beacon utilice un sleepmask personalizado.
En su perfil malleable, habilite el soporte para un sleepmask personalizado antes de intentar usar Async PICOs.
El script
picos-cna/sleepmask.cnacargaasync-sleepmask, una implementación de referencia mínima utilizada para soportar la salida asíncrona y la coordinación del despertar de Beacon.Este sleepmask es intencionalmente simple y conlleva las limitaciones descritas en la sección Limitaciones. Se proporciona para demostrar el framework y simplificar las pruebas, no como un componente terminado y listo para producción.
Si ya dispone de un sleepmask personalizado con técnicas OPSEC, como manipulación de pila u otras, consulte Modificar su sleepmask existente para convertirlo en un Async sleepmask para integrar el soporte Async PICO en su implementación existente.
Después de compilar el proyecto con la configuración x64 Release Objects, cargue los scripts de Aggressor picos.cna y sleepmask.cna en Cobalt Strike:
Script Manager → Load → picos-cna/picos.cna
Script Manager → Load → picos-cna/sleepmask.cna
Una vez cargados, los Async PICOs se pueden gestionar mediante el comando picos.
Para iniciar un PICO:
picos start [ruta al pico] [argumentos]
Por ejemplo:
picos start C:\temp\MonitorTGT.pico
O con argumentos:
picos start C:\temp\MonitorTGT.pico DOMINIO\cuentadeservicio
Para ver los Async PICOs en ejecución:
picos
Esto muestra las tareas actualmente en ejecución y sus identificadores.
Para detener un Async PICO:
picos stop [id del pico]
Por ejemplo:
picos stop 3
El PICO recibe una señal de detención y sale de forma ordenada después de realizar la limpieza.
Puede encontrar información de uso adicional directamente en Cobalt Strike a través de los menús de ayuda integrados para los comandos picos.
Consulte docs/writing_custom_async_pico.md para obtener más detalles.
Consulte docs/modifying_existing_sleepmask.md para obtener más detalles.
La implementación pública se mantiene intencionalmente simple, sin técnicas evasivas avanzadas. Está pensada como una base para adaptar, no como algo para desplegar sin cambios.
Los Async PICOs se lanzan mediante CreateThread. Esto mantiene el modelo de ejecución simple y fácil de razonar, pero también introduce una superficie de detección. En la implementación pública, el hilo comienza su ejecución desde memoria que no está respaldada por una imagen de módulo, lo que puede ser detectable por productos o heurísticas que inspeccionan las direcciones de inicio de los hilos.
Los usuarios deben evaluar si estrategias alternativas de creación o ejecución de hilos son más apropiadas para su entorno.
El framework depende de un sleepmask modificado para retransmitir la salida asíncrona de vuelta a Beacon y coordinar los eventos de despertar. La implementación incluida aquí es intencionalmente mínima y debe revisarse antes de su uso operativo.
El sleepmask es parte del modelo de ejecución, no meramente una capa de conveniencia. Cualquier cambio en cómo se pone en cola, se vacía o se señala la salida debe evaluarse cuidadosamente para evitar introducir problemas de concurrencia o interacciones no compatibles con los internals de Beacon.
La implementación pública presenta varias limitaciones prácticas que deben entenderse antes de su uso.
Crystal Palace permite que los PICOs usen variables globales, pero la implementación pública utiliza un modelo simple de almacenamiento compartido para guardar el estado global. Como resultado, las variables globales no están aisladas por hilo.
En la práctica, esto significa que ejecutar varios Async PICOs simultáneamente puede requerir cuidados adicionales cuando dependen de globales.
Los Async PICOs dependen de un sleepmask modificado para la salida asíncrona y la coordinación del despertar de Beacon. Por lo tanto, el framework no es completamente autónomo y no puede tratarse como un BOF de reemplazo directo.
El repositorio está diseñado para demostrar un framework y un enfoque de implementación, más que para proporcionar un componente terminado y listo para producción. Los ejemplos incluidos están pensados para ser extendidos, modificados y adaptados a casos de uso individuales.