C2 Docker Containers
Last updated
Last updated
All C2 profiles are backed by a Docker container or intermediary layer of some sort.
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.
The most current docker container for C2 Profiles is itsafeaturemythic/python38_sanic_c2profile:0.0.6. This container, which has all of its source code hosted on GitHub, uses the mythic_c2_container PyPi module to connect to Mythic and process requests. This PyPi module can be found on GitHub, and is currently version 0.0.23 and reports to Mythic as version "4".
There are a few things needed to make a C2 container. For this example, let's assume the name of the C2 profile is ABC:
Make the following folder structure by copying Example_C2_Profile as ABC under /Mythic/C2_Profiles/. The result should look like:
2. Within c2_code should be a file called server (this is what will be executed when you select to start the c2 profile). If you want this to pick up something from the environment, 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
3. Within c2_code 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). There are too many security concerns and processes that go into arbitrary file upload currently that make this process require you to ssh into the host where Mythic is running and put the files there manually. This might change in the future, but that's the current expectation.
4. Within ABC there should be a Dockerfile that sets up your environment. In most cases, you'll simply start it off with:
But you can customize this as well
5. Within the mythic folder are all the basic files for processing tasking. The rabbitmq_config.json file is fine being left alone if you're doing a local Docker container. If you're turning another computer into your C2 container, similar to what you can do with Payload Types, then this will need to be modified in the same way as Payload Type Development.
6. Within the mythic folder is the c2_functions folder. This is analogous to the agent_functionsfolder within Payload Types. This is where you'll put your Python files that define the C2 Profile metadata and establish any RPC functions you want to expose to other containers. This technically allows you to chain C2 containers together for RPC calls.
Within the /Mythic/C2_Profiles/ABC/mythic/c2_functions folder is a python file (name doesn't matter, typically matches the c2 profile name though) with a new class that extends the base C2 Profile class. If you just copied from Example_C2_Profile though, then this will be called HTTP.py. An example would be:
This is a small class that just defines the metadata aspects of the C2 profile. The main piece here is the definition of the parameters array. Each element here is a C2ProfileParameter class instance with a few possible arguments:
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 value
ChooseOne - this is a dropdown choice where the operator makes a choice from a pre-defined list of options
Array - 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 be 365. 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 "USER_AGENT" with a few pre-set options.
The first value is called "USER_AGENT" and there can be at most one key with that name (max: 1). There's a default value for it and that one will be shown by default.
There's another value called "host" that doesn't have a default value and allows you to specify 2 values for it (ex: this would be like a {"host": ["val1, "val2"]} situation. This one isn't shown by default, but you can add these in via the UI.
There's one final entry with a name called "*" and a max number of -1. This is a special scenario - -1 means that there is no limit, you can have as many of these as you want. The name called "*" is a special case where you get to write in your own key value. This allows you to give an operator the ability to supply arbitrary key-value pairs.
The two screenshots above show what this scenario looks like in the UI when generating a payload. The first one shows that by default, the user only sees the USER_AGENT key with the default value, but they have the option to modify the value here or add more keys. Notice that an option is "host". The second screenshot shows that we were able to add two "host" keys, but now when we try to add more, "host" isn't an option and only "Custom" is. This matches up with our "*" values that have an unlimited number (max: -1) and the host key having a max of 2.
