cobalt-strike/edenUn POC UDRL pour Cobalt Strike construit avec Crystal Palace qui combine la technique de streaming de pages de Raphael Mudge avec une passerelle d'appel modulaire (Draugr)
Eden loader est un PoC UDRL pour Cobalt Strike construit avec Crystal Palace qui combine la technique de streaming de pages de Raphael Mudge avec une porte d'appel modulaire (actuellement une version PIC du BOF de porte d'appel Draugr de Sleepmask-VS).
L'objectif d'Eden loader est de :
Pour plus d'informations sur Eden loader, consultez le blog d'accompagnement.
Remarque : Le but d'Eden est de démontrer l'idée d'utiliser Crystal Palace pour combiner différentes 'unités d'exécution' (c'est-à-dire des capacités) afin de créer des chargeurs personnalisés. Il n'est pas destiné à être un chargeur 'furtif' complet et il lui manque donc volontairement un certain nombre de fonctionnalités OPSEC de base. Par exemple, il utilise de la mémoire RWX et ne suit/masque pas la mémoire du tas de Beacon (et est donc vulnérable à des signatures YARA comme celle-ci).
Remarque : Ce guide de démarrage rapide suppose que vous avez téléchargé/construit Crystal Palace et effectué les étapes suivantes pour configurer votre environnement de développement.
stage {
set sleep_mask "false";
}
WSL dans la racine du dépôt et construisez Eden loader : make clean; make.crystalpalace.jar dans votre répertoire client Cobalt Strike.eden.cna dans le client Cobalt Strike.[14:55:55] [*] Generating Payload: HTTP -- Type: HTTP -- Arch: x64 -- Exit Function: Thread -- System Call: None -- HTTP Library: wininet
[14:55:56] [EDEN] Parsing C:\Users\wb\Desktop\eden\eden.spec...
[14:55:56] [EDEN] Applying eden ldr spec...
[14:55:56] [EDEN] Payload Size: 387060 bytes
[14:55:56] [*] Using user modified reflective DLL! DLLName=resources/beacon.x64.rl0k.dll Arch=x64
Remarque : Eden prend en charge les Beacons HTTP(S), DNS et Pivot.
Une limitation de Crystal Palace au moment de sa sortie est qu'il ne prend actuellement en charge que les fichiers objets construits avec mingw. Si vous essayez d'utiliser un COFF construit avec MSVC ou Clang, vous obtiendrez généralement des erreurs de relocation. Cela peut être frustrant car mingw ne prend pas directement en charge les fichiers pdb, ce qui rend le débogage difficile lors de l'écriture de Tradecraft Windows complexe. Cependant, vous pouvez ajouter l'option -g à votre Makefile pour intégrer les informations de débogage dans les builds exécutables. Cela permet de parcourir votre code dans WinDbg. Pour plus d'informations sur ce processus, il est recommandé de lire le blog suivant de Rastamouse.
Ce dépôt utilise l'approche ci-dessus pour construire une version de débogage de Draugr (draugr.x64.exe) et le code de streaming de pages (guardexec.x64.exe) par défaut. La version de débogage de Draugr n'a aucune dépendance et se compile donc directement, mais si vous souhaitez parcourir/déboguer le code de streaming de pages/des hooks IAT, vous devrez suivre les étapes ci-dessous :
1. Exporter Beacon sans chargeur :
debug/export_beacon_with_no_ldr.cna dans votre client CS et exportez un Beacon brut x64 (HTTP) sans stage dans le répertoire /eden/debug/. Cela exportera une DLL Beacon sans chargeur réflexif que nous pouvons utiliser pour simuler le point d'entrée de guardexec.$ xxd -i ./beacon_x64.bin > debug_beacon.h2. Exporter le stub PIC de Draugr depuis Crystal Palace :
$ ./piclink /<chemin>/eden/debug/draugr.spec x64 /<chemin>/eden/debug/draugr.bin. Cela utilisera Crystal Palace pour produire uniquement le stub PIC de Draugr que nous pouvons utiliser pour simuler le point d'entrée de guardexec.$ xxd -i ./draugr.bin > debug_druagr.h3. Commencer le débogage dans WinDbg
make clean;makeWinDbg et sélectionnez lancer l'exécutable (/eden/bin/draugr.exe ou /eden/bin/guardexec.exe)Open source file et choisissez le fichier .c pertinent (par exemple guardexec.c si vous déboguez le code de streaming de pages).Remarque : Il n'y a pas d'exécutable de débogage pour le chargeur car il n'y a aucun moyen évident de faire exporter des charges utiles de débogage par Crystal Palace pour des choses comme les DLL chiffrées et leurs clés. Par conséquent, il devient non trivial de passer des tampons PIC 'chiffrés' simulés.
Eden loader est principalement destiné à démontrer la puissance de Crystal Palace en combinant différentes 'capacités' pour créer un chargeur novateur. Cette idée pourrait être poussée beaucoup plus loin que dans ce dépôt (par exemple, un chargeur PIC 'statique' entièrement personnalisable via des modules COFF (garde-fous, portes d'appel, obfuscation du sommeil, etc.)).
Eden loader utilise une version PIC de Draugr explicitement afin de pouvoir usurper chaque appel du cycle de vie de Beacon (c'est-à-dire les appels VirtualAlloc / LoadLibrary utilisés pendant le processus de chargement réflexif). Dans certains cas, cela peut être excessif (par exemple, un EDR ne se soucie pas des appels non soutenus à LoadLibrary, etc.) auquel cas cela pourrait être modifié pour utiliser un équivalent PICO (== 'BOF') de Draugr qui est beaucoup plus simple.
Eden loader tente délibérément de garder la 'porte d'appel' découplée du chargeur. C'est par conception pour la modularité, car l'idée est que vous puissiez échanger des BOF BeaconGate/porte d'appel. Ainsi, le code de la porte d'appel Draugr est entièrement autonome dans son propre fichier objet. En remplaçant cela par une autre 'capacité', vous pourriez changer radicalement les TTP d'Eden.
Eden loader n'utilise pas les fonctionnalités plus récentes de Crystal Palace par choix. Par exemple, le mergelib peut être utilisé avec la bibliothèque partagée de Crystal Palace, LibTCG. Cependant, notez que cela signifie que vous perdez la possibilité de déboguer votre code.