Commandclass, there are two functions -
process_response. As the names suggest, the first one allows you to create and manipulate a task before an agent pulls it down, and the second one allows you to process the response that comes back. If you've been following along in development, then you know that Mythic supports many different fields in its
post_responseaction so that you can automatically create artifacts, register keylogs, manipulate callback information, etc. However, all of that requires that your agent format things in a specific way for Mythic to pick them up and process. That can be tiring.
process_responsefunction takes in one argument class that contains two pieces of information: The
taskthat generated the response in the first place, and the
responsethat was sent back from the agent. Now, there's a specific
process_responsekeyword you have to send for mythic to shuttle data off to this function instead of processing it normally. When looking at a
post_responsemessage, it's structured as follows:
process_responsekey will get sent to the
process_responsefunction in your Payload Type container.
process_containerkey, then as soon as the data is shipped off to your
process_responsefunction, Mythic is going to send the all clear back down to the agent and say everything was successful. It doesn't wait for your function to finish processing anything, nor does it expect any output from your function.
process_responsefunctionality because the agent needs the response in order to keep functioning. Compare this to something like registering a keylog, creating an artifact, or providing some output to the user which the agent tends to think of in a "fire and forget" style. These sorts of things are fine for async parallel processing with no response to the agent.
responsehas two fields:
response.taskis the task you'd expect from the OPSEC checking or
response.responseis the data you put in the