upload
command, this is for any command that wants to leverage a file from Mythic.{"file":"uuid", "path": "/some/path"}
rather than {"file": raw bytes of file, "path": "/some/path"}
. create_tasking
that handles the processing of tasks from users before handing them off to the database to be fetched by an agent. If your agent supports chunking and transferring files that way, then you don't need to do anything else, but if your agent requires that you send down the entire file's contents as part of your parameters, you need to get the associated file. file_resp.response
is an array of file information, we'll take the filename
from the first entry. We can use this to get the original filename back out from Mythic from the user's upload command. If there's something we want to modify about the file (such as adding a comment automatically or indicating that the file should be deleted from disk after the agent fetches it) we can use the update_file
RPC function to do so.get_file
query should indicate get_contents=True
, then you can access the raw bytes via file_resp.response[0]["contents"]
. You can then swap out the contents of the parameter with task.args.add_arg("arg name", "base64 of file contents here")
.create_file
RPC call.full_path
. This allows Mythic to track a new entry in the database with an associated task for uploads. The full_path
key lives at the same level as user_output
, total_chunks
, etc in the post_response
.chunk_size
and also reports to the agent how many chunks there are.full_path
is what allows Mythic to track the file in the Files search page as a file that has been written to disk. If you don't report back a full_path
or have full_path
as an empty string, then Mythic thinks that the file transfer only lived in memory and didn't touch disk. This is separate from reporting that a file was written to disk as part of artifact tracking on the Reporting Artifacts page.delete_after_fetch
as True
, then the file won't exist on disk after the first fetch and thus can't be re-used). This is to prevent bloating up the server with unnecessary files.full_path
parameter is helpful for accurate tracking. This allows an operator to be in the /Temp
directory and simply call the upload function to the current directory, but allows Mythic to track the full path for easier reporting and deconfliction.full_path
parameter is only needed if the agent plans to write the file to disk. If the agent is pulling down a file to load into memory, then there's no need to report back a full_path
.{'action': 'post_response', 'responses': [ {'total_chunks': 0, 'chunk_num': 0, 'chunk_data': '', 'file_id': '', 'task_id': '', 'status': 'error', 'error': 'some error message'} ] }
)
If the task_id was there in the request, but there was an error with some other piece, then the task_id will be present in the response with the right value.