Introduction au Command and Control (C2)

Introduction

Lors de nos missions Red Team, il est fréquent d'avoir besoin de maintenir l'accès à des systèmes compromis pour une durée potentiellement longue. Certaines missions de Red Team peuvent s'étendre sur plusieurs mois. Gérer la persistance sur une ou deux machines n'est pas forcément une tâche ardue, il existe de nombreuses options pour la réaliser. Cependant, la complexité augmente considérablement lorsqu'il s'agit de gérer la persistance sur une vingtaine, une trentaine de machines voire plus…
Ce défi de gestion et de coordination à grande échelle est similaire à celui rencontré par les attaquants exploitant un botnet, un réseau de machines infectées souvent utilisé pour des attaques DDoS. À titre d'exemple, le botnet Rustock, démantelé en 2011, comptait entre 540 000 et 810 000 machines compromises.

Mais alors, comment procéder ? Comment gérer un si grand nombre de machines ? Eh bien, c'est ici qu'intervient le Command and Control (C2/C&C) !
Dans cet article, nous parlerons des Command and Control et de leur fonctionnement. Nous verrons comment établir et gérer les communications entre le serveur C2 et les machines compromises, permettant ainsi de les contrôler à distance, d'exécuter des instructions ou d'extraire des données. A noter de manière bien évidente, l’attaquant à un objectif malveillant ; dans ce cas, on appelle cela “une attaque par Command and Contrôle”. L’opérateur Red team simule une attaque et agit en tant qu'acteur éthique.
Par la suite je vous présenterai un C2 open-source à travers différentes démonstrations.

Qu'est-ce qu'un Command and Control (C2) ?

Un Command and Control (C2) est une infrastructure qui centralise la gestion des communications avec des machines compromises. Au-delà de la simple gestion des communications, un C2 permet d'établir une persistance, c'est-à-dire de maintenir leur accès sur les machines compromises.

Typiquement, une machine infectée enverra, via un implant, des requêtes vers un redirecteur, qui les transférera au serveur C2, permettant à l'implant de récupérer les instructions dictées par les attaquants.

Grâce à un C2, il est possible non seulement d’exécuter des commandes sur les machines compromises, mais aussi de déployer des malwares tels que des ransomwares, ou d'autres types de logiciels malveillants. Ces logiciels peuvent être utilisés pour chiffrer des données, exfiltrer des informations sensibles, ou perturber les opérations de l'organisation cible.
En outre, le C2 permet de coordonner les actions à distance, de manière centralisée et discrète, tout en réagissant aux contre-mesures mises en place par les défenseurs.

Comme vous pouvez le constater, il s'agit d'un élément crucial dans l'organisation d'une cyberattaque avancée ou d'une opération de Red Team.

Il existe une variété de C2 ayant des spécificités et fonctionnalités différentes, certains sont payants tels que Cobalt Strike, tandis que d'autres sont gratuits et open source comme Sliver, Havoc et bien d'autres. Vous pouvez retrouver tous les C2 répertoriés par le projet MatrixC2 sur leur site : https://howto.thec2matrix.com/.

L'infrastructure C2

Bien que les fonctionnalités puissent varier d'un C2 à l'autre, le principe et le fonctionnement demeurent globalement les mêmes. L'objectif principal est de pouvoir gérer et communiquer avec un ensemble de machines compromises, le tout depuis un point central : le serveur de Command and Control.

Tout d'abord nous allons examiner comment les attaquants ou les équipes de Red team structurent leur infrastructure C2. Cette infrastructure se compose de plusieurs éléments distincts :

Le serveur C2 (Short term et Long term)

Le serveur C2 short term est un serveur qui est utilisé pour l'exécution d'actions sur les machines compromises de manière régulière, voire interactive. Les machines compromises consulteront périodiquement ce serveur pour vérifier s'il y a des tâches à réaliser, telles que l'exécution d'une commande spécifique. En raison de la fréquence élevée des communications entre le serveur C2 short term et les machines compromises, le risque de détection par les systèmes de sécurité de la cible augmente significativement.

Le serveur C2 long term quant à lui est conçu pour assurer une présence durable sur les machines compromises. À l'opposé du serveur C2 short term, il n'est pas destiné à réaliser des actions fréquentes sur ces machines, afin de minimiser les risques de détection et de rester le plus discret possible. Cette approche permet notamment de rétablir la connexion avec un serveur C2 short term via le déploiement d'agents, dans le cas où ce dernier aurait été identifié et neutralisé.

Les redirecteurs

Les redirecteurs servent de serveurs intermédiaires pour acheminer les communications vers le serveur C2. L'objectif est de masquer le serveur C2, évitant ainsi son exposition directe et compliquant le travail de traçabilité des communications par les défenseurs tel que la Blue team ou les autorités.

Les redirecteurs peuvent être catégorisé en deux catégories : passifs ou filtrants.

• Un redirecteur passif transfère simplement le trafic de son interface réseau vers une autre interface hôte configurée sans exercer de contrôle sur le trafic entrant redirigé. Ce type de redirecteur a l'avantage d'être rapide et facile à déployer, mais sa simplicité ne gênera probablement pas de manière significative les investigations des défenseurs.

• Quant au redirecteur filtrant, il analyse chaque requête entrante avant de la transférer. Il peut vérifier différents aspects de la requête, tels que l'adresse IP source, le type de requête, les en-têtes HTTP ou le contenu des paquets. Ainsi, on pourrait imaginer un redirecteur qui redirige vers le serveur C2 toutes les requêtes comportant un en-tête spécifique appliqué par l'implant.

Afin de mettre en place des redirecteurs, les attaquants disposent de plusieurs moyens. Parmi ces moyens, on retrouve les cloud provider comme AWS et Azure, qui ont l'avantage d'être largement utilisés par les entreprises. Cela peut compliquer la tâche des solutions de sécurité qui cherchent à différencier le trafic légitime du trafic malveillant, rendant ainsi plus difficile le blocage des attaques. Nous pouvons aussi retrouver Socat , Apache avec le mod_rewrite etc... L'utilisation de serveurs compromis comme redirecteurs est également une pratique courante chez les cybercriminels.

Voici un exemple d'infrastructure C2 que nous pourrions retrouver :

Il existe bien entendu une multitude d'infrastructures C2 possibles. Chaque mission de Red team peut nécessiter une adaptation de l’infrastructure. L’objectif est d’avoir une infrastructure efficace et cohérente avec la mission et la cible. Par exemple, il ne serait pas judicieux d’utiliser des redirecteurs basés sur AWS si la cible utilise exclusivement Azure et inversement.

Maintenant que nous avons exploré l’organisation de l’infrastructure d’un C2, intéressons-nous à la manière dont les attaquants déploient leurs implants afin de prendre le contrôle d’une machine et la gérer via un serveur C2.

Implant

Pour qu’un serveur C2 puisse contrôler et interagir avec une machine compromise, il est nécessaire d’établir une connexion entre la machine compromise et le serveur. Cependant, la présence d’un pare-feu nécessite que la machine compromise initie la connexion. C’est dans ce contexte que les implants ou beacon entrent en jeu.

Un implant peut être considéré comme un type de malware conçu spécifiquement pour un serveur C2, ayant pour but d’établir une connexion entre la machine ciblée et le serveur C2. Selon la méthodologie de l’attaquant, l'implant C2 peut prendre différentes formes en fonction des objectifs des attaquants, du système cible, et des techniques utilisées pour éviter la détection. Cela peut prendre la forme d'un fichier malveillant, d'un script, d'une macro dans un document Word, et bien d'autres.

Comme vous l'aurez compris, l'objectif de l'attaquant est de parvenir à exécuter cet implant sur la machine cible. Pour cela plusieurs méthodes peuvent être utilisées pour déployer cet implant :

• L'exploitation d'une vulnérabilité permettant l'exécution de commande à distance (RCE).
• L'envoi d'un fichier malveillant via une campagne de phishing.
• En faisant du social engineering pour convaincre un utilisateur de télécharger et d'exécuter l'implant.

Il existe une multitude d'autres techniques utilisées par les attaquants afin de parvenir à exécuter leurs implants.

Les communications

Afin de communiquer avec le serveur C2, un implant peut utiliser différents protocoles de communication, chacun ayant ses avantages et ses inconvénients. Parmi ces protocoles, nous retrouvons le protocole DNS qui est largement utilisé par les attaquants car il est essentiel pour le bon fonctionnement de l'infrastructure d'une entreprise et donc difficilement bloquable. Sa variante DoH (DNS over HTTP) permet de chiffrer les requêtes, ajoutant une couche supplémentaire de discrétion. Le protocole HTTPS, qui est omniprésent et se fond facilement dans le trafic légitime, rendant ainsi la détection plus difficile. Nous avons également des protocoles comme mTLS et WireGuard, qui offrent des communications sécurisées et chiffrées. L'utilisation de protocoles custom par les attaquants est également une pratique répandue. Ces protocoles, étant non-standards, sont difficiles à identifier pour les systèmes de détection d'intrusions (IDS) et les dispositifs de sécurité tels que les pare-feux ou les systèmes de prévention d'intrusions (IPS). En raison de leur caractère unique, ils ne génèrent pas d'alertes basées sur les signatures des protocoles courants.

En plus de ces protocoles, les attaquants peuvent s'appuyer sur des services légitimes pour masquer leurs actions. Il a été observé que des services tels que Discord, Google Drive, et bien d'autres sont utilisés par les attaquants pour dissimuler leurs activités malveillantes.

Démonstration avec le C2 Havoc

Maintenant que nous avons vu ce qu’était un C2, place à la pratique !

Pour cette démonstration, nous allons découvrir un C2 open-source nommé Havoc. Havoc est un C2 open-source développé par Paul Ungur (C5pider) .

Comme de nombreux C2, Havoc intègre diverses fonctionnalités. Actuellement, Havoc offre les options suivantes :

• Une interface graphique
• La prise en charge du mode multijoueur, permettant à plusieurs opérateurs de se connecter en même temps au serveur.
• La création de payloads, qui, pour le moment, se limite à la génération de fichiers binaires .exe, de shellcodes, et de DLL.
• La possibilité de communiquer en utilisant le protocole HTTP/HTTPS.
• La prise en charge d'agent custom via son API en Python
• La possibilité d'intégrer des modules pour ajouter des fonctionnalités ainsi que de personnaliser des commandes.

Il est important de rappeler que, au moment de la rédaction de cet article, ce projet est toujours en phase de développement. Nous pouvons donc nous attendre à de nombreuses nouvelles fonctionnalités et modifications à venir.

Havoc est structuré en deux composantes principales : le Teamserver et le Client. Le Teamserver, conçu en Golang, sert de serveur pour orchestrer les connexions des opérateurs, gérer les listeners, créer les implants, recevoir les connexions de ces derniers etc… Quant au client, développé en C++ et Qt, il fournit une interface utilisateur qui permet aux opérateurs de communiquer avec le Teamserver et visualiser les résultats de tâches exécutées par les implants. Il leur permet également d'administrer facilement les implants, d’échanger avec les autres opérateurs, d’administrer les listeners etc…
L'avantage d'une interface graphique permet aux opérateurs de visualiser plus facilement leurs parcs de machines compromises via un affichage en liste ou sous forme de graphe.

Test d'Havoc

Afin de tester Havoc, différentes possibilités s'offrent à nous : soit en l'installant depuis le dépôt GitHub, soit via Exegol qui l'intègre par défaut. Pour ma part, j'ai opté pour compiler le client à partir du code source et le déploiement du serveur via Docker. Toutes les informations nécessaires à son installation sont disponibles sur le dépôt GitHub : https://github.com/HavocFramework/Havoc.

Une fois l'installation terminé, nous allons pouvoir créer notre fichier de profils qui sera utilisé par notre Teamserver lors de son lancement.

Les profils sont gérés dans un fichier de configuration au format Yaotl. Le format Yaotl est un fork du language de configuration HCL. Pour faire simple nous allons simplement récupérer le profile par défaut et y ajouter notre utilisateur :

Teamserver {
            Host = "0.0.0.0"
            Port = 40056
}

Operators {
            user "5pider" {
                        Password = "password1234"
            }
            user "N4STRY" {
                        Password = "password1234"
            }
}

Demon {
            Sleep = 2

            Injection {
                Spawn64 = "C:\\Windows\\System32\\notepad.exe"
                Spawn32 = "C:\\Windows\\SysWOW64\\notepad.exe"

Vous trouverez plus d'information sur les profils sur le Wiki d'Havoc : https://havocframework.com/docs/profiles.

Notre profil terminé, nous sommes prêts à lancer notre Teamserver en mode debug. Pour cela rien de plus simple, il nous suffit d'utiliser la commande suivante en précisant notre fichier de profil :

havoc server --verbose --debug --profile <chemin-de-votre-profil>

Une fois lancé, nous pouvons nous connecter via le client. Pour lancer le client, utilisez la commande :

havoc client

Une fenêtre de connexion s'affichera. Saisissez-y les informations de votre serveur et de votre utilisateur telles qu'indiquées dans le fichier havoc.yaotl.

Une fois connecté, nous obtenons l'accès à l'interface graphique,

Pour nos tests, nous procéderons au déploiement d'un simple implant sur une machine virtuelle Windows afin d'explorer la manière dont nous pouvons contrôler cette machine via l'interface graphique de notre C2.

Débutons par la création d'un Listener. Ce Listener sera utilisé pour capter les communications émanant de notre implant ce qui nous permettra d'établir une connexion avec notre serveur C2. Pour cela, cliquez sur View > Listeners. Cette action affichera le panneau dédié au Listener.

Accédez à ce panneau, puis cliquez sur Add afin de créer un Listener :

Saisissez ensuite les informations requises pour configurer votre Listener. Dans mon exemple, je configure un Listener basique utilisant le protocole HTTPS écoutant sur le port 443.

Après avoir renseigné correctement les informations, cliquez sur Save et assurez-vous que votre nouveau Listener s'affiche bien dans le panneau Listener.

Maintenant que notre Listener est configuré et actif, nous sommes prêts à créer notre implant. Une fois déployé sur la machine cible, cet implant établira une connexion entre la machine compromise et notre Listener.

Pour générer un implant, cliquez sur Attack > Payloads.

Choisissez le Listener auquel associer l'implant. Dans mon cas, je sélectionne mon Listener de test. Je souhaite que mon implant prenne la forme d'un fichier exécutable Windows, donc je choisis Windows Exe dans le menu déroulant pour le format.

Havoc offre la possibilité de spécifier des valeurs pour le Sleep et le Jitter.

Le Sleep désigne une période durant laquelle l'implant suspend toute communication avec le serveur C2 dans le but de minimiser le trafic réseau généré et de compliquer sa détection par les systèmes de surveillance réseau. Cela se fait en espaçant les communications à des intervalles non réguliers.

Le Jitter, quant à lui, introduit une variabilité dans les intervalles de temps entre chaque communication avec le serveur C2, rendant les communications moins prévisibles et plus difficiles à détecter par les mécanismes de sécurité. Ainsi, au lieu d'avoir des communications à des intervalles fixes, l'implant avec Jitter varie ces intervalles aléatoirement dans une plage spécifiée. Par exemple, un implant configuré pour effectuer un check chaque heure avec un Jitter de 30% pourrait faire son check après 42 minutes ou 78 minutes, rendant le schéma de communication moins détectable.

Pour mes tests, n'ayant pas besoin de faire de l’évasion de solution de sécurité, je conserve les valeurs par défaut.

Mon implant a été généré sous le nom demon.exe. Nous allons maintenant pouvoir le déployer sur une machine de test. Pour ce faire, je mets en place un serveur web en utilisant Python et, depuis ma machine test, je télécharge le fichier en exécutant Invoke-WebRequest. Nous pourrions donc imaginer un scénario d’un attaquant, qui après la compromission initiale d'une machine, décide d'établir une persistance en téléchargeant son implant directement depuis la machine compromise.

Sans grande surprise, Microsoft Defender reconnaît notre implant comme un fichier malveillant et procède à sa suppression immédiate. Il est à noter que Havok est largement utilisé, et que les signatures de ses implants sont bien connues des solutions de sécurité.

Afin de garantir le succès de mes tests, je choisis de désactiver Windows Defender. Dans une mission Red team, nous aurions fait en sorte que notre implant ne soit pas détecté par des solutions de sécurité en obfuscant notre implant ou en développant notre implant custom comme le permet Havoc.

De ce fait, je télécharge de nouveau mon implant, cette fois sous le nom de demon2.exe, et je l'exécute.

Il ne me reste plus qu'à retourner sur mon client et à vérifier que mon serveur C2 a reçu une connexion provenant de mon implant.

Comme nous pouvons le voir, j'ai bien reçu une connexion de mon implant. Je peux afficher les machines compromises soit sous forme de tableau, soit sous forme de graphe.

Parmi les informations affichées, on retrouve différentes informations comme le nom de la machine, le nom de l'utilisateur, son système d'exploitation, le PID de notre implant, etc ...

Je vais maintenant pouvoir tester différentes fonctionnalités offertes par Havoc pour manipuler ma machine compromise.

Havoc nous permet d'accéder à un explorateur de fichiers via son interface graphique, facilitant l'exploration de la machine à la recherche de fichiers intéressants.

Pour cela, il suffit de faire un clic droit sur la machine cible, puis sélectionner Explorer > File Explorer.

Un nouveau panneau s'ouvre, affichant un explorateur de fichiers.

Depuis l'interface du C2, nous avons la possibilité de télécharger, par exemple, le fichier secret.txt en effectuant un clic droit sur le fichier concerné et en sélectionnant Download. Ce fichier sera alors téléchargé sur le serveur C2, dans le dossier Havoc/data/loot/*.

Nous pouvons également visualiser la liste des fichiers récupérés dans View > Loot:

Havoc nous permet également d’exécuter des commandes prédéfinies au travers de l'interface graphique. Faite un clic droit sur la machine avec laquelle vous souhaitez interagir :

Cela vous ouvre une console interactive pour exécuter des commandes. Vous pouvez afficher la liste des commandes et des modules disponibles avec la commande help :

Parmi ces commandes, on peut voir que nous avons beaucoup de possibilités, comme prendre une capture d'écran, télécharger un fichier sur le serveur, exécuter des commandes PowerShell, et bien d'autres.

Havoc offre aussi la possibilité de créer nos propres modules, élargissant ainsi nos options par la personnalisation de nos commandes. Le template d'un module est disponible sur le dépôt GitHub.

Conclusion

Les C2 (Command and Control) sont essentiels tant pour les équipes Red team que pour les groupes de cyberattaquants lors de missions de longue durée. Ils facilitent la gestion de nombreuses machines compromises depuis un emplacement central. Le marché propose une vaste gamme de ces outils, certains étant payants tandis que d'autres sont gratuits et open-source. Dans cet article, nous avons testé Havoc, un C2 actuellement en développement, qui propose une interface utilisateur graphique et de nombreuses fonctionnalités. À l'heure actuelle, le projet ne permet pas d'échapper aux systèmes de sécurité tels que Windows Defender. Néanmoins, Havoc offre la possibilité de créer des implants personnalisés, ce qui pourrait s'avérer utile pour des opérations de Red team.