Skip to main content

What is it?

C2 Profiles have access to MythicRPC just like Payload Types, but naturally they’re not going to have a TaskID. So, the functions you can use will be limited, but there’s still a bunch you can leverage.

Payload Type Docker -> C2 Docker

This one is a little less intuitive than the C2 Docker container directly reaching out to the Mythic server for functionality. This functionality allows tasking as an operator to directly manipulate a C2 component. This functionality has no “default” functions, it’s all based on the C2 profile itself. Technically, this goes both ways - C2 Profiles can reach back and execute functionality from Payload Types as well. Payload Types and C2 Profiles can specify an attribute, custom_rpc_functions, which are dictionaries of key-value pairs (much like the completion functions) where the key is the name of the function that a remote services can call, and the value is the actual function itself. These functions have the following format: Mythic 4.0 propagates authenticated context through these calls. Use current container libraries and preserve that context if you build a custom RabbitMQ forwarding layer.
The incoming data is a dictionary in the incomingMsg.ServiceRPCFunctionArguments and the resulting data goes back through the Result key.

Long-running RPCs

Set custom_rpc_timeout to a positive number of seconds in Mythic’s configuration when supported server-to-container RPC routes are expected to take longer than the default timeout. V4’s custom-timeout retry policy waits that long and does not retry a timed-out request, preventing duplicate builds, dynamic queries, file-hosting actions, or other work that may still be running.
Leave the value at 0 to use the default timeout. A larger timeout does not make a function asynchronous; callers still wait for one correlated response.