external_c2 framework

Framework Python pour une utilisation avec la spécification External C2 de Cobalt Strike, telle que décrite dans la spécification.

L'objectif de conception principal est de fournir une implémentation très modulaire de la spécification external c2, offrant suffisamment d'abstraction pour implémenter facilement des canaux C2 pour Cobalt Strike. Idéalement, tout ce qu'un utilisateur aurait à faire est de créer un module transport, un module encoder, et de remplir un fichier de configuration pour implémenter un nouveau canal.

Configuration du transport Dropbox

Vous devrez effectuer plusieurs modifications de configuration avant de pouvoir commencer. Vous devrez :

Créer un compte Dropbox si ce n'est pas déjà fait (https://www.dropbox.com/)
Générer un jeton d'accès pour votre compte Dropbox (https://www.iperiusbackup.net/en/create-dropbox-app-get-authentication-token/)
Dans builds/client/dbox/dbox_client.py, remplacez token par celui généré à l'étape 2.
Dans builds/server/utils/transports/transport_dbox.py, effectuez les mêmes modifications qu'à l'étape 3.
Compilez votre DLL avec : cd builds/client/dbox && ./compile_dll.sh
Démarrez votre serveur d'équipe Cobalt Strike et connectez-vous avec le client Cobalt Strike
Chargez le script start_externalc2.cna depuis votre client CS.
Copiez ce dépôt sur votre serveur d'équipe, puis exécutez le serveur avec cd builds/server/ && ./dbox_server.py
Distribuez votre exécutable de l'étape 6 à l'hôte et exécutez-le. Vous devriez voir une connexion de retour depuis le serveur d'équipe.

Lien vers la démo vidéo : https://www.youtube.com/watch?v=nTRHSh_uCcA

Architecture

Ce projet se compose de trois parties principales :

Builder (pas encore implémenté)
Client
Server

Builder

Le builder construit dynamiquement les déploiements client et serveur en fonction de la configuration spécifiée. Idéalement, le client pourrait être distribué sous forme d'un fichier compilé unique tel qu'une DLL ou un EXE.

Client

Le client est essentiellement la charge utile qui s'exécute sur le point de terminaison, désignée comme third-party client dans la spécification. La logique du client est principalement statique :

Effectuer les préparatifs nécessaires à l'utilisation du transport
Recevoir le stager
Injecter le stager et ouvrir le handle vers le beacon
Obtenir les métadonnées du beacon
Relayer les métadonnées du beacon au serveur C2 via le transport
Surveiller le transport pour de nouvelles tâches
Relayer les nouvelles tâches au beacon
Relayer les réponses du beacon via le transport
Répéter les étapes 6 à 8.

Les configurations nécessaires pour le transport et les mécanismes d'encodage sont copiées statiquement dans le client. La logique des fonctions de transport et d'encodage est également copiée statiquement depuis leurs modules respectifs.

La logique d'injection de processus est déterminée par le builder.

Server

Le serveur est l'application qui sert d'intermédiaire pour la communication entre le client et le c2 server, désigné comme third-party Client Controller dans la spécification. La logique du serveur est principalement statique, mais prend en charge des sorties verbeuses et de débogage pour faciliter le développement :

Analyser la configuration
Importer le module d'encodage spécifié
Importer le module de transport spécifié
Établir une connexion au serveur c2
Demander un stager au serveur c2
Encoder le stager avec le module encoder
Transporter le stager avec le module transport
Attendre une réponse de métadonnées du client reçue via le transport
Décoder les métadonnées avec le module encoder
Relayer les métadonnées au serveur c2.
Recevoir une nouvelle tâche du serveur c2.
Encoder la nouvelle tâche
Relayer la nouvelle tâche au client via le transport
Recevoir une réponse du client via le transport
Décoder la réponse via le module encoder
Relayer la réponse au serveur c2.
Répéter les étapes 11 à 16

Le choix du module encoder et du module transport importés par le serveur est déterminé à partir des valeurs stockées dans config.py.

Aucun import des modules transport ou encoder non utilisés n'est effectué.

Fonctionnalités partagées entre le client et les modules

Les tableaux suivants décrivent les fonctions partagées entre les modules encoding et transport, et le client. Les fonctions partagées sont essentiellement exactement le même code.

UNE NOTE TRÈS IMPORTANTE : Les données envoyées aux fonctions sendData et recvData du client doivent être des données brutes, tandis que les données envoyées aux fonctions sendData et retrieveData du module de transport doivent déjà être encodées ou décodées selon les besoins.

Module de transport

Fonction Transport	Fonction Client	Description
prepTransport

Module d'encodeur

Fonction Encodeur	Fonction Client	Description
encode	encode	Définit les modifications apportées aux données brutes pour les préparer au transport
decode	decode	Définit les modifications apportées aux données brutes reçues du transport pour être relayées vers leur destination

Comment utiliser ceci

Tout d'abord, déterminez quel module de transport et d'encodage vous souhaitez utiliser. Nous utiliserons transport_gmail et encoder_b64url pour l'exemple suivant.

Ensuite, modifiez server/config.py selon vos besoins, en vous assurant que ENCODER_MODULE et TRANSPORT_MODULE sont correctement configurés et pointent vers vos modules souhaités :

Exemple de config.py

EXTERNAL_C2_ADDR = "127.0.0.1"
EXTERNAL_C2_PORT = "2222"
C2_PIPE_NAME = "foobar"
C2_BLOCK_TIME = 100
C2_ARCH = "x86"
IDLE_TIME = 5
ENCODER_MODULE = "encoder_b64url"
TRANSPORT_MODULE = "transport_gmail"
verbose = False
debug = False

Ensuite, modifiez la section de configuration pour vos modules transport et encoder sélectionnés.

Assurez-vous que la section de configuration de client/mechanism/$mechanism_client.py correspond à toutes les configurations que vous avez définies jusqu'à présent.

Sur la machine exécutant le serveur, exécutez :

python server.py

Pour une sortie plus verbeuse, vous pouvez exécuter :

python server.py -v

Pour une sortie plus verbeuse et des sorties supplémentaires utiles pour le débogage, vous pouvez exécuter :

python server.py -d

Ensuite, exécutez le client sur le point de terminaison ciblé.

Si tout a fonctionné, un nouveau beacon sera enregistré dans la console Cobalt Strike, avec lequel vous pourrez interagir.

FAQ

Pourquoi avoir écrit cela ? : Il n'y avait pas beaucoup d'implémentations publiées de la spécification, et parmi celles qui sont publiées, elles ne sont soit pas dans un langage que je connais, soit n'ont pas la modularité et l'abstraction que je recherchais.

Pourquoi Python 2 ? : Je suis paresseux et il est facile d'y implémenter de nouveaux canaux de transport et d'encodage.

Ton code est nul : Ce n'est pas une question.

Puis-je soumettre de nouveaux modules de transport et/ou d'encodage ? : Oui, s'il vous plaît ! Soumettez une pull request et je serais heureux de la revoir.

Feuille de route

Une abstraction et une modularité similaires seront également implémentées dans le composant client, afin de prendre en charge différentes méthodes d'injection de processus pour la charge utile du beacon et d'autres fonctionnalités prévues à la feuille de route.
Actuellement, la fonctionnalité de builder manque, qui est prévue pour construire dynamiquement les déploiements client et serveur, mais elle est sur la feuille de route.

external_c2_framework

Populaires