Message Flow

This page describes how messages flow within Mythic

What happens for tasking?

There's a lot of moving pieces within Mythic and its agents, so it's helpful to take a step back and see how messages are flowing between the different components.

Issuing Tasking Flow Within Mythic

Here we can see an operator issue tasking to the Mythic server. The Mythic server registers the task as "preprocessing" and informs the operator that it got the task. Mythic then sends the task off to the corresponding Payload Type container for processing. The container looks up the corresponding command python file, parses the arguments, validates the arguments, and passes the resulting parameters to the create_tasking function. This function can leverage a bunch of RPC functionality going back to Mythic to register files, send output, etc. When it's done, it sends the final parameters back to Mythic which updates the Task to either Submitted or Error. Now that the task is out of the preprocessing state, when an agent checks in, it can receive the task.

The corresponding mermaid diagram code is:

{{<mermaid>}}
sequenceDiagram
    participant O as Operator
    participant M as Mythic
    participant P as Payload Container
    O ->>+ M: Issues Task
    M ->> M: Creates Preprocessing Task
    M -->>- O: Indicate new task exists
    M ->>+ P: Forward Task
    P ->> P: Parse Arguments
    P ->> P: Validate Arguments
    loop create_tasking
        P -->> M: Use RPC Functionality
        M -->> P: RPC Replies
    end
    Note over P: Finish Processing
    P -->>- M: Send finished task
    M ->> M: Updates Task to Submitted or Error
    M -->> O: Update with new Task Status
{{< /mermaid >}}

What happens for building payloads?

What happens when an operator tasks a payload to build?

Issuing a Build command to Mythic

Here we can see that the operator selects the different payload options they desire in the web user interface and clicks submit. That information goes to Mythic which looks up all the database objects corresponding to the user's selection. Mythic then registers a payload in a building state. Mythic sends all this information to the corresponding Payload Type container to build an agent to meet the desired specifications. The corresponding build command parses these parameters, stamps in any required user parameters (such as callback host, port, jitter, etc) and uses any user supplied build parameters (such as exe/dll/raw) to build the agent.

In the build process, there's a lot of room for customizing. Since it's all async through rabbitMQ, you are free to stamp code together, spin off subprocesses (like mono or go) to build your agent, or even make web requests to CI/CD pipelines to build the agent for you. Eventually, this process either returns an agent or some sort of error. That final result gets send back to Mythic via rabbitMQ which then updates the database and user interface to allow an operator to download their payload.

The corresponding mermaid diagram code is:

{{<mermaid>}}
sequenceDiagram
    participant O as Operator
    participant M as Mythic
    participant P as Payload Container
    participant B as Compiler
    O -->> O: Selects Payload Options
    O ->>+ M: Sends Build Request
    M -->> M: Looks up all Components
    M ->> M: Registers Payload
    M -->>- O: Indicate that build has started
    M ->>+ P: Forward Build Parameters
    P ->> P: Parse Parameters
    loop create_tasking
        P -->> P: Stamp in Parameters
        P -->> B: Build Payload
        B -->> P: Return Payload or Error
    end
    Note over P: Finish Building
    P -->>- M: Send finished Payload
    M ->> M: Updates Payload build status
    M -->> O: Update with new Build Status
{{< /mermaid >}}