Version 2.0

Payload Type Development

This section describes new Payload Types

Creating a new Mythic agent

You want to create a new agent that fully integrates with Mythic. Since everything in Mythic revolves around Docker containers, you will need to ultimately create one for your payload type along with some specific files/folder structures. This can be done with docker containers on the same host as the Mythic server or with an external VM/host machine.

  • Optionally: You can also have a custom C2 profile that this agent supports, see C2 Profile Development for that piece though

The first step is to look into the First Steps page to get everything generally squared away and look at the order of things that need your attention. The goal is to get you up and going as fast as possible!

Payload Type Docker Information

The rest of these sections talk about specifics for the docker container for your new agent.

Creating a docker container for your new agent

There are docker containers for each payload type which contain customized build environments. This allows two payload types that might share the same language to still have different environment variables, build paths, tools installed, etc. Docker containers come into play for a few things:

  • Metadata about the payload type (this is in the form of python classes)

  • The payload type code base (whatever language your agent is in)

  • The python code to create the payload based on all of the user supplied input

  • Metadata about all of the commands associated with that payload type (more python classes)

  • The code for all of those commands (whatever language your agent is in)

  • Browser scripts for commands and support scripts for the payload type as a whole (JavaScript)

  • The python code to take user supplied tasking and turn it into tasking for your agent

This part has to happen outside of the web UI at the moment. The web UI is running in its own docker container, and as such, can't create, start, or stop entire docker containers. So, make sure this part is done via CLI access to where Mythic is installed.

Within Mythic/Payload_Types/ make a new folder that matches the name of your agent. Inside of this folder make a file called Dockerfile. This is where you have a choice to make - either use the default Payload Type docker container as a starting point and make your additions from there, or use a different container base.

Using the default container base

The default container is pretty bare bones except for python 3.6. Start your Dockerfile off with:

From itsafeaturemythic/python36_payload:0.0.5

On the next lines, just add in any extra things you need for your agent to properly build, such as:

RUN pip install python_module_name
RUN shell_command
RUN apt-get install -y tool_name

This happens all in a script for docker, so if a command might make a prompt for something (like apt-get), make sure to auto handle that or your stuff won't get installed properly

There are a few different default containers you can leverage depending on the environment you need:

  • From itsafeaturemythic/python36_payload:0.0.5

    • This is based on python:3.6-buster and only has python3.6 installed

  • From itsafeaturemythic/csharp_payload:0.0.5

    • This is based on mono:latest with python 3.6.9 manually installed along with the System.Management.Automation.dll added in

  • From itsafeaturemythic/xgolang_payload:0.0.4

    • This is based on karalabe/xgo-latest with python 3.6.9 manually installed

If you're curious what else goes into these containers, look in /Mythic/Docker_Templates/Docker_Payload_type_base_files for the docker files associated with each container.

Required Folder Structure

The Mythic/Payload_Types/[agent name] folder is mapped to /Mythic in the docker container. Editing the files on disk results in the edits appearing in the docker container and visa versa.

All of your agent code, commands, and c2 profile code should be in the following folder: Mythic/Payload_Types/[agent name]/agent_code/. You can have any folder structure or files you want here.

The Mythic/Payload_Types/[agent name]/mythic folder contains all information for interacting with Mythic. Inside of the mythic folder there's a subfolder agent_functions where all of your agent-specific building/command information lives.

The entire folder structure can be copied from the Example_Payload_Type folder.

There isn't too much that's different if you're going to use your own container, it's just on you to make sure that python3.6 is up and running and the entrypoint is set properly. Here's what the base containers do:

From python:3.6-buster
RUN pip install aio_pika

RUN mkdir /Mythic_service 2>/dev/null
COPY ["payload_service.sh", "/Mythic_service/payload_service.sh"]
RUN chmod +x /Mythic_service/payload_service.sh
WORKDIR /Mythic_service/

ENTRYPOINT ["/Mythic_service/payload_service.sh"]

Notice that it installs python3.6, sets it up correctly, installs the required packages (aio_pika) for Mythic, and gets the directory structure all set up like the default container template does.

Starting your Docker container

To start your new payload type docker container, use the ./start_payload_types.sh script and supply the name of your payload type. For example, to start just the atlas payload type container, run:

sudo ./start_payload_types.sh atlas

Your container should pull down all the necessary files, run the necessary scripts, and finally start. If it started successfully, you should see it listed in the payload types section when you run sudo ./status_check.sh.

If you go back in the web UI at this point, you should see the red light next to your payload type change to green to indicate that it's now getting heartbeats. If it's not, then something went wrong along the way. You can use the sudo ./display_output.sh payload_type_name to see the output from the container to potentially troubleshoot.

The containers will automatically sync all of their information with the Mythic server when they start, so the first time the Mythic server gets a message from a container it doesn't know about, it'll ask to sync. Similarly, as you do development and restart your Payload Type container, updates will automatically get synced to the main UI.

If you want to go interactive within the container to see what's up, use the following command:

sudo docker exec -it {payload type name} /bin/bash

The container has to be running though.

Turning a VM into a Mythic container

There are scenarios in which you need a Mythic container for an agent, but you can't (or don't want) to use the normal docker containers that Mythic uses. This could be for reasons like:

  • You have a custom build environment that you don't want to recreate

  • You have specific kernel versions or operating systems you're wanting to develop with

So, to leverage your own custom VM or physical computer into a Mythic recognized container, there are just a few steps.

  1. Install python 3.6+ in the VM

  2. pip3 install aio_pika (this is used to communicate via rabbitmq)

  3. Create a folder on the computer or VM (let's call it path /pathA).

  4. Do the same folder structure and files as above in the Payload_Types/[agent name] folder. Essentially, your /pathA path will be the new Payload_Types/[agent name] folder.

  5. Edit the rabbitmq_config.json with the parameters you need

    1. the host value should be the IP address of the main Mythic install

    2. the name value should be the name of the payload type (this is tied into how the routing is done within rabbitmq). For Mythic's normal docker containers, this is set to hostname because the hostname of the docker container is set to the name of the payload type. For this case though, that might not be true. So, you can set this value to the name of your payload type instead.

    3. the container_files_path should be the absolute path to the folder in step 3 (/pathAin this case)

  6. Run python3 mythic_heartbeat.py in the background

  7. Run python3 mythic_service.py and now you should see this container pop up in the UI

  8. If you already had the corresponding payload type registered in the Mythic interface, you should now see the red light turn green.

Caveats

There are a few caveats to this process over using the normal process. You're now responsible for making sure that the right python version and dependencies are installed, and you're now responsible for making sure that the user context everything is running from has the proper permissions.

One big caveat people tend to forget about is paths. Normal containers run on *nix, but you might be doing this dev on Windows. So if you develop everything for windows paths hard-coded and then want to convert it to a normal Docker container later, that might come back to haunt you.

Last updated