nccgroup/async-pico-hubAsync PICO Hub is a work-in-progress framework to extend Cobalt Strike with custom event monitoring and in-process Asynchronous BOFs
Async PICOs est un framework pour exécuter des fichiers d'objet Beacon de longue durée, pilotés par événements, dans un processus Beacon Cobalt Strike. Il fournit une exécution asynchrone, le suivi des tâches, un arrêt gracieux et une sortie asynchrone sûre en combinant les PICOs de Crystal Palace avec un modèle d'exécution côté Beacon.
Contrairement aux BOF asynchrones natifs de Cobalt Strike, les Async PICOs s'exécutent dans le processus de Beacon et peuvent réveiller Beacon pour afficher la sortie lorsque des événements se produisent.
Les BOF asynchrones natifs de Cobalt Strike résolvent un problème différent. Les Async PICOs sont destinés à des tâches de longue durée, pilotées par événements, qui s'exécutent dans Beacon et peuvent communiquer immédiatement et en toute sécurité les résultats à l'opérateur.
Pour les détails d'implémentation et la justification de la conception, consultez l'article de blog associé :
https://www.nccgroup.com/research/async-picos-and-custom-beacon-wakeups-in-cobalt-strike/
Avant la compilation, les composants suivants sont requis :
Un checkout local de ce dépôt
Une version compilée de Crystal Palace
Visual Studio avec prise en charge de MSVC et CMake
Tradecraft Garden
Clonez le dépôt
git clone <repo-url>
cd async-pico-hub
Les Async PICOs dépendent de Crystal Palace pour la génération de PICO.
Téléchargez la dernière version compressée de Crystal Palace et compilez-la selon ses instructions. Une fois compilée, placez les binaires de Crystal Palace dans :
pico-tools/crystal-palace/
La structure attendue devrait ressembler à ceci :
pico-tools/
└── crystal-palace/
├── src/
├── lib/
└── ...
Téléchargez la dernière version de Tradecraft Garden et placez-la dans
pico-tools/tradecraftgarden
La structure attendue devrait ressembler à ceci :
pico-tools/
└── tradecraftgarden/
├── libtcg/
├── simple_pic/
└── ...
Assurez-vous de compiler libtcg et l'exemple simple_pic pour pouvoir compiler les Async PICOs.
Le projet utilise CMake pour simplifier la compilation avec MSVC.
Depuis la racine du dépôt, faites un clic droit sur le dossier et sélectionnez :
Open with Visual Studio
Cela charge le projet CMake et expose les configurations de compilation disponibles.
Les configurations de compilation suivantes sont disponibles :
x64 Debug
Compile des versions exécutables locales des PICO et des BOF pour le débogage.
Utilisez cette configuration lorsque vous déboguez un comportement localement ou lorsque vous parcourez le code dans Visual Studio.
x64 Release
Compile des versions exécutables locales optimisées des PICO et des BOF.
Utilisez cette configuration pour tester le comportement de release en dehors de Beacon.
x64 Release Objects
Compile les artefacts de déploiement :
C'est la configuration utilisée pour produire les objets pour Cobalt Strike.
Une fois la compilation terminée, les artefacts générés se trouvent dans :
build/x64-ReleaseObject/obj/
Ce répertoire contient les PICO et les BOF compilés, prêts à l'emploi.
Les Async PICOs nécessitent que Beacon utilise un sleepmask personnalisé.
Dans votre profil malleable, activez la prise en charge d'un sleepmask personnalisé avant d'essayer d'utiliser les Async PICOs.
Le script
picos-cna/sleepmask.cnachargeasync-sleepmask, une implémentation de référence minimale utilisée pour prendre en charge la sortie asynchrone et la coordination du réveil de Beacon.Ce sleepmask est volontairement simple et présente les limitations décrites dans la section Limitations. Il est fourni pour démontrer le framework et simplifier les tests, et non comme un composant final prêt pour la production.
Si vous disposez déjà d'un sleepmask personnalisé avec des techniques OPSEC, telles que la manipulation de la pile ou autres, consultez Modifier votre sleepmask existant pour en faire un Async sleepmask pour intégrer la prise en charge des Async PICO dans votre implémentation existante.
Après avoir compilé le projet avec la configuration x64 Release Objects, chargez les scripts Aggressor picos.cna et sleepmask.cna dans Cobalt Strike :
Script Manager → Load → picos-cna/picos.cna
Script Manager → Load → picos-cna/sleepmask.cna
Une fois chargés, les Async PICOs peuvent être gérés via la commande picos.
Pour démarrer un PICO :
picos start [path to pico] [arguments]
Par exemple :
picos start C:\temp\MonitorTGT.pico
Ou avec des arguments :
picos start C:\temp\MonitorTGT.pico DOMAIN\serviceaccount
Pour afficher les Async PICOs en cours d'exécution :
picos
Cela affiche les tâches en cours d'exécution et leurs identifiants.
Pour arrêter un Async PICO :
picos stop [pico id]
Par exemple :
picos stop 3
Le PICO reçoit un signal d'arrêt et se termine proprement après avoir effectué le nettoyage.
Des informations d'utilisation supplémentaires sont disponibles directement dans Cobalt Strike via les menus d'aide intégrés pour les commandes picos.
Consultez docs/writing_custom_async_pico.md pour plus de détails.
Consultez docs/modifying_existing_sleepmask.md pour plus de détails.
L'implémentation publique est volontairement maintenue simple, sans techniques évasives avancées. Elle est conçue comme une base à adapter plutôt que comme quelque chose à déployer tel quel.
Les Async PICOs sont lancés à l'aide de CreateThread. Cela maintient le modèle d'exécution simple et facile à appréhender, mais introduit également une surface de détection. Dans l'implémentation publique, le thread commence son exécution depuis une mémoire qui n'est pas adossée à une image de module, ce qui peut être détecté par des produits ou des heuristiques qui inspectent les adresses de début des threads.
Les utilisateurs doivent évaluer si des stratégies alternatives de création de threads ou d'exécution sont plus appropriées à leur environnement.
Le framework repose sur un sleepmask modifié pour relayer la sortie asynchrone vers Beacon et coordonner les événements de réveil. L'implémentation incluse ici est volontairement minimale et doit être examinée avant une utilisation opérationnelle.
Le sleepmask fait partie du modèle d'exécution, pas simplement une couche de confort. Toute modification de la façon dont la sortie est mise en file d'attente, vidée ou signalée doit être évaluée avec soin pour éviter d'introduire des problèmes de concurrence ou des interactions non prises en charge avec les composants internes de Beacon.
L'implémentation publique comporte plusieurs limitations pratiques qui doivent être comprises avant son utilisation.
Crystal Palace permet aux PICO d'utiliser des variables globales, mais l'implémentation publique utilise un modèle de stockage partagé simple pour conserver l'état global. Par conséquent, les variables globales ne sont pas isolées par thread.
En pratique, cela signifie que l'exécution simultanée de plusieurs Async PICOs peut nécessiter une attention supplémentaire lorsqu'ils dépendent de variables globales.
Les Async PICOs dépendent d'un sleepmask modifié pour la sortie asynchrone et la coordination du réveil de Beacon. Le framework n'est donc pas entièrement autonome et ne peut pas être traité comme un BOF interchangeable (drop-in).
Le dépôt est conçu pour démontrer un framework et une approche d'implémentation plutôt que pour fournir un composant final prêt pour la production. Les exemples inclus sont destinés à être étendus, modifiés et adaptés à des cas d'utilisation individuels.