Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
meteor — Un C2/teamserver multipiattaforma che supporta molteplici protocolli di trasporto, scritto in Go. | Kitploit
Strumenti/GitHubGitHub/degenerat3/meteor
Frameworks per Penetration TestingFramework di ExploitGenerazione di PayloadSicurezza WebSicurezza di ReteCommand and ControlRed Teaming
GitHubdegenerat3/meteor

meteor

Un C2/teamserver multipiattaforma che supporta molteplici protocolli di trasporto, scritto in Go.

Vedi Repository
45123 anni faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Meteor

Un C2/teamserver cross-platform che supporta molteplici protocolli di trasporto, scritto in Go.

Nota: questo progetto è in fase di sviluppo e pertanto non è esattamente stabile. Anche la documentazione è carente, ma verrà migliorata gradualmente nel tempo.

Generale

Il sistema Meteor è suddiviso in diverse parti:

  • Core: il principale elemento "team server" che tiene traccia di azioni, host, gruppi, ecc. Il Core esegue un'API interna che "non" è accessibile se non dai listener e dagli altri container sulla Meteornet (la rete docker).
  • Database - Un database Postgres, che memorizza le relazioni ent usate dal Core
  • Client - Il modo in cui un utente interagisce con il core. Il client attuale è Daddy Tops, ma è possibile creare opzioni personalizzate abbastanza facilmente
  • Agenti - Gli implant effettivi che verranno eseguiti sugli host infetti. Gli agenti sono responsabili della comunicazione con il loro listener, del recupero/esecuzione delle azioni e della restituzione dei risultati
  • Listener - L'intermediario tra soggetti esterni e Core. Ogni protocollo di comunicazione avrà il proprio listener (ad es. uno per il web, uno per ICMP, ecc.). I listener elaborano i check-in degli agenti, quindi inviano le azioni in sospeso, inoltrando infine i risultati al Core. Daddy Tops e Nest si trovano nella directory degli altri listener poiché sono container ospitati che ascoltano sulla rete, ma il loro scopo è leggermente diverso da quello dei listener usati per la comunicazione con gli agenti

Installazione e Utilizzo

Clona il repository e crea le immagini compose richieste:

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 è ora attivo! Nota che puoi rimuovere dal file compose i container che non userai; quindi, se vuoi usare solo il trasporto web, non c'è bisogno di creare ed eseguire anche Petrie/Cera. Una volta che i container sono in esecuzione, esegui una curl a localhost:8888 per assicurarti che il core sia attivo.

A questo punto dovrebbe essere già compilato un client Daddy Tops, quindi segui le istruzioni in meteor/docs/daddy_tops.md per scaricare il client e iniziare a creare agenti!

Protobuf

Quasi tutta la comunicazione nel sistema Meteor avviene tramite protobuf. Lo standard di comunicazione Meteor (MCS) definisce come formattare i dati affinché il Core possa elaborarli. I listener e gli agenti utilizzano anch'essi MCS per il trasferimento di azioni e risultati, e Daddy Tops utilizza MCS per tutto, dall'autenticazione alla registrazione di bot e gruppi. Il file proto MCS si trova in meteor/pbuf/mcs.proto.

Canali di Trasporto Attuali

Le attuali coppie agente/listener sono implementate, con piani per aggiungerne altre in futuro:

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

Sviluppare listener aggiuntivi dovrebbe essere abbastanza semplice, se lo desideri, poiché gran parte della funzionalità effettiva di Meteor è astratta nelle utility Agent e Listener. Nella maggior parte dei casi, l'unica cosa necessaria per creare un nuovo listener è un modo affidabile per inviare e ricevere una stringa di byte. Da lì, le utility del listener possono instradare i dati all'endpoint API Core appropriato, e le utility dell'agente possono eseguire le azioni e costruire i payload MCS corretti. C'è ancora molto da migliorare in questo senso, poiché una parte della logica e del parsing protobuf viene svolta al di fuori delle utility, nelle funzioni principali.

Nest

Il Nest viene utilizzato per compilare il codice Meteor (attualmente solo gli agenti), così non devi farlo tu. Puoi usare Daddy Tops (o qualcosa di personalizzato) per inviare i parametri richiesti. A differenza del resto del progetto, l'API del Nest è composta da endpoint JSON piuttosto che protobuf. Questo perché i binari possono essere compilati e scaricati con pochi semplici comandi curl, invece di richiedere l'uso di protobuf e codice più complicato.

Altri Documenti

La documentazione è piuttosto limitata al momento, ma migliorerà col tempo. Alcuni documenti per le API Core e Nest, oltre alle istruzioni per Daddy Tops, si trovano in meteor/docs.

DISCLAIMER: Questo strumento è solo a scopo educativo. Non armeggiare con macchine che non sono tue. Gli autori non sono responsabili di eventuali usi illeciti di questo codice.

Scarica lo strumento