Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
meteor — Un C2/teamserver multiplateforme prenant en charge plusieurs protocoles de transport, écrit en Go. | Kitploit
Outils/GitHubGitHub/degenerat3/meteor
Frameworks de Tests d'IntrusionFrameworks d'ExploitationGénération de PayloadsSécurité WebSécurité RéseauCommandement et ContrôleRed Teaming
GitHubdegenerat3/meteor

meteor

Un C2/teamserver multiplateforme prenant en charge plusieurs protocoles de transport, écrit en Go.

Voir le dépôt
4512il y a 3 ansVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

Meteor

Un C2/teamserver multiplateforme prenant en charge plusieurs protocoles de transport, écrit en Go.

Note : Ceci est en développement et n'est donc pas exactement stable. La documentation est également incomplète, mais elle sera améliorée progressivement au fil du temps.

Général

Le système Meteor est divisé en plusieurs parties :

  • Core : le principal élément "team server" qui suivra les actions, les hôtes, les groupes, etc. Le Core exécute une API interne qui n'est "pas" accessible sauf depuis les listeners et les autres conteneurs sur le Meteornet (le réseau docker).
  • Database - Une base de données Postgres, contenant les relations ent utilisées par le Core
  • Client - Comment un utilisateur interagit avec le core. Le client actuel est Daddy Tops, mais des options personnalisées peuvent être déployées assez facilement
  • Agents - Les implants réels qui seront exécutés sur les hôtes infectés. Les agents sont responsables de communiquer avec leur listener, de récupérer/exécuter les actions et de renvoyer leurs résultats
  • Listeners - L'intermédiaire entre l'extérieur et le Core. Chaque protocole de communication aura son propre listener (par exemple un pour le web, un pour l'ICMP, etc). Les listeners traiteront les check-ins des agents, puis renverront les actions en attente, et enfin transmettront les résultats au Core. Daddy Tops et Nest vivent dans le répertoire avec les autres listeners car ce sont des conteneurs hébergés qui écoutent sur le réseau, mais leur but est légèrement différent de celui des listeners utilisés pour la communication avec les agents.

Installation et utilisation

Clonez le dépôt et construisez les images compose requises :

root@kitploit:~
$ git clone https://github.com/degenerat3/meteor
$ cd meteor
$ docker-compose build
<wait patiently as Golang and docker stuff happens>
$ docker-compose up

Meteor est maintenant opérationnel ! Notez que vous pouvez supprimer les conteneurs du fichier compose si vous ne les utilisez pas. Ainsi, si vous ne voulez utiliser que le transport web, il n'est pas nécessaire de construire et d'exécuter aussi Petrie/Cera. Une fois vos conteneurs en cours d'exécution, faites un curl localhost:8888 pour vérifier que le core fonctionne.

À ce stade, un client Daddy Tops devrait être construit. Suivez donc les instructions dans meteor/docs/daddy_tops.md pour télécharger le client et commencer à créer des agents !

Protobuf

Presque toutes les communications dans le système Meteor sont effectuées avec des protocol buffers. Le Meteor Communication Standard (MCS) définit comment formater les données pour que le Core puisse les traiter. Les listeners et les agents utilisent également MCS pour le transfert des actions et des résultats, et Daddy Tops utilise MCS pour tout, de l'authentification à l'enregistrement des bots et des groupes. Le fichier proto MCS se trouve à meteor/pbuf/mcs.proto.

Canaux de transport actuels

Les paires agent/listener actuelles sont implémentées, avec des projets pour plus à l'avenir :

  • Petrie : un socket TCP de base
  • Little_Foot : Web (HTTP)
  • Cera (WIP) : ICMP

Le développement de listeners supplémentaires devrait être assez simple si vous le souhaitez, car la plupart des fonctionnalités réelles de Meteor sont abstraites dans les utils Agent et Listener. Pour l'essentiel, la seule chose requise pour créer un nouveau listener est un moyen fiable d'envoyer et de recevoir une chaîne d'octets. À partir de là, les utils listener peuvent router les données vers le endpoint API approprié du Core, et les utils agent peuvent exécuter les actions et construire les payloads MCS appropriés. Il reste encore beaucoup d'améliorations à faire à cet égard, car une partie de la logique et de l'analyse protobuf est effectuée en dehors des utils dans les fonctions principales.

Nest

Le Nest est utilisé pour construire et compiler le code de Meteor (actuellement uniquement les agents), afin que vous n'ayez pas à le faire. Vous pouvez utiliser Daddy Tops (ou un outil personnalisé) pour envoyer les paramètres requis. Contrairement au reste du projet, l'API Nest est composée d'endpoints JSON plutôt que de protobuf. Cela permet de construire et de télécharger les binaires avec quelques simples commandes curl, plutôt que d'exiger l'utilisation de protobuf et de code plus compliqué.

Plus de documentation

La documentation est assez limitée pour le moment, mais elle s'améliorera avec le temps. Certains documents pour les API Core et Nest, ainsi que des instructions pour Daddy Tops, sont disponibles dans meteor/docs.

AVERTISSEMENT : Cet outil est uniquement à des fins éducatives. Ne touchez pas aux machines qui ne vous appartiennent pas. Les auteurs ne sont pas responsables des utilisations illicites de cette base de code.

Télécharger l’outil