Meteor

Eine plattformübergreifende C2/Teamserver, die mehrere Transportprotokolle unterstützt, geschrieben in Go.

Hinweis: Dies befindet sich in der Entwicklung und ist daher nicht wirklich stabil. Die Dokumentation ist ebenfalls mangelhaft, wird aber im Laufe der Zeit schrittweise verbessert.

Allgemeines

Das Meteor-System ist in mehrere Teile unterteilt:

• Core: das Haupt-"Teamserver"-Element, das Aktionen, Hosts, Gruppen usw. verfolgt. Der Core führt eine interne API aus, die "nicht" von außen zugänglich ist, außer von Listenern und anderen Containern im Meteornet (dem Docker-Netzwerk).
• Datenbank – Eine Postgres-Datenbank, die ent-Relationen speichert, die vom Core verwendet werden.
• Client – Wie ein Benutzer mit dem Core interagiert. Der aktuelle Client ist Daddy Tops, aber benutzerdefinierte Optionen können recht einfach erstellt werden.
• Agenten – Die eigentlichen Implantate, die auf infizierten Hosts ausgeführt werden. Agenten sind verantwortlich für die Kommunikation mit ihrem Listener, das Abrufen/Ausführen von Aktionen und das Zurücksenden ihrer Ergebnisse.
• Listener – Das Zwischenglied zwischen der Außenwelt und dem Core. Jedes Kommunikationsprotokoll hat seinen eigenen Listener (z. B. einen für Web, einen für ICMP usw.). Listener verarbeiten die Check-ins der Agenten, senden dann die ausstehenden Aktionen zurück und leiten die Ergebnisse schließlich an den Core weiter. Daddy Tops und Nest befinden sich im selben Verzeichnis wie die anderen Listener, da sie gehostete Container sind, die im Netzwerk lauschen, ihr Zweck unterscheidet sich jedoch geringfügig von den Listenern, die für die Agentenkommunikation verwendet werden.

Installation und Verwendung

Klonen Sie das Repository und erstellen Sie die erforderlichen Compose-Images:

$ git clone https://github.com/degenerat3/meteor
$ cd meteor
$ docker-compose build
<warten Sie geduldig, während Golang und Docker-Dinge passieren>
$ docker-compose up

Meteor ist jetzt gestartet! Beachten Sie, dass Sie Container aus der Compose-Datei entfernen können, wenn Sie sie nicht verwenden. Wenn Sie also nur den Web-Transport nutzen möchten, müssen Sie Petrie/Cera nicht ebenfalls bauen und ausführen. Sobald Ihre Container laufen, führen Sie curl localhost:8888 aus, um sicherzustellen, dass der Core läuft.

An diesem Punkt sollte ein Daddy Tops-Client erstellt sein. Folgen Sie daher den Anweisungen in meteor/docs/daddy_tops.md, um den Client herunterzuladen und mit dem Bau von Agenten zu beginnen!

Protobuf

Nahezu die gesamte Kommunikation im Meteor-System erfolgt mit Protocol Buffers. Der Meteor Communication Standard (MCS) definiert, wie Daten formatiert werden müssen, damit der Core sie verarbeiten kann. Die Listener und Agenten nutzen MCS ebenfalls für den Austausch von Aktionen und Ergebnissen, und Daddy Tops verwendet MCS für alles von der Authentifizierung bis zur Bot- und Gruppenregistrierung. Die MCS-Proto-Datei befindet sich unter meteor/pbuf/mcs.proto.

Aktuelle Transportkanäle

Die aktuellen Agenten/Listener-Paare sind implementiert, mit Plänen für weitere in der Zukunft:

• Petrie: Ein einfacher TCP-Socket
• Little_Foot: Web (HTTP)
• Cera (WIP): ICMP

Die Entwicklung zusätzlicher Listener sollte recht einfach sein, wenn Sie dies wünschen, da die meisten eigentlichen Meteor-Funktionen in die Agent- und Listener-Utils abstrahiert sind. Im Großen und Ganzen ist für die Erstellung eines neuen Listeners lediglich eine zuverlässige Methode zum Senden und Empfangen eines Byte-Strings erforderlich. Von dort aus können die Listener-Utils die Daten an den entsprechenden Core-API-Endpunkt weiterleiten, und die Agent-Utils können die Aktionen ausführen und die richtigen MCS-Payloads erstellen. In dieser Hinsicht gibt es noch viel Verbesserungspotenzial, da ein Teil der Logik und Protobuf-Analyse außerhalb der Utils in den Hauptfunktionen erfolgt.

Nest

Das Nest wird verwendet, um Meteor-Code (derzeit nur Agenten) zu bauen und zu kompilieren, sodass Sie dies nicht selbst tun müssen. Sie können Daddy Tops (oder etwas Eigenes) verwenden, um die erforderlichen Parameter zu senden. Im Gegensatz zum Rest des Projekts besteht die Nest-API aus JSON-Endpunkten anstelle von Protobuf. Dies ermöglicht es, die Binärdateien mit ein paar einfachen curl-Befehlen zu bauen und herunterzuladen, anstatt die Verwendung von Protobuf und komplexerem Code zu erfordern.

Weitere Dokumentation

Die Dokumentation ist derzeit recht begrenzt, wird sich aber im Laufe der Zeit verbessern. Einige Dokumentationen für die Core- und Nest-APIs sowie Anweisungen für Daddy Tops finden Sie in meteor/docs.

HAFTUNGSAUSSCHLUSS: Dieses Tool dient nur zu Bildungszwecken. Manipulieren Sie keine Maschinen, die Ihnen nicht gehören. Die Autoren sind nicht verantwortlich für illegale Nutzungen dieser Codebasis.