C2 Docker Containers
All C2 profiles are backed by a Docker container or intermediary layer of some sort.
What's the goal of the container?
What do the C2 docker containers do? Why are things broken out this way? In order to make things more modular within Mythic, most services are broken out into their own containers. When it comes to C2 profiles, they simply serve as an intermediary layer that translates between your special sauce C2 mechanism and the normal RESTful interface that Mythic uses. This allows you to create any number of completely disjoint C2 types without having to modify anything in the main Mythic codebase.
Container Information
C2 Profile Contianers, like Payload Type and Translation Containers, all use the same mythic_base_container
Docker image. From there you can leverage the github.com/MythicMeta/MythicContainer
GoLang package or the mythic_container
PyPi package depending on if you want to write the meta information about your C2 profile in GoLang or Python. The actual code that binds to ports and accepts messages can be written in any language.
Container Components
There are a few things needed to make a C2 container. For reference on general code structure options, check out Payload Type Development. The general structure is the same for Payload Types, C2 Profiles, and Translation containers.
Instead of declaring a new class of Payload Type though, you declare a new class of type C2Profile. For example, in Python you can do:
The key here for a C2 Profile though is the server_binary_path
- this indicates what actually gets executed to start listening for agent messages. This can be whatever you want, in any language you want, but you just need to make sure it's executable and identified here. If you want this to pick up something from the environment (and it's a script), be sure to put it as a #!
at the top. For example, the default containers leverage python3, so they have #! /usr/bin/env python3
at the top. This file is always executed via bash, so as a sub-process like ./server
Your server
code *MUST* send an HTTP header of Mythic: ProfileNameHere
when connecting to Mythic. This allows Mythic to know which profile is connecting
Within the server_folder_path
should be a file called config.json
, this is what the operator is able to edit through the UI and should contain all of the configuration components. The one piece that doesn't need to be here are if the operator needs to add additional files (like SSL certs).
C2Profile Class
This is a small class that just defines the metadata aspects of the C2 profile. A big piece here is the definition of the parameters
array. Each element here is a C2ProfileParameter
class instance with a few possible arguments:
C2 Profile Parameter Types
There are a few main values you can supply for parameter_type
when defining the parameters of your c2 profile:
String
- This is simply a text box where you can input a string valueChooseOne
- this is a dropdown choice where the operator makes a choice from a pre-defined list of optionsArray
- This allows an operator to input an array of values rather than a single string value. When this is processed on the back-end, it becomes a proper array value like["val1", "val2"]
.Date
- This is a date in the YYYY-MM-DD format. However, when specifying a default value for this, you simply supply an offset of the number of days from the current day. For example, to have a default value for the user be one year from the current date, the default_value would be365
. Similarly, you can supply negative values and it'll be days in the past. This manifests as a date-picker option for the user when generating a payload.Dictionary
- This one is a bit more complicated, but allows you to specify an arbitrary dictionary for the user to generate and allows you to set some restrictions on the data. Let's take a look at this one more closely:
This is saying that we have a Dictionary called "headers" with a few pre-set options.
Last updated