Mythic: the plug-in C2 framework that ate Cobalt Strike's open-source competition

Mythic is the open-source C2 framework that’s quietly taken over the slot that Empire used to occupy in the operator’s toolkit. Cody Thomas (@its_a_feature_) started it at SpecterOps and the project has grown into a plugin-architecture C2 where the server is the only thing you install and everything else (agents, transport profiles, web translators) is a separately-installed module pulled from GitHub. The design choice that mattered: by separating the framework from the agents, Mythic let independent developers ship their own agents on the same server, which produced an ecosystem (Apollo, Poseidon, Apfell, Athena, Xenon, Medusa, Thanatos, Freyja, and growing) that no single C2 maintainer could have built alone.

This post covers the architecture as it actually exists in 2026, the install workflow with mythic-cli, the current agent lineup (the original post had several agents listed wrong, including identifying Poseidon as Python when it’s Go and listing Merlin, which is its own separate framework by Russel Van Tuyl, as a Mythic agent), and how Mythic fits next to Sliver, Cobalt Strike, and Havoc.

Install and first run

#

Mythic is Docker-deployed; you install the server, then install each agent and C2 profile as a separate plugin pulled from its own GitHub repo. The install workflow on a modern Linux operator host (Ubuntu 22.04+ is the well-tested baseline):

# Get the server source and build the containers
git clone https://github.com/its-a-feature/Mythic.git
cd Mythic
sudo make

# Install at least one agent and one C2 profile
sudo ./mythic-cli install github https://github.com/MythicAgents/Apollo
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http

# Start the server
sudo ./mythic-cli start

The web UI comes up at https://localhost:7443 (HTTPS is enforced; the self-signed cert is acceptable for local lab work but should be replaced with a real cert behind a reverse proxy on engagement infrastructure). The initial admin credentials are printed by the install process; reset them on first login.

For production engagement infrastructure, run Mythic behind a real domain with TLS termination at nginx or Caddy, scope inbound connections to the operator’s VPN, and use a malleable C2 profile that fits the target’s normal traffic patterns rather than the defaults. The lab install is fine for learning; the engagement install needs the same care as any other piece of operator infrastructure.

Architecture

#

Mythic has four moving parts. The current version as of 2026 is the 3.4.x series (3.4.0 line shipped early 2026, evolving the 3.0 architecture rewrite that landed in October 2023).

• Server. The Mythic server itself, which runs in Docker as several containers (the main Go application, a PostgreSQL database, a RabbitMQ message broker, a Hasura GraphQL layer over Postgres, and an nginx fronting the web UI). The server is what you install once; everything else plugs into it.
• Agents. The implants that run on target systems. Each agent is its own Docker container that the server installs as a plugin. The agent container builds the actual payload binaries (.exe, .dll, ELF, Mach-O, raw shellcode) on demand based on the configuration the operator picks in the UI.
• C2 profiles. The transport layer between agent and server. Also installed as Docker containers. Common profiles include http and httpx, websocket, smb (named-pipe peer-to-peer for in-network pivoting), dns, discord, github, tcp, mqtt, and dynamichttp (a more sophisticated profile that can change request patterns per callback). The C2 profile sits between the agent and server architecturally; the agent doesn’t have to know what transport it’s running over.
• Web UI and CLI. React frontend backed by GraphQL (Hasura) for the API layer. mythic-cli is the command-line companion for everything the UI can do, plus the install/start/stop/uninstall plugin management.

The plug-in model is what makes Mythic feel different from the other open-source C2s. With Cobalt Strike or Sliver, you get the framework with the agents baked in; with Mythic, you assemble the framework from the parts that make sense for your engagement. If you’re hitting Apple-platform targets, install Apfell (JXA). If you’re hitting Windows, install Apollo (.NET) or Xenon (C). If you want the long-running cross-platform default, install Poseidon (Go) or Freyja (Go).

The agents

#

The actual current agents under the MythicAgents organization in 2026 are not the three the original post listed. The lineup as of the latest check, with language and primary target platform:

• Apollo (C# / .NET 4.0, Windows). The most-developed Mythic agent and the rough analog of Cobalt Strike’s Beacon in feature completeness. Built around .NET assembly loading, in-memory execution, and the BOF (Beacon Object File) compatibility layer that lets Apollo load Cobalt-Strike-style BOFs.
• Poseidon (Go, Linux and macOS primarily, with some Windows support). Not Python; older posts get this wrong. Go was chosen for the static-linking, single-binary deployment characteristics that fit a cross-platform agent.
• Apfell (JXA / JavaScript for Automation, macOS). The agent named after the framework’s original prototype. Pure JXA, no compiled binary on target.
• Athena (C / .NET-based per project history, cross-platform). Newer than Apollo, sometimes used where the operator wants .NET semantics on a non-Windows target.
• Xenon (C, Windows). The native C agent in the lineup.
• Medusa (Python, cross-platform). Useful when the target already has Python available (most Linux servers, macOS, some enterprise Windows builds).
• Thanatos (Rust, Linux and Windows). Rust’s smaller binary size and memory safety make it attractive for droppers and loaders.
• Freyja (Go, cross-platform, purple-team-oriented). Similar role to Poseidon, different feature set.
• Sage (Python, AI-agentic wrapper). Newer addition to the ecosystem.
• Integration agents like Ghostwriter, Bloodhound, and Nemesis that bridge Mythic with adjacent operator tooling rather than landing as implants themselves.
• Wrappers like forge (Go-based BOF / .NET command augmentation) and dll_wrapper aren’t standalone agents but extend the capabilities of the others.

The agent set rotates faster than any blog post can keep up with. Swift-based and Rust-based agents have existed in the Mythic ecosystem at various points (the Swift post references Hermes, which was in MythicAgents at the time of that post but may have since been archived or moved). Check github.com/MythicAgents for the canonical current list when you’re picking what to install.

Note that Merlin is not a Mythic agent. Merlin is a separate standalone HTTP/1.1/2/3 C2 framework by Russel Van Tuyl (Ne0nd0g) at github.com/Ne0nd0g/merlin; the older draft of this post that lists Merlin alongside Apollo and Poseidon as Mythic agents is wrong. Merlin is its own framework with its own server and its own agent and has no relationship to the Mythic project.

Payloads and delivery

#

Each agent’s Docker container generates payloads through the Mythic UI. The operator picks the agent, picks the C2 profile, picks the output format (.exe, .dll, .bin raw shellcode, .elf, .app bundle, .py script, .js JXA, .lnk, OneNote attachment, depending on the agent), configures options (sleep interval, jitter, kill date, parent process spoofing, AMSI/ETW bypass settings), and clicks Build. The agent container does the actual compilation and returns the artifact for the operator to download.

Delivery is whatever fits the engagement: phishing email with HTML smuggling or an ISO-wrapped LNK, USB drop, exploitation of a vulnerable service, malicious browser extension. Mythic is agnostic about how the payload reaches the target; getting it there is the operator’s job.

C2 profiles

#

The MythicC2Profiles organization on GitHub currently hosts around 17 profile containers. The ones operators reach for most often:

• http and httpx, vanilla HTTP / HTTPS. Customizable headers, paths, response bodies. The starting point for most engagements.
• dynamichttp, a more sophisticated HTTP profile with rotating callback patterns. Better for engagements where the defender’s EDR is good at spotting beacons.
• websocket, for environments where outbound HTTP is filtered but WebSocket connections pass.
• smb, named-pipe peer-to-peer. Used for agent-to-agent communication inside a network segment where outbound C2 is blocked. The technique transfers across frameworks; covered in detail in the Covenant post .
• tcp, raw TCP for environments that allow arbitrary outbound TCP.
• dns, DNS-tunneled C2. Slow, but works through restrictive egress and ends up in DNS-query metadata where some defenders aren’t looking.
• discord, uses Discord channel messages as the C2 transport. Hides operator traffic in a service the target’s egress probably allows.
• github, uses GitHub as the C2 transport (gists, repository commits, issue comments). Newer addition.
• mqtt, for environments where MQTT brokers are part of the legitimate infrastructure (IoT-heavy networks, industrial deployments).
• basic_webhook, for sending callback notifications to operator-side webhooks during testing.

Slack was previously available as a C2 profile but has been deprecated. Custom profiles can be written following the framework’s container conventions; the MythicC2Profiles GitHub organization has reference profiles to fork from.

A typical engagement workflow

#

The day-to-day of using Mythic on engagement looks like this:

1. Generate the payload. Pick the agent (Apollo for Windows, Poseidon for Linux/macOS, etc.), pick the C2 profile, pick the output format (raw shellcode, EXE, DLL, .NET assembly, Mach-O), configure options (sleep, jitter, kill date, AMSI/ETW bypass settings), and let the agent container build it. Download the artifact.
2. Deliver the payload. Whatever fits the engagement, phishing email with HTML smuggling, ISO + LNK delivery, exploitation of an internet-facing vulnerability, malicious browser extension. Mythic is agnostic; getting it onto the target is the operator’s job.
3. Wait for the callback. When the agent runs, it calls home to the C2 profile’s listener. The agent appears in the Mythic UI under the Callbacks tab.
4. Interact with the callback. Click into the callback for a command-line interface to the agent. Commands available depend on which agent it is; Apollo has the most commands (a few hundred at the time of writing, including shell, powershell, inline_execute_assembly, execute_pe, make_token, steal_token, inject, socks, rportfwd, etc.).
5. Post-exploitation. Privilege escalation, credential dumping, lateral movement, persistence, internal reconnaissance, data identification, exfiltration. All the standard post-ex work, done through whichever agent commands fit.
6. Tear down. When the engagement ends, kill the callbacks, archive the engagement data, rotate the C2 infrastructure for the next job.

The framework also supports MITM-style operator-team collaboration: multiple operators can be logged into the same Mythic server, each interacting with their own subset of callbacks, with the full history of who did what kept in the audit log. The audit log is also what gets exported for the report.

Mythic versus the alternatives

#

How Mythic compares to the other major C2 frameworks in 2026:

The practical takeaway: Mythic is the right choice when you need a specific agent for a specific platform or need to drop your own custom agent into the framework. Sliver is the default for engagements where one Go-based cross-platform agent is enough. Cobalt Strike is what the client expects to see named in the report when they bought a commercial pentest. Havoc fills the same niche as Sliver with a more modern UI.

What this comes down to

#

Mythic is the framework that bet on modularity and won the open-source C2 space because of it. The plugin architecture meant the framework grew an ecosystem of agents and C2 profiles that no single maintainer could have built alone, and the result is a C2 that fits any platform you actually need to land on. The operator who learns Mythic well also learns how to write their own agent (the framework has thorough developer docs), which is the skill that makes the difference on engagements where stock agents are signatured.

Cody Thomas and the Mythic team keep shipping; the agent ecosystem keeps growing; the framework gets new features every few months. If you’re building out an open-source C2 stack in 2026, Mythic is one of the two or three frameworks you install first.