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 è un framework per eseguire Beacon Object Files a lunga durata e guidati da eventi all'interno di un processo Beacon di Cobalt Strike. Fornisce esecuzione asincrona, tracciamento delle attività, spegnimento controllato e output asincrono sicuro combinando i PICO di Crystal Palace con un modello di esecuzione lato Beacon.
A differenza dei BOF asincroni nativi di Cobalt Strike, gli Async PICO vengono eseguiti nel processo di Beacon e possono riattivare Beacon per mostrare l'output quando si verificano eventi.
I BOF asincroni nativi di Cobalt Strike risolvono un problema diverso. Gli Async PICO sono pensati per attività a lunga durata e guidate da eventi che vengono eseguite all'interno di Beacon e possono comunicare in modo sicuro i risultati immediatamente all'operatore.
Per i dettagli implementativi e la logica progettuale, consulta il post del blog di accompagnamento:
https://www.nccgroup.com/research/async-picos-and-custom-beacon-wakeups-in-cobalt-strike/
Prima di compilare, sono richiesti i seguenti componenti:
Una copia locale di questo repository
Una versione compilata di Crystal Palace
Visual Studio con supporto MSVC e CMake
Tradecraft Garden
Clonare il repository
git clone <repo-url>
cd async-pico-hub
Gli Async PICO si affidano a Crystal Palace per la generazione dei PICO.
Scarica l'ultima release compressa di Crystal Palace e compilala secondo le sue istruzioni. Una volta compilata, posiziona i binari di Crystal Palace all'interno di:
pico-tools/crystal-palace/
La struttura prevista dovrebbe essere simile a:
pico-tools/
└── crystal-palace/
├── src/
├── lib/
└── ...
Scarica l'ultima release di Tradecraft Garden e posizionala in
pico-tools/tradecraftgarden
La struttura prevista dovrebbe essere simile a:
pico-tools/
└── tradecraftgarden/
├── libtcg/
├── simple_pic/
└── ...
Assicurati di compilare libtcg e l'esempio simple_pic per poter compilare gli Async PICO.
Il progetto usa CMake per semplificare la compilazione con MSVC.
Dalla root del repository, fai clic con il tasto destro sulla cartella e seleziona:
Open with Visual Studio
Questo carica il progetto CMake ed espone le configurazioni di compilazione disponibili.
Sono disponibili le seguenti configurazioni di compilazione:
x64 Debug
Compila versioni eseguibili locali di PICO e BOF per il debug.
Usa questa configurazione per eseguire il debug del comportamento localmente o per passo-passo nel codice in Visual Studio.
x64 Release
Compila versioni eseguibili locali ottimizzate di PICO e BOF.
Usa questa configurazione per testare il comportamento della release al di fuori di Beacon.
x64 Release Objects
Compila gli artefatti di distribuzione:
Questa è la configurazione usata per produrre gli oggetti per Cobalt Strike.
Al termine della compilazione, gli artefatti generati si trovano in:
build/x64-ReleaseObject/obj/
Questa directory contiene i PICO e i BOF compilati, pronti per l'uso.
Gli Async PICO richiedono che Beacon usi uno sleepmask personalizzato.
Nel tuo profilo malleable, abilita il supporto per uno sleepmask personalizzato prima di tentare di usare gli Async PICO.
Lo script
picos-cna/sleepmask.cnacaricaasync-sleepmask, un'implementazione di riferimento minimale usata per supportare l'output asincrono e il coordinamento del risveglio di Beacon.Questo sleepmask è volutamente semplice e presenta le limitazioni descritte nella sezione Limitazioni. È fornito per dimostrare il framework e semplificare i test, non come componente finale pronto per la produzione.
Se hai già uno sleepmask personalizzato con tecniche OPSEC, come la manipolazione dello stack o altre, consulta Modificare il tuo sleepmask esistente per trasformarlo in uno sleepmask Async per integrare il supporto Async PICO nella tua implementazione esistente.
Dopo aver compilato il progetto con la configurazione x64 Release Objects, carica gli script Aggressor picos.cna e sleepmask.cna in Cobalt Strike:
Script Manager → Load → picos-cna/picos.cna
Script Manager → Load → picos-cna/sleepmask.cna
Una volta caricati, gli Async PICO possono essere gestiti tramite il comando picos.
Per avviare un PICO:
picos start [path to pico] [arguments]
Ad esempio:
picos start C:\temp\MonitorTGT.pico
Oppure con argomenti:
picos start C:\temp\MonitorTGT.pico DOMAIN\serviceaccount
Per visualizzare gli Async PICO in esecuzione:
picos
Questo mostra le attività attualmente in esecuzione e i loro identificatori.
Per fermare un Async PICO:
picos stop [pico id]
Ad esempio:
picos stop 3
Il PICO riceve un segnale di stop ed esce in modo controllato dopo aver eseguito la pulizia.
Ulteriori informazioni sull'uso sono disponibili direttamente in Cobalt Strike tramite i menu di aiuto integrati per i comandi picos.
Consulta docs/writing_custom_async_pico.md per i dettagli.
Consulta docs/modifying_existing_sleepmask.md per i dettagli.
L'implementazione pubblica è volutamente mantenuta semplice, senza tecniche evasive avanzate. È pensata come base da adattare piuttosto che qualcosa da distribuire senza modifiche.
Gli Async PICO vengono avviati usando CreateThread. Questo mantiene il modello di esecuzione semplice e facile da analizzare, ma introduce anche una superficie di rilevamento. Nell'implementazione pubblica, il thread inizia l'esecuzione da memoria non supportata da un'immagine di modulo, il che può essere rilevato da prodotti o euristiche che ispezionano gli indirizzi di inizio dei thread.
Gli utenti dovrebbero valutare se strategie alternative di creazione o esecuzione dei thread siano più appropriate per il loro ambiente.
Il framework si basa su uno sleepmask modificato per inoltrare l'output asincrono a Beacon e coordinare gli eventi di risveglio. L'implementazione inclusa qui è volutamente minimale e dovrebbe essere revisionata prima dell'uso operativo.
Lo sleepmask fa parte del modello di esecuzione, non è semplicemente un livello di comodità. Qualsiasi modifica al modo in cui l'output viene accodato, svuotato o segnalato dovrebbe essere valutata attentamente per evitare di introdurre problemi di concorrenza o interazioni non supportate con gli interni di Beacon.
L'implementazione pubblica presenta diverse limitazioni pratiche che dovrebbero essere comprese prima del suo utilizzo.
Crystal Palace rende possibile l'uso di variabili globali nei PICO, ma l'implementazione pubblica usa un semplice modello di archiviazione condivisa per lo stato globale. Di conseguenza, le variabili globali non sono isolate per thread.
In pratica, questo significa che eseguire più Async PICO contemporaneamente può richiedere ulteriore attenzione quando dipendono da globali.
Gli Async PICO dipendono da uno sleepmask modificato per l'output asincrono e il coordinamento del risveglio di Beacon. Il framework quindi non è completamente autonomo e non può essere trattato come un BOF sostitutivo immediato.
Il repository è progettato per dimostrare un framework e un approccio implementativo piuttosto che fornire un componente finale pronto per la produzione. Gli esempi inclusi sono pensati per essere estesi, modificati e adattati ai singoli casi d'uso.