A cross-platform C2/teamserver supporting multiple transport protocols, written in Go.
A cross-platform C2/teamserver supporting multiple transport protocols, written in Go.
Note: This is in development and as such is not exactly stable. Documentation is also lacking, but will be improved gradually over time.
The Meteor system is split into several parts:
Clone the repository and build the required compose images:
$ git clone https://github.com/degenerat3/meteor
$ cd meteor
$ docker-compose build
<wait patiently as Golang and docker stuff happens>
$ docker-compose up
Meteor is now up! Note that you can remove containers from the compose file if you won't be using them, so if you only want to use the web transport there's no need to also build and run Petrie/Cera. Once your containers are running, curl localhost:8888
to make sure the core is running.
At this point a Daddy Tops client should be built, so follow the instructions in meteor/docs/daddy_tops.md
to download the client and start building agents!
Nearly all communication in the Meteor system is done with protocol buffers. The Meteor Communication Standard (MCS) defines how to format data for the Core to process it. The listeners and agents also utilize MCS for transfer of actions and results, and Daddy Tops utilizes MCS for everything from authentication to bot and group registration. The MCS proto file can be found at meteor/pbuf/mcs.proto
.
The current agent/listener pairs are implemented, with plans for more in the future:
Developing additonal listeners should be simple enough if you so desire, since most of the actual Meteor functionality is abstracted away to Agent and Listener utils. For the most part, the only thing required for creation of a new listener is a reliable way to send and recieve a byte string. From there the listener utils can route the data to the appropriate Core API endpoint, and the agent utils can execute the actions and build the proper MCS payloads. There's still a lot of improvement to be made in this regard, as there's a bit of logic and protobuf parsing done outside the utils in the main functions.
The Nest is used for building and compiling Meteor code (currently only agents), so you don't have to. You can use Daddy Tops (or something custom) to send the required params. Unlike the rest of the project, the Nest API is comprised of JSON endpoints rather than protobuf. This is so the binaries can be built and downloaded with a few simple curl commands, rather than requring use of protbuf and more complicatd code.
Docs are fairly limited right now, but will be improving over time. Some docs for the Core and Nest APIs, as well as instructions for Daddy Tops can be found in meteor/docs
.
DISCLAIMER: This tool is for educational purposes only. Don't diddle machines that aren't yours. The authors are not responsbile for any illicit uses of this codebase.