Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
meteor — Um C2/teamserver multiplataforma que suporta múltiplos protocolos de transporte, escrito em Go. | Kitploit
Ferramentas/GitHubGitHub/degenerat3/meteor
Frameworks de Testes de PenetraçãoFrameworks de ExploraçãoGeração de PayloadsSegurança WebSegurança de RedeComando e ControleRed Teaming
GitHubdegenerat3/meteor

meteor

Um C2/teamserver multiplataforma que suporta múltiplos protocolos de transporte, escrito em Go.

Ver Repositório
45123há 3 anosRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Meteor

Um C2/teamserver multiplataforma com suporte a múltiplos protocolos de transporte, escrito em Go.

Nota: Isto está em desenvolvimento e, como tal, não é exatamente estável. A documentação também é escassa, mas será melhorada gradualmente ao longo do tempo.

Geral

O sistema Meteor é dividido em várias partes:

  • Core: o principal elemento "servidor de equipe" que rastreia ações, hosts, grupos, etc. O Core executa uma API interna que é "não" acessível exceto por listeners e outros contêineres na Meteornet (a rede docker).
  • Database - Um banco de dados Postgres, contendo relações ent que são usadas pelo Core
  • Client - Como um usuário interage com o core. O cliente atual é o Daddy Tops, mas opções personalizadas podem ser criadas com relativa facilidade
  • Agents - Os implantes reais que serão executados nos hosts infectados. Os Agents são responsáveis por se comunicar com seu listener, puxar/executar ações e retornar seus resultados
  • Listeners - O intermediário entre os externos e o Core. Cada protocolo de comunicação terá seu próprio listener (ex: um para web, um para ICMP, etc.). Os Listeners processarão os check-ins dos agentes, depois enviarão de volta as ações pendentes, eventualmente encaminhando os resultados de volta ao Core. Daddy Tops e Nest ficam no diretório com os outros listeners, pois são contêineres hospedados que escutam na rede, mas seu propósito é ligeiramente diferente dos listeners usados para comunicação com os Agent

Instalação e Uso

Clone o repositório e construa as imagens compose necessárias:

root@kitploit:~
$ git clone https://github.com/degenerat3/meteor
$ cd meteor
$ docker-compose build
<aguarde pacientemente enquanto Golang e coisas do docker acontecem>
$ docker-compose up

O Meteor já está no ar! Note que você pode remover contêineres do arquivo compose se não for usá-los, então se você quiser apenas usar o transporte web, não há necessidade de também construir e executar Petrie/Cera. Assim que seus contêineres estiverem em execução, faça curl em localhost:8888 para garantir que o core está funcionando.

Neste ponto, um cliente Daddy Tops deve ter sido construído, então siga as instruções em meteor/docs/daddy_tops.md para baixar o cliente e começar a construir agents!

Protobuf

Quase toda comunicação no sistema Meteor é feita com buffers de protocolo. O Padrão de Comunicação Meteor (MCS) define como formatar dados para o Core processá-los. Os listeners e agents também utilizam MCS para transferência de ações e resultados, e o Daddy Tops utiliza MCS para tudo, desde autenticação até registro de bots e grupos. O arquivo proto do MCS pode ser encontrado em meteor/pbuf/mcs.proto.

Canais de Transporte Atuais

Os pares agente/listener atuais estão implementados, com planos para mais no futuro:

  • Petrie: Um socket TCP básico
  • Little_Foot: Web (HTTP)
  • Cera (WIP): ICMP

Desenvolver listeners adicionais deve ser simples o suficiente se você desejar, já que a maior parte da funcionalidade real do Meteor é abstraída para utilitários de Agent e Listener. Na maioria dos casos, a única coisa necessária para a criação de um novo listener é uma maneira confiável de enviar e receber uma sequência de bytes. A partir daí, os utilitários do listener podem rotear os dados para o endpoint apropriado da API do Core, e os utilitários do agent podem executar as ações e construir as cargas MCS adequadas. Ainda há muito a melhorar nesse aspecto, pois há um pouco de lógica e análise de protobuf feita fora dos utilitários nas funções principais.

Nest

O Nest é usado para construir e compilar código Meteor (atualmente apenas agents), para que você não precise. Você pode usar o Daddy Tops (ou algo personalizado) para enviar os parâmetros necessários. Ao contrário do resto do projeto, a API do Nest é composta por endpoints JSON em vez de protobuf. Isso é para que os binários possam ser construídos e baixados com alguns simples comandos curl, em vez de exigir o uso de protobuf e código mais complicado.

Mais Documentação

A documentação é bastante limitada no momento, mas será melhorada com o tempo. Alguns documentos para as APIs do Core e do Nest, bem como instruções para o Daddy Tops, podem ser encontrados em meteor/docs.

AVISO: Esta ferramenta é apenas para fins educacionais. Não mexa em máquinas que não são suas. Os autores não são responsáveis por quaisquer usos ilícitos deste código-base.

Baixar ferramenta