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 ist ein Framework zum Ausführen langlebiger, ereignisgesteuerter Beacon Object Files innerhalb eines Cobalt-Strike-Beacon-Prozesses. Es bietet asynchrone Ausführung, Aufgabenverfolgung, kontrolliertes Herunterfahren und sichere asynchrone Ausgabe durch die Kombination von Crystal-Palace-PICOs mit einem Beacon-seitigen Ausführungsmodell.
Im Gegensatz zu den nativen asynchronen BOFs von Cobalt Strike werden Async PICOs im Prozess des Beacons ausgeführt und können das Beacon aufwecken, um Ausgaben darzustellen, wenn Ereignisse auftreten.
Die nativen asynchronen BOFs von Cobalt Strike lösen ein anderes Problem. Async PICOs sind für langlebige, ereignisgesteuerte Aufgaben gedacht, die innerhalb des Beacons ausgeführt werden und Ergebnisse sicher und unmittelbar an den Operator zurückmelden können.
Implementierungsdetails und Designüberlegungen finden Sie im zugehörigen Blogbeitrag:
https://www.nccgroup.com/research/async-picos-and-custom-beacon-wakeups-in-cobalt-strike/
Vor dem Erstellen sind die folgenden Komponenten erforderlich:
Ein lokales Checkout dieses Repositorys
Eine erstellte Version von Crystal Palace
Visual Studio mit MSVC- und CMake-Unterstützung
Tradecraft Garden
Klonen Sie das Repository
Klonen oder kopieren Sie das Repository lokal:
git clone <repo-url>
cd async-pico-hub
Async PICOs basieren auf Crystal Palace zur PICO-Erzeugung.
Laden Sie die neueste komprimierte Version von Crystal Palace herunter und erstellen Sie sie gemäß den Anweisungen. Platzieren Sie die Crystal-Palace-Binärdateien nach dem Erstellen in:
pico-tools/crystal-palace/
Die erwartete Verzeichnisstruktur sollte ähnlich aussehen wie:
pico-tools/
└── crystal-palace/
├── src/
├── lib/
└── ...
Laden Sie die neueste Version von Tradecraft Garden herunter und platzieren Sie sie in
pico-tools/tradecraftgarden
Die erwartete Verzeichnisstruktur sollte ähnlich aussehen wie:
pico-tools/
└── tradecraftgarden/
├── libtcg/
├── simple_pic/
└── ...
Stellen Sie sicher, dass Sie libtcg und das simple_pic-Beispiel erstellen, um Async PICOs bauen zu können.
Das Projekt verwendet CMake, um das Erstellen mit MSVC zu vereinfachen.
Klicken Sie im Repository-Stammverzeichnis mit der rechten Maustaste auf den Ordner und wählen Sie:
Open with Visual Studio
Dadurch wird das CMake-Projekt geladen und die verfügbaren Build-Konfigurationen werden angezeigt.
Die folgenden Build-Konfigurationen sind verfügbar:
x64 Debug
Erstellt lokale ausführbare Versionen von PICOs und BOFs zum Debuggen.
Verwenden Sie diese Konfiguration, wenn Sie Verhalten lokal debuggen oder Code in Visual Studio schrittweise durchgehen möchten.
x64 Release
Erstellt optimierte lokale ausführbare Versionen von PICOs und BOFs.
Verwenden Sie diese Konfiguration, um das Release-Verhalten außerhalb von Beacon zu testen.
x64 Release Objects
Erstellt Bereitstellungsartefakte:
Diese Konfiguration wird verwendet, um Objekte für Cobalt Strike zu erzeugen.
Nach Abschluss des Builds finden Sie die erzeugten Artefakte in:
build/x64-ReleaseObject/obj/
Dieses Verzeichnis enthält die kompilierten PICOs und BOFs, bereit zur Verwendung.
Async PICOs erfordern, dass Beacon ein benutzerdefiniertes Sleepmask verwendet.
Aktivieren Sie in Ihrem Malleable-Profil die Unterstützung für ein benutzerdefiniertes Sleepmask, bevor Sie Async PICOs verwenden.
Das Skript
picos-cna/sleepmask.cnalädtasync-sleepmask, eine minimale Referenzimplementierung zur Unterstützung asynchroner Ausgabe und Beacon-Wake-Koordination.Dieses Sleepmask ist bewusst einfach gehalten und bringt die im Abschnitt Einschränkungen beschriebenen Limitierungen mit sich. Es dient dazu, das Framework zu demonstrieren und das Testen zu vereinfachen, nicht als fertige, produktionsreife Komponente.
Wenn Sie bereits über ein benutzerdefiniertes Sleepmask mit OPSEC-Techniken wie Stack-Manipulation oder anderen verfügen, lesen Sie Modifizieren Ihres bestehenden Sleepmasks zu einem Async-Sleepmask, um die Async-PICO-Unterstützung in Ihre vorhandene Implementierung zu integrieren.
Nachdem Sie das Projekt mit der Konfiguration x64 Release Objects erstellt haben, laden Sie die Aggressor-Skripte picos.cna und sleepmask.cna in Cobalt Strike:
Script Manager → Load → picos-cna/picos.cna
Script Manager → Load → picos-cna/sleepmask.cna
Nach dem Laden können Async PICOs über den Befehl picos verwaltet werden.
So starten Sie ein PICO:
picos start [path to pico] [arguments]
Zum Beispiel:
picos start C:\temp\MonitorTGT.pico
Oder mit Argumenten:
picos start C:\temp\MonitorTGT.pico DOMAIN\serviceaccount
So zeigen Sie laufende Async PICOs an:
picos
Dies zeigt die aktuell laufenden Aufgaben und ihre Kennungen an.
So stoppen Sie ein Async PICO:
picos stop [pico id]
Zum Beispiel:
picos stop 3
Das PICO empfängt ein Stoppsignal und beendet sich nach der Bereinigung ordnungsgemäß.
Weitere Nutzungsinformationen sind direkt in Cobalt Strike über die integrierten Hilfemenüs der picos-Befehle verfügbar.
Details finden Sie in docs/writing_custom_async_pico.md.
Details finden Sie in docs/modifying_existing_sleepmask.md.
Die öffentliche Implementierung ist bewusst einfach gehalten und verzichtet auf fortgeschrittene evasive Techniken. Sie ist als Grundlage zur Anpassung gedacht und nicht dafür, unverändert bereitgestellt zu werden.
Async PICOs werden mit CreateThread gestartet. Dies hält das Ausführungsmodell einfach und nachvollziehbar, führt aber auch eine Erkennungsoberfläche ein. In der öffentlichen Implementierung beginnt der Thread seine Ausführung aus Speicher, der nicht durch ein Modul-Image gestützt wird, was von Produkten oder Heuristiken erkannt werden kann, die Thread-Startadressen untersuchen.
Anwender sollten bewerten, ob alternative Thread-Erstellungs- oder Ausführungsstrategien für ihre Umgebung besser geeignet sind.
Das Framework verlässt sich auf ein modifiziertes Sleepmask, um asynchrone Ausgaben an Beacon zurückzuleiten und Wake-Ereignisse zu koordinieren. Die hier enthaltene Implementierung ist bewusst minimal und sollte vor dem operativen Einsatz überprüft werden.
Das Sleepmask ist Teil des Ausführungsmodells und nicht nur eine Komfortschicht. Jegliche Änderungen daran, wie Ausgaben in die Warteschlange eingereiht, abgerufen oder signalisiert werden, sollten sorgfältig evaluiert werden, um Nebenläufigkeitsprobleme oder nicht unterstützte Interaktionen mit Beacon-Interna zu vermeiden.
Die öffentliche Implementierung bringt mehrere praktische Einschränkungen mit sich, die vor der Verwendung verstanden werden sollten.
Crystal Palace ermöglicht es PICOs, globale Variablen zu verwenden, aber die öffentliche Implementierung nutzt ein einfaches gemeinsames Speichermodell zur Ablage des globalen Zustands. Dadurch sind globale Variablen nicht pro Thread isoliert.
In der Praxis bedeutet dies, dass die gleichzeitige Ausführung mehrerer Async PICOs zusätzliche Sorgfalt erfordern kann, wenn diese von globalen Variablen abhängen.
Async PICOs hängen für asynchrone Ausgabe und Beacon-Wake-Koordination von einem modifizierten Sleepmask ab. Das Framework ist daher nicht vollständig eigenständig und kann nicht als Drop-in-BOF behandelt werden.
Das Repository soll ein Framework und einen Implementierungsansatz demonstrieren und keine fertige, produktionsreife Komponente bereitstellen. Die enthaltenen Beispiele sind dafür gedacht, erweitert, modifiziert und an individuelle Anwendungsfälle angepasst zu werden.