
Un conduit de commande et de contrôle simplifié basé sur FTP pour interconnecter des systèmes distants.
SharpFtpC2 est un petit projet expérimental visant à explorer la possibilité d'utiliser FTP(S) pour relayer des commandes et des réponses entre deux ordinateurs distants. Il utilise le protocole FTP comme un tunnel de fortune à travers lequel les ordinateurs, agissant tous deux comme des clients connectés à un serveur FTP, peuvent communiquer. Un système simple de gestion de session est utilisé pour suivre l'échange de requêtes et de réponses.
SharpFtpC2 utilise un système de gestion de session basique. Bien qu'assez élémentaire, il permet de maintenir les communications synchronisées et liées, ce qui est essentiel pour les allers-retours entre les systèmes distants.
Il est à noter que ce projet peut être facilement porté en utilisant des systèmes de contrôle de version tels que git, svn ou des protocoles similaires.
Si vous vous intéressez aux détails techniques de la communication réseau, ou si vous souhaitez simplement bricoler avec C# et .NET Core, SharpFtpC2 pourrait être un point de départ intrigant. N'attendez pas un bijou poli, mais peut-être, juste peut-être, apprendrez-vous quelque chose d'intéressant en y trifouillant.
SharpFtpC2 est un projet expérimental créé pour une exploration éducative de l'utilisation de FTP(S) comme canal de communication entre deux ordinateurs distants. Il est crucial de comprendre que le projet est conçu comme une ressource d'apprentissage pour les personnes intéressées par la communication réseau, C#, la simulation d'adversaires, la Red Team et les Malwares. En tant que créateur, j'encourage les utilisateurs à ne pas demander de fonctionnalités supplémentaires ni à utiliser ce projet à des fins d'armement ou malveillantes. L'intention fondamentale est éducative, et les utilisateurs sont tenus d'interagir avec le contenu de manière responsable et éthique.
SharpFtpC2 est né du désir de contribuer au Projet Unprotect, en particulier à sa catégorie Network Evasion.
L'idée d'utiliser FTP comme « tunnel » a des racines profondes. En fait, elle rappelle de bons souvenirs datant d'environ 2005, à l'époque où je faisais mes premiers pas dans le monde de la programmation. À l'époque, j'avais croisé un individu français remarquablement créatif qui se faisait appeler BlasterWar. Il avait conçu un projet nommé BlasterX qui, bien que perdu dans le temps, était plutôt avant-gardiste pour son époque.
L'ingéniosité de BlasterWar dans son projet était de proposer une alternative à la connexion inverse classique, où l'agent devait établir une connexion de retour vers le dispositif de contrôle ou de piratage.
Au lieu de cela, BlasterWar a choisi d'utiliser FTP (File Transfer Protocol) comme support alternatif et a construit un outil d'accès à distance complet autour de celui-ci. L'outil incluait des fonctionnalités telles que la capture d'écran, l'enregistrement des frappes et la gestion du système, le tout transmis via le tunnel FTP. À l'époque, FTP était très populaire et une multitude de sites web proposaient des serveurs FTP gratuits au public. Cela en faisait une alternative idéale aux connexions inverses ou directes, qui nécessitaient la redirection de ports. De plus, cela offrait une couche supplémentaire d'obscurcissement pour le contrôle et la commande (C2), car l'adresse IP de la machine du pirate n'était pas directement exposée.
Aujourd'hui, utiliser FTP comme tunnel n'est pas un concept nouveau, car quelques frameworks de Command and Control (C2) ont adopté ce protocole. Cependant, l'utilisation de FTP de cette manière comporte des risques. Notamment, la transmission des identifiants en clair sur le réseau par FTP, combinée à la nécessité pour les deux parties de posséder ces identifiants, le rend vulnérable à une multitude d'attaques. Bien que les serveurs FTP aient fait des progrès pour résoudre ces problèmes de sécurité en adoptant de plus en plus FTPS, qui intègre le chiffrement SSL/TLS, cette adaptation n'a pas été une panacée pour tous les risques inhérents.
Avec un peu d'ingéniosité et en s'inspirant des protocoles existants, il est possible de résoudre un nombre substantiel des risques existants.
Pour compiler ce projet, vous avez besoin de deux composants : Visual Studio et une dépendance pour le contrôleur nommée CommandLineUtils.
Comme ce projet utilise .NET Core, il peut être compilé pour différentes plates-formes facilement, sans nécessiter de modifications de code. Cependant, vous pouvez avoir besoin d'implémenter certaines fonctionnalités spécifiques à la plate-forme cible.
Pour commencer à tester ce projet rapidement, je recommande d'utiliser Docker avec l'image stilliard/pure-ftpd. Cette image prend en charge une gamme d'options, vous permettant de configurer rapidement votre propre serveur FTP avec facilité.
docker pull stilliard/pure-ftpd
docker run -d --name ftpd_server -p 21:21 -p 30000-30009:30000-30009 -e "PUBLICHOST: 127.0.0.1" -e "ADDED_FLAGS=-E -A -X -x" -e FTP_USER_NAME=dark -e FTP_USER_PASS=toor -e FTP_USER_HOME=/home/dark stilliard/pure-ftpd
docker run -d --name ftpd_server -p 21:21 -p 30000-30009:30000-30009 -e "PUBLICHOST: 127.0.0.1" -e "ADDED_FLAGS=-E -A -X -x --tls=2" -e FTP_USER_NAME=dark -e FTP_USER_PASS=toor -e FTP_USER_HOME=/home/dark -e "TLS_CN=localhost" -e "TLS_ORG=maislaf" -e "TLS_C=FR" stilliard/pure-ftpd
N'hésitez pas à personnaliser les paramètres selon vos besoins. Cependant, je vous déconseille fortement d'exposer ce serveur FTP de test aux réseaux locaux ou publics. Il serait plus prudent de limiter l'exposition de ce conteneur uniquement à votre machine hôte.
L'option ADDED_FLAGS vous permet d'affiner le serveur pure-ftpd. Les explications de tous les drapeaux se trouvent ici.
Certains drapeaux peuvent nécessiter des modifications du fonctionnement du protocole C2. Par exemple, si vous utilisez l'option -K pour conserver tous les fichiers, la possibilité de supprimer des fichiers via FTP sera désactivée. Étant donné que le protocole C2 actuel utilise cette fonctionnalité, vous pourriez avoir besoin d'envisager des approches alternatives, telles que le renommage ou le déplacement de fichiers.
Pour garantir l'intégrité et la confidentialité de toutes les communications entre les agents et le C2, le chiffrement a été intégré de manière transparente dans le protocole de communication, utilisant à la fois les algorithmes RSA et AES-GCM 256 bits. L'objectif principal de cette fonctionnalité est d'empêcher la possibilité qu'un serveur FTP compromis délivre des commandes malveillantes. En utilisant le chiffrement, l'injection de commandes est rendue impossible sans accès à la clé publique de l'agent. De même, il n'est pas possible d'injecter de fausses réponses d'agent sans posséder la clé publique du C2.
Pour faciliter le processus de génération de vos propres paires de clés (une paire de clés pour l'agent et une pour le C2), j'ai inclus un outil tiers appelé RSAKeyHelper. Chaque fois que vous exécutez l'application, elle vous présentera une nouvelle paire de clés publique et privée fraîchement générée, qui peut être utilisée dans le programme si vous choisissez d'utiliser le chiffrement.

Pour vérifier que tout fonctionne comme prévu, j'ai également intégré une fonctionnalité dans le même outil qui vous permet de tester le chiffrement de chaînes.

La publication de la version « 3.0 Final » marque le point culminant de ce projet. Je n'ajouterai aucune autre fonctionnalité ; l'objectif de ce PoC était de démontrer la création d'un C2 fiable et sécurisé utilisant FTP(S). Vous êtes encouragé à développer votre propre version avec des fonctionnalités adaptées. À titre d'exercice, vous pourriez envisager d'implémenter le multitâche pour éviter que l'application ne se bloque lors de tâches de longue durée.
Je continuerai cependant à fournir un support pour le projet en ce qui concerne la résolution d'éventuels bogues ou opportunités d'optimisation.
(Liste des agents)

(Exécuter une commande sur l'agent actif (contexte))

(Fenêtre de débogage de la console de l'agent avec confirmation utilisateur pour action dangereuse)
