Message Request
The contents of the JSON message from the agent to Mythic when requesting tasking is as follows:-
tasking_size- This parameter defaults to one, but allows an agent to request how many tasks it wants to get back at once. If the agent specifies-1as this value, then Mythic will return all of the tasking it has for that callback. -
delegates- This parameter is not required, but allows for an agent to forward on messages from other callbacks. This is the peer-to-peer scenario where inner messages are passed externally by the egress point. Each of these agentMessage is a self-contained “Agent Message” and thec2_profileindicates the name of the C2 Profile used to connect the two agents. This allows Mythic to properly decode/translate the messages even for nested messages. -
get_delegate_tasks- This is an optional parameter. If you don’t include it, it’s assumed to beTrue. This indicates whether or not thisget_taskingrequest should also check for tasks that belong to callbacks that are reachable from this callback. So, if agentA has a route to agentB, agentB has a task in thesubmittedstate, and agentA issues aget_tasking, agentA can decide if it wants just its own tasking or if it also wants to pick up agentB’s task as well.- Why does this matter? This is helpful if your linked agents issue their own periodic
get_taskingmessages rather than simply waiting for tasking to come to them. This way the parent callback (agentA in this case) doesn’t accidentally consume and toss aside the task for agentB; instead, agentB’s own periodicget_taskingmessage has to make its way up to Mythic for the task to be fetched.
- Why does this matter? This is helpful if your linked agents issue their own periodic
Message Response
Mythic responds with the following message format for get_tasking requests:-
tasks- This parameter is always a list, but contains between 0 andtasking_sizenumber of entries. -
parameters- this encapsulates the parameters for the task. If a command has parameters like:{"remote_path": "/users/desktop/test.png", "file_id": "uuid_here"}, then theparamsfield will have that JSON blob as a STRING value (i.e. the command is responsible to parse that out). -
delegates- This parameter contains any responses for the messages that came through in the first message.
This
get_tasking request CAN also include a responses field, socks, rpfwd, edges, alerts, and interactive fields. This means you can technically only do checkin and get_tasking messages since you can forward responses in this message. The reason for this is you might not want to have to send TWO messages per sleep interval - ex: you don’t want to post the response from an output and make a get_tasking request back-to-back, but you also don’t want to not do get_tasking requests while you’re periodically sending task responses back.