kamalx06/tornadoc2Framework C2 basé sur le pull avec dix transports natifs, des gestionnaires multi-profils concurrents, des tâches signées ECDSA et un serveur d'équipe multi-opérateurs avec RBAC et consoles Qt/CLI.
Un C2 basé sur le pull avec dix transports natifs, des gestionnaires multi-profils concurrents et un modèle de menace honnête. L'agent est un binaire Go unique avec chaque propriété comportementale intégrée au moment de la compilation — pas de fichier de configuration à l'exécution, pas de variable d'environnement, pas d'arguments en ligne de commande. Les tâches et les résultats sont signés ECDSA de bout en bout. Les transports sont HTTPS, QUIC/HTTP/3, WebSocket, DNS TXT, DNS-over-HTTPS, ICMP, WireGuard, SMB-pivot, TCP-bind et TCP-reverse.
N'utilisez ce logiciel que sur des systèmes que vous possédez ou sur des systèmes pour lesquels vous détenez une autorisation écrite explicite. Vous êtes seul responsable du respect des lois applicables et des politiques organisationnelles. Les auteurs et contributeurs n'acceptent aucune responsabilité pour une mauvaise utilisation, une perte de données ou des conséquences juridiques découlant de l'utilisation de ce projet.
TornadoC2 est un C2 basé sur le pull. L'agent ne maintient pas de socket active ; il se réveille selon son propre calendrier, se signale au serveur, récupère le travail en file d'attente, l'exécute, puis se rendort. L'opérateur met les commandes en file d'attente ; la balise les récupère lors de son prochain signalement.
Ce design échange l'immédiateté contre la résilience. Un shell live meurt quand le réseau vacille ; un beacon se reconnecte à son prochain réveil et reprend. Un shell live laisse une empreinte persistante sur le réseau ; le schéma de trafic d'un beacon est borné par son intervalle de sommeil. Le framework est conçu pour des engagements de longue durée où l'implant doit survivre aux redémarrages, réessayer en cas d'échec et s'autodétruire selon un calendrier.
L'implant est un binaire Go unique, compilé de manière croisée depuis la machine de l'opérateur. Il n'y a pas de fichier de configuration à l'exécution, pas de variable d'environnement, pas de clé de registre. L'URL de callback, l'intervalle de sommeil, la date de kill, le profil C2 et l'ensemble d'évasion sont tous intégrés au moment de la compilation. Un binaire capturé contient tout ce dont il a besoin pour s'exécuter, et rien que l'opérateur n'y ait mis.
Le framework est compilé pour Linux et Windows aujourd'hui, sur amd64 et arm64. Le support de macOS est sur la liste à court terme, ainsi que des commandes natives supplémentaires et des primitives d'évasion supplémentaires. Le Résumé des capacités ci-dessous liste ce qui est disponible dans la version actuelle.
La console opérateur PySide6. Table des beacons en haut, log et
chat en bas, une seule barre de commandes pour les deux. Le terminal REPL
est l'implémentation de référence ; l'interface graphique est une couche de présentation
au-dessus des mêmes méthodes Client.
J'ai utilisé Sliver pendant un an. C'est un bon outil — cela doit être dit avant toute autre chose, car ce qui suit n'est pas une critique de celui-ci. Le problème était que je ne pouvais pas changer la forme de l'agent. Un beacon Sliver ressemble à un beacon Sliver : une empreinte, un calendrier de polling, une famille de protocoles, une configuration d'exécution qui réside sur le disque. Je pouvais le pointer vers une URL différente. Je ne pouvais pas en faire autre chose. C'est le bon compromis pour des engagements où une forme généraliste convient. C'était le mauvais compromis pour les réseaux sur lesquels je travaillais.
