gmh5225/cs-dropspawn_bofCobaltStrike BOF pour lancer des Beacons en utilisant le détournement de répertoire d'application DLL
DropSpawn est un BOF CobaltStrike utilisé pour lancer des Beacons supplémentaires via une méthode relativement méconnue de détournement de DLL. Fonctionne en x86-x86, x64-x64, et x86-x64/vice versa. À utiliser comme alternative à l'injection de processus.
Les exécutables Windows suivent l'ordre de recherche des DLL lorsqu'ils tentent de charger des DLL dont les chemins absolus n'ont pas été spécifiés :
Le détournement de DLL nécessite généralement que soit :
A. Un utilisateur dispose de droits d'écriture dans un dossier ayant une priorité d'ordre de recherche supérieure à celle où se trouve la véritable DLL
ou
B. Que la DLL en question n'existe nulle part sur le système, auquel cas elle peut être placée dans un dossier accessible en écriture par l'utilisateur dans la variable %PATH% de celui-ci (comme %USERPROFILE%\appdata\local\microsoft\windowsapps).
Ces exigences excluent le détournement de DLL pour les exécutables résidant dans C:\Windows\System32 car presque toutes les DLL que ces exécutables chargent résident également dans System32. Copier un exécutable de System32 vers un emplacement accessible en écriture par l'utilisateur et l'exécuter à partir de là est une option, mais ce n'est pas très sûr du point de vue OPSEC car les binaires de System32 exécutés depuis des emplacements alternatifs sont faciles à identifier.
DropSpawn permet le détournement de DLL à l'aide d'exécutables de System32 (et d'autres trouvés dans des dossiers supplémentaires non accessibles en écriture par l'utilisateur) en usurpant le « répertoire à partir duquel l'application est chargée » vers un répertoire arbitraire spécifié par l'utilisateur.
La version publique de DropSpawn diffère légèrement de la version non publique. La version non publique exploite un générateur de payload propriétaire, rendant l'expérience beaucoup plus fluide pour l'opérateur. La version publique a été légèrement modifiée pour tenir compte du fait que les utilisateurs disposeront de leurs propres méthodes pour générer des payloads compatibles avec le détournement de DLL. Un script Python3 ainsi que le code source d'une DLL de démonstration ont été inclus pour aider les utilisateurs à intégrer et à armer dropspawn.
Identifiez certains exécutables cibles qui tentent de charger des DLL sans spécifier leurs chemins absolus. Vous pouvez le faire en copiant l'exe dans un répertoire accessible en écriture par l'utilisateur et en l'exécutant tout en le surveillant avec Procmon. Dans cet exemple, nous utiliserons WerFault.exe qui réside normalement dans C:\Windows\System32\WerFault.exe
Dans l'exemple ci-dessus, cryptsp.dll, wer.dll, dbghelp.dll et bcrypt.dll sont tous des candidats viables car leurs chemins absolus n'ont pas été spécifiés dans WerFault ; par conséquent, WerFault tentera de les charger depuis son répertoire d'application en premier avant de recourir au reste de l'ordre de recherche des DLL. Notez que cela ne pose généralement pas de problème car le répertoire d'application de WerFault EST System32.
Téléchargez l'une des DLL détournables depuis le système cible.
Ceci est nécessaire afin que nous puissions extraire ses exports et les inclure dans notre DLL de payload. Il est important de récupérer la DLL détournable depuis la même machine sur laquelle vous souhaitez utiliser DropSpawn, car les DLL changent entre les versions de Windows. De plus, si vous exécutez un beacon x86 et souhaitez lancer un beacon x64 à l'aide de DropSpawn, assurez-vous de télécharger la version x64 de la véritable DLL en spécifiant 'C:\windows\sysnative...' au lieu de 'C:\windows\system32...'.
Exécutez generate_dll.py, en passant la DLL téléchargée et l'architecture de payload souhaitée. Generate_dll.py est une version modifiée de ce script. Il analysera la DLL fournie, créera un fichier .def contenant les exports de la DLL, et appellera MingW pour compiler notre DLL de payload de démonstration. Lorsque le processus lancé tente d'appeler une fonction réelle dans la DLL usurpée, notre DLL de payload transmettra l'appel à la véritable DLL située dans System32 afin que le processus hôte ne plante pas.
Appelez dropspawn en utilisant la DLL de payload générée.
dropspawn <payload DLL> <x86|x64> <programme à lancer> [dossier cible accessible en écriture] [parent]
payload DLL - le chemin complet vers la DLL de payload générée.
architecture - l'architecture du processus que vous souhaitez lancer
programme à lancer - le nom/chemin du processus que vous souhaitez lancer. Si ce processus réside dans System32 (ou syswow64), vous pouvez simplement spécifier le nom. Sinon, spécifiez le chemin complet. Vous pouvez également fournir des arguments de ligne de commande au processus. S'il y a des espaces dans le chemin/si vous utilisez des arguments, mettez le tout entre guillemets.
dossier cible accessible en écriture - Optionnel. Si laissé vide, dropspawn tentera d'utiliser le répertoire courant du Beacon. Utilisez des guillemets s'il y a des espaces dans le chemin.
parent - Optionnel. Le nom du processus à utiliser pour l'usurpation de PPID avec le processus nouvellement lancé. Si un processus est spécifié avec plusieurs instances en cours d'exécution à différents niveaux de privilèges (c'est-à-dire svchost.exe), dropspawn tentera d'en identifier une qui peut être utilisée pour l'usurpation de PPID.
Exemple : dropspawn /root/dbgcore.dll x64 "WerFault.exe -u -p 4352 -s 160" C:\users\user\appdata\local\temp explorer.exe
Cela déposera la DLL de payload 'dbgcore.dll' sur le disque à 'c:\users\user\appdata\local\temp\dbgcore.dll' et lancera un processus WerFault.exe x64 avec les arguments de ligne de commande '-u -p 4352 -s 160' et explorer.exe comme processus parent.
Le nettoyage est facile. En incluant la fonction d'auto-suppression dans la DLL de payload déposée sur le disque, celle-ci sera supprimée dès que notre nouveau processus se lancera et la chargera. C'est un changement majeur, car normalement la DLL serait verrouillée sur le disque tant que notre processus qui l'a chargée continue de s'exécuter. Si la technique d'auto-suppression échoue pour une raison quelconque (ou si le processus ne parvient pas à se lancer), DropSpawn tentera de supprimer la DLL de payload du disque et informera l'utilisateur du résultat de l'opération dans tous les cas.
L'injection de processus suit généralement la chaîne ouvrir un processus distant -> allouer de la mémoire distante -> écrire dans la mémoire distante -> exécuter la mémoire distante, avec une option pour lancer un nouveau processus au début au lieu d'utiliser un processus existant. DropSpawn crée uniquement un nouveau processus ; le processus nouvellement lancé est responsable de l'allocation, de l'écriture et de l'exécution du shellcode, ce qui nous permet d'éviter une grande partie des IOC généralement associés à l'injection de processus distants.
Cette technique est bien sûr à la merci de la qualité de vos DLL de payload. Mais nous pouvons examiner ce que Windows voit (cette section suivante utilise la version privée de DropSpawn et le lancement de Beacons).
En ce qui concerne l'Observateur d'événements, tout semble normal :
Dans MDE, il y a très peu de choses à voir.
Exécution de dropspawn :
Journaux MDE :
Avec usurpation de PPID :
Sans usurpation de PPID :
Dans les deux cas, nous voyons notre processus beacon d'origine (également un werfault) déposer dbgcore.dll sur le disque, créer un nouveau processus WerFault.exe, le processus nouvellement lancé charger dbgcore.dll, puis la renommer (supprimer). De manière cruciale, il n'y a pas d'examen supplémentaire de dbgcore.dll qui accompagne souvent les détournements de DLL car nous ne l'écrivons pas dans un emplacement fréquemment détourné, et WerFault.exe (ou tout autre processus que vous choisissez d'utiliser) n'est pas vraiment associé aux détournements de DLL de la même manière que des éléments comme WmiPrvSE.exe.
Il est intéressant de noter que cette opération est presque plus visible avec l'usurpation de PPID que sans. Cela peut toutefois varier selon le produit de sécurité.
Comme mentionné, il est essentiel que les utilisateurs téléchargent les véritables DLL depuis la machine cible sur laquelle ils prévoient d'utiliser DropSpawn. L'utilisation d'une mauvaise version d'une DLL peut entraîner le plantage du processus lancé s'il tente d'appeler une fonction qui n'existe pas.
DropSpawn peut être utilisé avec des exécutables en dehors de System32 ; soyez toutefois averti que des problèmes peuvent survenir si le processus tente de charger des DLL supplémentaires depuis le véritable répertoire d'application du processus. Parce que nous avons usurpé le répertoire d'application ailleurs, si le véritable répertoire d'application n'est pas également accessible via l'ordre de recherche des DLL autrement, le processus plantera/échouera à démarrer car il ne peut pas localiser les DLL essentielles. Testez toujours les détournements potentiels sur des machines de développement avant de les utiliser en production !
Cette recherche a vu le jour alors que j'explorais comment les processus assemblent leur ordre final de recherche des DLL (car il doit être déterminé au moment de l'exécution en raison des exécutables résidant dans différents répertoires, du répertoire courant faisant partie du chemin de recherche, etc.). Mes recherches m'ont conduit à ce message de forum, qui a servi d'origine aux deux API non documentées critiques qui sont au cœur de cette technique.
Ils ont déjà été liés plus haut, mais ce post concernant l'évitement du verrou du chargeur, ce script pour générer un fichier .def pour le proxy DLL, et cette recherche sur l'activation de l'auto-suppression des exécutables en cours d'exécution sont essentiels pour produire des DLL de payload efficaces et armées adaptées à DropSpawn.
Lorsque j'ai publié pour la première fois cette technique sur Twitter, plusieurs autres ont rejoint la conversation et produit des POC. SecurityAndStuff a produit celui-ci, tandis que Snovvcrash a le sien ici
