degenerat3 / meteor Goto Github PK

have bots/hosts keep track of last callback, would be updated by the '/get/command' endpoint

Currently backend stuff just goes to standard error/out. Each app/module should have logging built in and write those logs to somewhere in the container. The container will have a mapped drive, so the format on the docker host would have a log directory (Ex: /var/log/metor/) and each module would write to a directory inside meteor.

it's showing the response to the web request (I think) which is success, rather than the actual command output.

It's a PITA to manually edit source and recompile golang. Make a build script or something that sets the important variables and compiles the client.

This will be updated as we go:

• /register/bot
• /register/host
• /register/group
• /list/bots
• /list/hosts
• /list/groups
• /list/actions
• /add/command/single
• /add/command/group
• /add/actionresult
• /get/command
• /get/actionresult
• /dumpdb
• /cleardb

Probably more as we decide we need them?

don't want some rando controlling our bots

This exists:

https://github.com/RITRedteam/Topology-Generator/

Should read from that, rather than having a proprietary topology form (or both)

module name: cera

c2 over ICMP. No idea what this will look like yet...

module name: daddytops <-NON NEGOTIABLE

Make a simple CLI tool that can interact with commander endpoints (add commands, create groups, etc). The module would simply middle-man those requests to the Core API

Module name: littefoot

Basic web c2. Module only has to middle-man command requests and result posts

GetCommand shouldn't require hostname. UUID is a required parameter, and hostid can be determined by that (its foreign key of bot table).

Collection of docs should include:

• general structure of project, explain docker, etc (the readme?)
• setup instructions (should just be some simple docker commands)
• API Documentation (endpoints/parameters/methods, spec for modules, etc)
• Command execution explanation (modes, arguments, etc)
• Docs for each module (up to developer of module)

There's some that are just plain "Error," some are [True, "None"]... make them all the same format.

Add option to MAD for file transfer, args would be target/dest path

MAD has an unimplemented spawn reverse shell option. This should be done by executing payload in memory. Linux can utilize memfdcreate syscall for this.

Have hosts be able to be a member of more than one group. Possible implementation: make a new table called HostGroupMap or something that has a series of rows with hostid and groupid as values for each row. Would have to change how the "groupaction" endpoint works, but thats ok.