browser_scripts
in your mythic
folder. These are simply JavaScript files that you then reference from within your command files such as:
for_new_ui=True
in order for the script to be leveraged for the new user interface. If you don’t do this, Mythic will attach the script to the old user interface. All of the following documentation is for the new user interface.responses
and aggregates all of the responses into one string called combined
then asks Mythic to render it via: {'plaintext': combined}
.
Plaintext is also used when you don’t have a browserscript set for a command in general or when you toggle it off. This uses the react-ace text editor to present the data. This view will also try to parse the output as JSON and, if it can, will re-render the output in pretty print format.
plaintext
.
agent_file_id
or file_id
of the screenshot you’re trying to render. If you want to return this information from the agent, then this will be the same file_id
that Mythic returns to you for transferring the file. If you display this information via process_response
output from your agent, then you’re likely to pull the file data via an RPC call, and in that case, you’re looking for the agent_file_id
value. You’ll notice that this is an array of identifiers. This allows you to supply multiple at once (for example: you took 5 screenshots over a few minutes or you took screenshots of multiple monitors) and Mythic will create a modal where you can easily click through all of them.
screenshot
that has an array of Dictionaries. We do this so that you can actually render multiple screenshots at once (such as if you fetched information for multiple monitors at a time). For each screenshot, you just need three pieces of information: the agent_file_id
, the name
of the button you want to render, and the variant
is how you want the button presented (contained
is a solid button and outlined
is just an outline for the button).
processed
. In that case, if we have data we want to also display the partial screenshot, but if we have no responses yet, then we want to just inform the user that we don’t have anything yet.
agent_file_id
for the file, then you won’t be able to link to it in the UI. Let’s take an example and look at what this means:
task.status
and task.completed
fields.
file_id
field.
agent_file_id
is the file UUID of the file we’re going to download through the UI
variant
allows you to control if the button is a solid or just outlined button (contained
or outlined
)
name
is the text inside the button
plaintext
is any leading text data you want to dispaly to the user instead of just a single download button
file_id
which we use to pass in as agent_file_id
for the browser script, and total_chunks
. total_chunks
isn’t strictly necessary for anything, but if you look back at the script, you’ll see that we display that as plaintext to the user while we’re waiting for the download to finish so that the user has some sort of idea how long it’ll take (is it 1 chunk, 5, 50, etc).
download
key is an array. So yes, if you’re downloading multiple files, as long as you can keep track of the responses you’re getting back from your agent, you can render and show multiple download buttons.
download
example, but the actual dictionary we’re returning is a little different. Specifically, we have:
plaintext
as a string we want to display before our actual link to the search page
hoverText
as a string for what to display as a tooltip when you hover over the link to the search page
search
is the actual query parameters for the search we want to do. In this case, we’re showing that we want to be on the files
tab, with the searchField
of Filename
, and we want the actual search
parameter to be what is shown to the user in the display parameters (display_params
). If you’re ever curious about what you should include here for your specific search, whenever you’re clicking around on the search page, the URL will update to reflect what’s being shown. So, you can navigate to what you’d want, then copy and paste it here.
name
is the text represented that is the link to the search page.
search
responses.
table
which has an array of Dictionaries. This means that you can have multiple tables if you want. For each one, we need three things: information about headers, the rows, and the title of the table itself. Not too bad right? Let’s dive into the headers:
plaintext
, type
, and optionally width
. As you might expect, plaintext
is the value that we’ll actually use for the title of the column. type
is controlling what kind of data will be displayed in that column’s cells. There are a few options here: string
(just displays a standard string), size
(takes a size in bytes and converts it into something human readable - i.e. 1024 -> 1KB), date
(process date values and display them and sort them properly), number
(display numbers and sort them properly), and finally button
(display a button of some form that does something). The last value here is width
- this is a pixel value of how much width you want the column to take up by default. If you want one or more columns to take up the remaining widths, specify "fillWidth": true
. Columns by default allow for sorting, but this doesn’t always make sense. If you want to disable this ( for example, for a button column), set "disableSort": true
in the header information.
Now let’s look at the actual rows to display:
plaintext
key with the value we’re going to use. You’ll notice that aside from rowStyle
, each of these other keys match up with the plaintext
header values so that we know which values go in which columns.
In addition to just specifying the plaintext
value that is going to be displayed, there are a few other properties we can specify:
startIcon
- specify the name of an icon to use at the beginning of the plaintext
value. The available startIcon
values are:
endIcon
attribute
startIconHoverText
- this is text you want to appear when the user hovers over the icon
endIcon
this is the same as the startIcon
except it’s at the end of the text
endIconHoverText
this is the text you want to appear when the user hovers over the icon
plaintextHoverText
this is the text you want to appear when the user hovers over the plaintext value
copyIcon
- use this to indicate true/false if you want a copy
icon to appear at the front of the text. If this is present, this will allow the user to copy all of the text in plaintext
to the clipboard. This is handy if you’re displaying exceptionally long pieces of information.
startIconColor
- You can specify the color for your start icon. You can either do a color name, like "gold"
or you can do an rgb value like "rgb(25,142,117)"
.
endIconColor
- this is the same as the startIconColor
but applies to any icon you want to have at the end of your text
name
is the name of the button you want to display to the user. the type
field is what kind of button we’re going to display - in this case we use dictionary
to indicate that we’re going to display a dictionary of information to the user. The other type is task
that we’ll cover next. The value
here should be a Dictionary value that we want to display. We’ll display the dictionary as a table where the first column is the key and the second column is the value, so we can provide the column titles we want to use. We can optionally make this button disabled by providing a disabled
field with a value of true
. Just like with the normal plaintext
section, we can also specify startIcon
, startIconColor.
Lastly, we provide a title
field for what we want to title the overall popup for the user.
startIcon
, startIconColor
, and hoverText
for this button as well.
name
and type
fields as the dictionary button. Just like with the dictionary button we can make the button disabled or not with the disabled
field. You might be wondering which task we’ll invoke with the button. This works the same way we identify which command to issue via the file browser or the process browser - ui_feature
. These can be anything you want, just make sure you have the corresponding feature listed somewhere in your commands or you’ll never be able to task it. Just like with the dictionary button, we can specify startIcon
and startIconColor
. The openDialog
flag allows you to specify that the tasking popup modal should open and be partially filled out with the data you supplied in the parameters
field. Similarly, the getConfirmation
flag allows you to force an accept/cancel
dialog to get the user’s confirmation before issuing a task. This is handy, especially if the tasking is something potentially dangerous (killing a process, removing a file, etc). If you’re setting getConfirmation
to true, you can also set acceptText
to something that makes sense for your tasking, like “yes”, “remove”, “delete”, “kill”, etc.
The last thing here is the parameters
. If you provide parameters, then Mythic will automatically use them when tasking. In this example, we’re pre-creating the full path for the files in question and passing that along as the parameters to the download
function.
parse_arguments
function gets called when your input isn’t a dictionary or if your parse_dictionary
function isn’t defined. So keep that in mind - string arguments go here
ls -Path some_path
on the command line, Mythic’s UI is automatically parsing that into {"Path": "some_path"}
for you and since you have a dictionary now, it goes to your parse_dictionary
function
"parameters": {"Path": "my path value"}.
"parameters": "-Path some_path"
just like you would type on the command line, then you need to have a parse_arguments
function that will parse that out into the appropriate command parameters you have. If your command doesn’t take any parameters and just uses the input as a raw command line, then you can do like above and have "parameters": "path here"
table
button type and provide all of the same data you did when creating this table to create a new table (yes, you can even have menu buttons on that table).
menu
. With this we can wrap the other kinds of buttons:
task
and dictionary
buttons as before, but they’re just in an array format now. It’s as easy as that. You can even keep your logic for disabling entries or conditionally not even add them. This allows us to create a dropdown menu like the following screenshot:
startIcon
, startIconColor
, and hoverText
, properties.
agent_file_id
(the UUID value you get back when registering a file with Mythic) and the filename
of whatever media it is you’re trying to show.
media
key that sets the filename
to be the display parameters for the task (in this case it was a download command so the display parameters are the path to the file to download) and the agent_file_id
is set to the file_id
that was returned as part of the agent’s tasking. In this case, the raw agent user_output
was:
media
button on the file downloads page.
nodes
, edges
, and a group_by
string where you can optionally group your nodes via certain properties.
id
- this is a unique way to identify this node compared to others. This is also how you’ll identify the node when it comes to creating edges.
img
- if you want to display an image for your node, you give the name of the image here. Because this is React, we need to identify these all ahead of time. For now, the available images are as follows: group, computer, user, lan, language, list, container, help, diamond, skull. We can always add more though - if you find a free icon on Font Awesome or Material UI then let me know and I can get that added.
style
- this is where you can provide React styles that you want applied to your image. These are the same as CSS styles, except that -
are removed and camel casing is used instead. For example, instead of an attribute of background-color
like normal CSS, you’d define it as backgroundColor
.
overlay_img
- this is the same as img
except that you can define a SECOND image to have overlayed on the top right of your original one.
overlay_style
- this is the same as style
except that it applied to overlay_image
instead of img
.
data
- this is where any information about your actual node lives
label
value in here that’s used to display the text under your nodebuttons
- this is an array of button actions you’d like to add to the context menu of your node. This is the same as the normal buttons from Tables, except there’s no need for a menu
button.
source
- all of the data (as a dictionary) about the source node. Mythic will try to do things like source.id
to get the ID for the source node.
destination
- all of the data (as a dictionary) about the destination/target node.
label
- the text to display as a label on the edge
data
- dictionary of information about your edge
animate
- boolean true/false if you want the edge the be animated or a solid color
color
- the color you want the edge to be
buttons
- this is an array of button actions you’d like to add to the context menu of your edge.