degenerat3 / meteor Goto Github PK

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

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: cera

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

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)

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

This exists:

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

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

Module name: littefoot

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

don't want some rando controlling our bots

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

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.

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

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.

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

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.

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?

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