Consider the mythical framework C2 Mythic. Part 1

Description

Mythic is a cross-platform C2 framework Red Teamdesigned by Cody Thomas of SpecterOps and intended for post-exploitation. Core elements of Mythic are written in Python3, and the platform relies heavily on Docker to manage key elements of its functionality, including the server, agents, and C2 profiles. The framework also has its own web interface and is designed to be extensible, with the ability for other people to create agents for it.
At the moment, it supports the following connections:

• TCP

• HTTP

• Web-socket

• SMB

• DNS

  In addition, Mythic has about a dozen different agents written in Go, Python, C#, targeting Windows, MacOS, and Linux.

Agents in this framework they name the types of loads that you can see in the official repository Mythic Agentseach of which is written in the appropriate programming language depending on the OS.

Installation and installation

The docker containers that Mythic uses for agents, C2 connections, and the like can be large, as they can contain entire build environments, sometimes for multiple OSes.
You can install Mythic from the official GitHub repository:

git clone https://github.com/its-a-feature/Mythic

Before running Mythic, make sure you have Docker and Docker-compose installed on your system, as they are required to install and run the framework:

sudo apt update && apt upgrade -y && apt install docker docker-compose

Mythic includes a couple of scripts ( install_docker_debian.sh And install_docker_ubuntu.sh) to make things easier. (Eat install_docker_kali.shbut these are only the commands I listed earlier.)

Mythic is controlled via a binary file mythic-cli. To generate it, write it in the folder with the framework sudo make .
After downloading, you can start all containers at once with the command:

sudo ./mythic-cli start

More specific setup instructions, configurations, examples, screenshots and more can be found on the website Mythic documentation .

The repository itself does not contain any payload types or C2 profiles. Instead, Mythic provides the command

./mythic-cli install github <url> [branch name] [-f]

which can be used to install agents on the current Mythic instance.
For example:

sudo ./mythic-cli install github https://github.com/MythicAgents/apollo

Beginning of work

After you launch Mythic with the command sudo ./mythic-cli start you can see all the services that are currently running.
We are interested in the nginx service, which hosts the web interface for the client.

We go to it and see that we are greeted by an authorization window:

To log in, we need to take the login and password from the file .env in the main directory of the framework:

Open the file and find the data we need:

Now we can log in. We are greeted by this web interface, which offers us a quick guide to generating load:

As I said, Mythic does not have profiles or C2 agents installed by default. Anything you want to use must be installed using the Mythic CLI tool. To install the Poseidon agent, the following command was used:

sudo ./mythic-cli install github https://github.com/MythicAgents/poseidon

Poseidon establishes its own C2-TCP connection, but this is a peer-to-peer connection for communication between agents within the compromised environment, so to enable outgoing communication with my server, we will establish http connection using the following command:

sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http

As I said, Mythic is a multi-operator platform and with an admin account you can add users by clicking on the user icon in the top right corner of the page and selecting our user mythic_admin:

Mythic groups actions performed on a goal or a related set of goals into “operations.” Mythic users must be granted access rights for each operation. A default operation that can be specified in a file .envis Operation Chimera. The Operations screen can be accessed by clicking the Operation Chimera button on the button bar at the top of the page.

On the Operations screen, you can create and edit operations, create new users, and create command block lists. Let’s click New Operationto create a new operation. After creating it we use Edit for operators of this operation, after which it becomes possible to assign users to it, set their roles and assign block lists.

Available roles:

1. lead– is an operation administrator with the ability to add/remove operators and change roles;

2. operator – is a standard operator;

3. spectator – can observe the operation, but take no action.

I have assigned my account justin the head of the operation, then logged out of the account mythic_admin and logged back in with justin. As an aside, I note that even as the head of the operation, I could not change the operation until I pressed the blue button Make Current on the operation management screen.
Pressing Edit button on the activity itself opens up the option to rename the activity, mark it as complete, or set up Slack webhooks for that activity if you integrate with Slack.

The last thing on the operations configuration page is the blacklists section. Blacklists define a list of commands that Mythic will not allow this agent to run (for example, Apollo, Poseidon, Merlin).

Blacklists can be assigned on a per-user and per-transaction basis. So, if you want to prevent a specific user from doing anything to change the drive on a compromised machine, you can create a blacklist that disables commands like cp, upload, mv, mkdir etc. and then assign it on the operation edit page operators.

C2 profiles

I clicked the headphones icon at the top of the page to open the “Payload Types and C2 Profiles” page.

This page displays information about all installed C2 agents and connections. On my server this showed that I had Apollo and Poseidon agents installed, as well as http and Poseidon TCP C2 connections.

C2 Mythic http connection configuration options are limited to changing the server headers, port, URL, and enabling TLS. To access the profile configuration, I clicked the down arrow on the button start profile to access the drop-down menu and selected View/Edit Config.

Configuration is a JSON file that allows the operator to set server headers, listen port, and enable TLS/SSL. To enable TLS/SSL, set the value use ssl How true. If key path And cert path are valid files, Mythic will use them for the http C2 profile. Otherwise it will generate self-signed certificates.

I decided to use the default profile. The http C2 profile will be relatively easy to identify since each request will be essentially identical.

I saved my configuration and clicked the button Start Profile. A moment later, an output log appeared confirming the action, and the panel Profile the new status is displayed.

Agents

Mythic supports multiple agents, each with its own set of capabilities and OS and connection support. It is important to carefully read the documentation for a specific agent to ensure that the agent will be able to support the specific operations for which it will be used.

Clicking the biohazard icon in the button bar at the top of the page will open the payloads page.

I clicked on the drop down list Actions and chose Generate New Payload from the menu.
I chose Linux as the target operating system. Selecting a target OS will limit the selection of agent types on the next screen.

Having selected a Linux agent, my agent options were Medusa and Poseidon. I selected Medusa and got the build options. Medusa supports creating agents as regular scripts or Base64 encoded blobs. It also gives the ability to create agents compatible with Python 2.7 or 3.8, choose encryption implementation (manual or library cryptography), as well as encode and encrypt the agent code. I decided to use the default settings.

Some agent types allow the operator to customize commands built into the agent. This can be used to control the size of the payload and to ensure that certain commands cannot be run. Medusa requires the operator to affirmatively indicate which commands to embed. I decided to embed all the commands into my agent.

On the next page I selected the http C2 profile (the only one available) and set the host address http://<ip_address>. Other options here include setting the agent’s kill date, the URI and parameters for POST and GET requests, and the callback port.

On the final agent creation page, I can specify a file name and description for the agent and approve its creation.

Quite quickly a popup appeared saying the agent was ready to download and it appeared on the payloads page.

Clicking the info icon on the right brings up the payload configuration, including a list of built-in commands.

When working with an active agent, the same information can be obtained through the agent drop-down menu under this option View Metadata.

For testing purposes, I downloaded the agent to the machine I was working with and launched it with the command python3 medusa_agent.py and received a call back almost immediately. Clicking on the keyboard icon allowed me to interact with the beacon.

Pivots

Mythic has C2 channels that support the creation of a chain of beacons deep within the network, which are connected through a single beacon that has HTTP access to the C2 server. The beacon must be created using a peer-to-peer C2 connection and then associated with a beacon that has direct or chained access to the C2 server using the command link. The most common connection is SMB, although Poseidon and Freyja beacons have their own custom TCP P2P.

When executing the command link A dialog box appears in which the operator can either select a known host that has already been contacted or specify a new host.

Linked agents will appear as a chain icon under type C2. They may also have a high last check time because they do not log a check unless a command has been sent to them or data has been received to return.

SOCKS5

Some Mythic agents support the creation of SOCKS5 proxies, allowing the operator to proxy traffic from a test node to the target network. The Apollo and Medusa agents support SOCKS5 proxies, and the new .NET 6-based Athena agent is announced as beta proxy support.
The operator can start the proxy using the command socks [port]. The specified port must be within the range specified in the variable MYTHIC_SERVER_DYNAMIC_PORTS Mythic configuration file, which defaults to 7000-7010. Currently Mythic only supports TCP through its SOCKS5 proxies, UDP connections are not supported.
After the operator has created a proxy, click on the socks At the top of the screen you can open the SOCKS tab, which displays all active proxies, ports and agents through which they work.

Since my Mythic server is running on a different host than the one I’m on, I need to add a forwarding port to my ssh connection to make the proxy available to my tools. I can do this either when starting the connection by adding it to the end of the command line ssh -L 127.0.0.1:7000:127.0.0.1:7000or using the ssh control sequence to add it to an existing session by doing the following:

$ <enter>
$~C
ssh> -L 127.0.0.1:7000:127.0.0.1:7000

ssh> tells me that I am now giving commands directly to SSH and can
add your port forward as if I did it when starting the client.

Now, having a proxy and local port forwarding, I can use proxying tools like Certificate, through an agent.

Note that running a SOCKS5 proxy will not change the agent’s logging interval, so if commands executed through an agent seem to be taking an exceptionally long time to complete, setting that agent to interactive mode ( ) sleep 0 may speed things up.

Conclusion

These are the basics of installing and using Mythic. It is one of the most customizable C2s, both in terms of the different agents and how individual agents can be tailored for a specific task. In the next article I will show how to use this framework using a specific example. See you soon!