What is it?
C2 Profiles have access to MythicRPC just like Payload Types, but naturally they’re not going to have aTaskID. 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.
incomingMsg.ServiceRPCFunctionArguments and the resulting data goes back through the Result key.
Long-running RPCs
Setcustom_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.
0 to use the default timeout. A larger timeout does not make a function asynchronous; callers still wait for one correlated response.