Mythic Documentation
Version 2.3
Version 2.3
  • Mythic
  • Operators
  • Installation
    • Connecting
    • A note about containers
    • Offline Installation
    • Updating Mythic
  • Internal Documentation
  • Quick Usage
  • Operational Pieces
    • MITRE ATT&CK
    • Operations
    • Browser Scripts
    • Active Callbacks
    • Files
    • Search
    • File Browser
    • Socks Proxy
    • Credentials
    • Comments
    • Tags
    • Expanded Callbacks
    • Screenshots
    • Event Feed
    • API Tokens
  • Message Flow
    • Building Payloads
    • Agent Sends Message
    • File Upload Mythic->Agent
    • File Download Agent->Mythic
    • P2P Messages
    • Operator Submits Tasking
  • Database Schema
  • Understanding Commands
    • Basic Information
    • Parameters
    • MITRE ATT&CK in Commands
  • Payload Types
    • Configuration
    • Containers
  • C2 Profiles
    • C2 Server Utilities
    • Egress vs P2P
    • HTTP
    • dynamicHTTP
    • Save Parameters
  • Reporting
    • Artifacts
    • MITRE ATT&CK
    • Reports
  • Scripting
  • Presentations / Webinars
  • Common Errors
  • Customizing
    • Hooking Features
      • Actions
      • Linking Agents
      • P2P Connections
      • Process_List
      • Artifacts
      • Credentials
      • File Downloads (Agent -> Mythic)
      • File Uploads (Mythic -> Agent)
      • Screenshots
      • Commands
      • Keylog
      • File Browser
      • Tokens
      • Task Status
    • Payload Type Development
      • Translation Containers
      • First Steps
      • Container Syncing
      • Payload Type Info
      • Commands
      • Browser Scripting
      • Dynamic Parameter Values
      • Create_Tasking
      • MythicRPC
      • OPSEC Checking
      • Sub-tasking / Task Callbacks
      • Process Response
      • SOCKS
      • Reverse PortFwd
      • Adding Commands
    • C2 Related Development
      • C2 Profile Code
        • Agent Side Coding
          • Delegates (p2p)
          • Agent Message Format
          • Action: Checkin
          • Action: get_tasking
          • Action: post_response
          • SOCKS
          • RPFWD
        • Server Side Coding
          • OPSEC Checks For C2 Profiles
          • Configuration Checks
          • Redirect Rules
          • C2 Docker Containers
          • C2 Configuration Files
    • Mythic UI Development
  • Common Questions and Answers
    • FAQ / Troubleshooting Tips
    • Change Log
    • Next Release
    • Tip of the Week
  • Updating
    • Mythic 2.1 -> 2.2 Updates
      • Agents 2.1.* -> 2.2.8
        • MythicRPC
    • Mythic 2.2 -> 2.3 Updates
      • Agents 2.2 -> 2.3
    • Mythic 2.3 -> 3.0 Updates
      • Agents 2.3 -> 3.0
Powered by GitBook
On this page
  • What is it?
  • When does it happen?
  • Current Container Versions

Was this helpful?

Export as PDF
  1. Customizing
  2. Payload Type Development

Container Syncing

PreviousFirst StepsNextPayload Type Info

Last updated 1 year ago

Was this helpful?

What is it?

When your container starts up, it connects to the rabbitMQ broker system. Mythic then tries to look up the associated payload type and, if it can find it, will update the running status. However, if Mythic cannot find the payload type, then it'll issue a "sync" message to the container. Similarly, when a container starts up, the first thing it does upon successfully connecting to the rabbitMQ broker system is to send its own synced data.

This data is simply a JSON representation of everything about your payload - information about the payload type, all the commands, build parameters, command parameters, browser scripts, etc.

When does it happen?

Syncing happens at a few different times and there are some situations that can cause cascading syncing messages.

  • When a payload container starts, it sends all of its synced data down to Mythic

  • If a C2 profile syncs, it'll trigger a re-sync of all Payload Type containers. This is because a payload type container might say it supports a specific C2, but that c2 might not be configured to run or might not have check-ed in yet. So, when it does, this re-sync of all the payload type containers helps make sure that every agent that supports the C2 profile is properly registered.

  • When a Wrapper Payload Type container syncs, it triggers a re-sync of all non-wrapper payload types. This is because a payload type might support a wrapper that doesn't exist yet in Mythic (configured to not start, hasn't checked in yet, etc). So, when that type does check in, we want to make sure all of the wrapper payload types are aware and can update as necessary.

Current Container Versions

Latest versions can always be found on the Mythic .

README