Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
All uploads and downloads for an operation can be tracked via the clip icon or the search icon at the top.
This page simply shows all uploads and downloads tracked by Mythic and breaks them up by task.
From here, you can see who download or uploaded a file, when it happened, and where it went to or came from. Clicking the download button will download the file to the user's machine.
If you want to download multiple files at once from the Downloads
section, click the toggle for all the files you want and select the Zip & Download selected
button at the top right to download them. You can also preview the first 512KB of a file either as a string or as a hex xxd formatted view. This makes it easier to browse downloaded files without having to actually download them and open them up in a new tool.
Each file has additional information such as the SHA1 and MD5 of each file that can be viewed by clicking the blue info icon. If there's a comment on the task associated with the file upload or download, that comment will be visible here as well.
Operations are collections of operators, payloads, tasks, artifacts, callbacks, and files. While payload types and c2 profiles are shared across an entire Mythic instance, operations allow fine grained control over the visibility and access during an assessment.
Operation information can be found via the hamburger icon in the top left, then selecting "Operations" -> "Modify Operations" page. If you're a global Mythic admin, you'll see all operations here. Otherwise, you'll only see operations that are associated with your account.
Every operation has at least one member - the lead operator. Other operators can be assigned to the operation with varied levels of access.
operator
is your normal user.
lead
is the lead of that operation
spectator
can't do anything within Mythic. They essentially have Read-Only access across the entire operation. They can't create payloads, issue tasking, add comments, send messages, etc. They can search and view callbacks/tasking, but that's it.
For more fine-grained control than that listed above, you can also create block lists. These are named lists of commands that an operator is not allowed to execute for a specific payload type. These block lists are then tied to specific operators. This offers a middle-ground between normal operator with full access and a spectator with no access. You can edit these block lists via the yellow edit button.
For the configure button for the operation, there are many options. You can specify a Slack webhook along with the channel. By default, whenever you create a payload via the "Create Payloads" page, it is tagged as alert-able - any time a new callback is created based on that payload, this slack webhook will be invoked. If you want to prevent that for a specific payload, go to the payloads page, select the "Actions" dropdown for the payload in question, and select to stop alerting. If you have the Slack webhook set on the operation overall, other payloads will continue to generate alerts, but not the ones you manually disable. You can always enable this feature again in the same way.
For the operators edit button, you can edit who is assigned to the operation, what their roles are, and specify which (if any) block lists should be assigned to that user.
Because many aspects of an assessment are tied to a specific operation (payloads, callbacks, tasks, files, artifacts, etc), there are many things that will appear empty within the Mythic UI until you have an operation selected as your current operation. This lets the Mythic back-end know which data to fetch for you. If you don't have an operation as your active one, then you'll see no operation name listed on the top center of your screen. Go to the operations page and, if you're assigned to an operation that you can see, you can select to "Make Current".
Browser Scripts allow users to script the output of agent commands. They are JavaScript functions that can return structured data to indicate for the React user interface to generate tables, buttons, and more.
Browser Scripts are located in the hamburger icon in the top left -> "Operations" -> BrowserScripts.
Every user has the default browser scripts automatically imported upon user creation based on which agents are installed.
Anybody can create their own browser scripts and they'll be applied only to that operator. You can also deactivate your own script so that you don't have to delete it, but it will no longer be applied to your output. This deactivates it globally and takes affect when the task is toggled open/close. For individual tasking you can use the speed dial at the bottom of the task and select to "Toggle Browserscript".
Click Register New Script
to create a new one. This is for one-off scripts you create. If you want to make it permanent across databases and for other operators, then you need to add the script to the corresponding Payload Type's container. More information about that process can be found here: #what-is-browser-scripting.
When you're creating a script, the function declaration will always be function(task, responses)
where task
is a JSON representation of the current task you're processing and responses
is an array of the responses displayed to the user. This will always be a string. If you actually returned JSON data back, be sure to run JSON.parse
on this to convert it back to a JSON dictionary. So, to access the first response value, you'd say responses[0]
.
You should always return a value. It's recommended that you do proper error checking and handling. You can check the status of the task by looking at the task
variable and checking the status
and completed
attributes.
Even if a browser script is pushed out for a command, its output can be toggled on and off individually.
This section will highlight a few of the pieces of Mythic that operators are most likely to use on a daily basis.
Browser Scripts - use JavaScript to transform your command output into tables, buttons, links, and more
Active Callbacks - the main operational page for interacting with callbacks, also allows you to see graph/tree views of your callbacks
Files - view the uploads and downloads for the operation
Search - search commands, command parameters, and command output across the operation
Credentials - view/comment/edit/add credentials for your operation
Expanded Callbacks - this allows you to view callbacks as the full screen so that you have more operational screen space
Screencaptures - all of the screencaptures throughout the operation can be viewed and downloaded here
Event Feed - view all of the events going on throughout an operation (new payloads, new callbacks, users signing in, etc) as well as a basic chat program to send messages to all operators in the operation
Unified, Persistent File Browser
The file browser is a visual, file browser representation of the directory listings that agents perform. Not all agents support this feature however.
From any callback dropdown in the "Active Callbacks" window, select "File Browser" and the view will be rendered in the lower-half of the screen. This information is a combination of the data across all of the callbacks, and is persistent.
The view is divided into two pieces - a graphical hierarchy on the left and a more detailed view of a folder on the right. The top layer on the left will be the hostname and everything below it will correspond to the file structure for that host.
You'll notice a green checkmark for the files
folder. The green checkmark means that an agent reported back information for that folder specifically (i.e. somebody tasked an ls
of that folder or issued a list
command via the button on the table side). This is in contrast the other folders in that tree - those folders are "implicitly" known because we have the full path returned for the folder we did access. If there is a red circle with an exclamation point, it means that you tried to perform an ls
on the directory, but it failed.
On the right hand side, the table view has a few pieces along the top:
The text field is the path
associated with the information below with the corresponding hostname right above it. If you haven't received any information from any agent yet or you haven't clicked on a path, this will default to the current directory .
.
The first button is the list
button. This looks at the far right hand side Callback number, finds the associated payload type, then looks for the command with file_browser:list
set in the command's supported_ui_features. Then issues that command with the host
and path
shown in the first two fields. If you want to list the contents of a directory that you can't see in the UI, just modify these two values and hit list
.
The second button is the upload
button. This will look for the file_browser:upload
set in the supported_ui_features for a command and execute that command. In most cases this will cause a popup dialog where you can upload your file.
The last field allows you to toggle viewing deleted files or not.
For each entry in the table menu on the right, there are some actions you can do by clicking the gear icon:
The file browser only shows some information that's returned. There are portions that are Operating Specific though - like UNIX permissions, extended attributes, or SDDLs. This information doesn't make sense to display in the main table, so clicking the View Permissions
action will display a popup with more specific information.
The Download History
button will display information about all the times that file has been downloaded. This is useful when you repeatedly download the same file over and over again (ex: downloading a user's Chrome Cookie's file every day). If you've downloaded a file, there will be a green download icon next to the filename. This will always point to the latest version of the file, but you can use the download history
option to view all other instances in an easy pane. This popup will also show the comments associated with the tasks that issued the download commands.
The other three are self explanatory - tasking to list a file/folder, download a file, or remove a file/folder. If a file is removed and reports back the removal to hook into the file browser, then the filename will have a small trash icon next to it and the name will have a strikethrough.
Credentials can be found from the search page on the top navigation bar or by clicking the key icon at the top.
As part of command output, credentials can be registered automatically if the agent parses out the material. Otherwise, users can also manually register credentials. There are a few pieces of information required:
The type of credential - This is more for situational awareness right now, but in the future will help the flow of how to treat the credential before use.
Account - the account this credential applies to
Realm - the domain for the credential or a generic realm in case this is a credential for something else. If the account is a local account, the Domain is the name of the computer.
Credential - the actual credential
Comment - any comment you want to store about the credential
On this page you can also see the task that created credentials (which can be Manual Entry
), who added in the credential, and when it was added.
Command parameters can hook into this by having a parameter type of CredentialJson
- the tasking UI will get a dropdown for the various credentials to choose from and your create_go_tasking
function will get a dictionary of all the credential's information.
Tasks can register credentials with the server in their responses by following format.
MITRE ATT&CK (https://attack.mitre.org/) is an amazing knowledge base of adversary techniques.
MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community.
With the creation of ATT&CK, MITRE is fulfilling its mission to solve problems for a safer world — by bringing communities together to develop more effective cybersecurity. ATT&CK is open and available to any person or organization for use at no charge.
This is in development to bring into the new user interface. This is still tracked by the back-end and available via reporting, but the ATT&CK matrix itself still needs to be ported over to the new React interface.
Commands can be automatically tagged with MITRE ATT&CK Techniques (this is what populates the "Commands by ATT&CK" output). To locate this, you just need to look at the associated python/golang files for each command.
In addition to this file defining the general properties of the command (such as parameters, description, help information, etc). There's a field called attackmapping
that takes an array of MITRE's T#
values. For example, looking at the apfell
agent's download
command:
When this command syncs to the Mythic server, those T numbers are stored and used to populate the ATT&CK Matrix. When you issue this download
command, Mythic does a lookup to see if there's any MITRE ATT&CK associations with the command, and if there are, Mythic creates entries for the "Tasks by ATT&CK" mappings. This is why you're able to see the exact command associated.
As long as you're keeping with the old MITRE ATT&CK mappings, simply add your T# to the list like shown above, then run sudo ./mythic-cli start [agent name]
. That'll restart the agent's container and trigger a re-sync of information. If the container is using golang instead of python for its Mythic connectivity, then you need to run sudo ./mythic-cli build [agent name]
instead.
Comments are a single text description that can be added to any task, file, credential, etc in an operation. All members of the operation can see and modify the comment, but the last person that adds or modifies it will show up as the one that added it.
Comments can be found in many places throughout Mythic. On almost any page where you see a task and output, you'll be able to see task comments. These comments can be added by selecting the dropdown for the task status and selecting comment. When there is a comment, you can click the chat bubble icon to show/hide them.
Comments can be removed by either clicking the red trash icon or editing the comment to be a blank string ""
.
Comments are a nice way to highlight certain tasks and output as important for later use, but just like everything else, they can easily get lost in an operation. When searching across any primary object on the search page (tasks, files, credentials, etc), you can opt to search by comment as well.
The main page to see and interactive with active callbacks can be found from the phone icon at the top of the screen.
The top table has a list of current callbacks with a bunch of identifying information. All of the table headers can be clicked to sort the information in ascending or descending order.
Callback - The identifying callback number. The blue or red button will bring the bottom section into focus, load the previously issued tasks for that callback, and populate the bottom section with the appropriate information (discussed in the next section).
If the integrity_level
of the callback is <= 2, then the callback button will be blue. Otherwise it'll be red (indicating high integrity) and there will be an *
next to the username. It's up to the agent to report back its own integrity level
Host - The hostname for the machine the callback is from
IP - The IP associated with the host
User - The current user context of the callback
PID - The process ID for the callback
OS (arch) - This is the OS and architecture information for the host
Initial Checkin - The time when the callback first checked in. This date is stored in UTC in the database, but converted to the operator's local time zone on the page.
Last Checkin - How long it's been since the last checkin in day:hour:minute:second time\
Description - The current description of the callback. The default value for this is specified by the default description
section when creating a payload. This can be changed either via the callback's dropdown.
Next to the Interact
button is a dropdown button that provides more accessible information:
Expand Callback - This opens up the callback in a separate window where you can either just view that whole callback full screen, or selectively add other callbacks to view in a split view
Edit Description - This allows you to edit the description of a callback. This will change the side description at the end and also rename the tab at the bottom when somebody clicks interact
. To set this back to the default value, interact with the callback and type set description reset
. or set this to an empty string
Hide Callback - This removes the callback from the current view and sets it to inactive. Additionally, from the Search page, you can make the callback Active
again which will bring it back into view here.
Hide Multiple - allows you to hide multiple callbacks at once instead of doing one at a time.
Process Browser - This allows you to view a unified process listing from all agents related to this host
, but issue new process listing requests from within this callback's context
Locked - If a callback is locked by a specific user, this will be indicated here (along with a changed user and lock icon instead of a keyboard on the interacting button).
File Browser - this allows you to view a process browser across all of the agents.
Task Multiple - this allows you to task multiple callbacks of the same Payload Type at once.
The bottom area is where you'll find the tasks, process listings, file browsers, and comments related to specific callbacks. Clicking the keyboard icon on a callback will open or select the corresponding tab in this area.
When you start typing a command, you can press Tab
to finish out and cycle through the matching commands. If you don't type anything and hit Tab
then you'll cycle through all available commands. You can use the up and down arrow keys to cycle through the tasking history for that callback, and you can use ctrl+r
to do a reverse grep search through your previous history as well.
Submitting a command goes through a few phases that are also color coded to help visually see the state of your task:
Preprocessing - This is when the command is submitted to Mythic, but execution is passed to the associated Payload Type's command file for processing. These capabilities are covered in more depth in the Payload Types section.
Submitted- The task has finished pre-processing and is ready for the agent to request it.
Processing - The agent has pulled down the task, but has not returned anything.
Processed - The agent has returned at least one response for the task, but hasn't explicitly marked the task as completed
Completed - The agent has reported the task done successfully
Error -The agent reported that there was an error with executing the task.
Once you've submitted tasking, there's a bit of information that'll be automatically displayed.
The user that submitted the task
The task number - You can click on this task number to view just that task and its output in a separate page. This makes it easy to share the output of a task between members of an operation.
The command and any parameters supplied by the operator
The very bottom right hand of the screen has a little filter button that you can click to filter out what you see in your callbacks. The filtering only applies as long as you're on that callback page (i.e. it gets reset when you refresh the page).
Socks proxy capabilities are a way to tunnel other traffic through another protocol. Within Mythic, this means tunneling other proxy-aware traffic through your normal C2 traffic. Mythic specifically leverages a modified Socks5 protocol without authentication (it's going through your C2 traffic afterall).
The Mythic server runs within a Docker container, and as such, you have to define which ports to expose externally. Mythic/.env
has a special environment variable you can use to expose a range of ports at a time for this exact reason - MYTHIC_SERVER_DYNAMIC_PORTS="7000-7010"
. By default this uses ports 7000-7010, but you can change this to any range you want and then simply restart Mythic to make the changes.
Click the main Search field at the top and click the "Socks" icon on the far right (or click the socks icon at the top bar).
When you issue a command to start a socks proxy with Mythic, you specify an action "start/stop" and a port number. The port number you specify is the one you access remotely and leverage with your external tooling (such as proxychains).
An operator issues a command to start socks on port 3333. This command goes to the associated payload type's container which does an RPC call to Mythic to open that port for Socks.
Mythic opens port 3333 in a go routine.
An operator configures proxychains to point to the Mythic server on port 3333.
An operator runs a tool through proxychains (ex: proxychains curl https://www.google.com
)
Proxychains connects to Mythic on port 3333 and starts the Socks protocol negotiations.
The tool sends data through proxychains, and Mythic stores it in memory. In this temporary data, Mythic assigns each connection its own ID number.
The next time the agent checks in, Mythic takes this socks data and hands it off to the agent as part of the normal Action: get_tasking or post_response process.
The agent checks if it's seen that ID before. If it has, it looks up the appropriate TCP connection and sends off the data. If it hasn't, it parses the Socks data to see where to open the connection. Then sends the resulting data and same randomID back to Mythic via Action: post_response.
Mythic gets the response, parses out the Socks specific data, and sends it back to proxychains
The above is a general scenario for how data is sent through for Socks. The Mythic server itself doesn't look at any of the data that's flowing - it simply tracks port to Callback mappings and shuttles data appropriately.
Your proxy connections are at the mercy of the latency of your C2 channel. If your checkin time is every 10s, then you'll get one message of traffic sent every 20s (round trip time). This breaks a LOT of protocols. Therefore, it's recommended that you change the sleep of your agent down to something very low (0 or as close to it).
Don't forget to change the sleep interval of your agent back to your normal intervals when you're done with Socks so that you reduce the burden on both the server and your agent.
Screenshots for an entire operation can be accessed via the camera icon in the top bar or the search page.
The screenshots display as they're coming in and will indicate how many chunks are left before you have the full image. At any point you can click on the image and view what's available so far.
Mythic allows you to track types of tags as well as instances of tags. A tag type would be something like "contains credential" or "objective 1" - these take a name, a description, and a color to be displayed to the user. An instance of a tag would then include more detailed information such as the source of the information, the actual credential contained or maybe why that thing is tagged as "objective 1", and can even include a link for more information.
Tagging allows more logical grouping of various aspects of an operation. You can create a tag for "objective 1" then apply that tag to tasks, credentials, files, keylogs, etc. This information can then be used for easier deconflictions, attack path narratives, and even a way to signal information to other members of your assessment that something might be worth while to look at.
The tag icon at the top of the screen takes you to the tag management page where you can view/edit/create various types of tags and see how many times that tag is used in the current operation.
Tags are available throughout the various Mythic pages - anywhere you see the tag icon you can view/edit/add tags.
Commands keep track of a wealth of information such as name, description, help information, if it needs admin permissions, the current version, any parameters, artifacts, MITRE ATT&CK mappings, which payload type the command corresponds to, who created or last editing the command, and when. That is a lot of information, so let’s break that down a bit.
The event feed is a live feed of all events happening within Mythic. This is where Mythic records messages for new callbacks, payload creations, users signing in/out, etc
The event feed is located at the alarm bell icon in the top right.
The event feed is a running list of all that's going on within an operation. If Mythic has an error, these will be recorded in the event log with a red background and a button to allow "resolution" of the problem. If you resolve the problem, then the background will change to green. You can also delete messages as needed:
All PayloadTypes get 2 commands for free - clear
and help
. The reason these two commands are 'free' is because they don't actually make it down to the agent itself. Instead, they cause actions to be taken on the Mythic server.
The clear command does just that - it clears tasks that are sitting in the queue waiting for an agent to pick them up. It can only get tasks that are in the submitted stage, not ones that are already to the processing stage because that means that an agent has already requested it.
clear
- entering the command just like this will clear all of the tasks in that callback are in the appropriate stages.
clear all
- entering the command just like this will clear all
tasks you've entered on that callback that are in the appropriate stages.
clear #
- entering the command just like this will attempt to clear the task indicated by the number after clear.
If a command is successfully cleared by this command before an agent can get to it, then that task will get an automated response stating that it was cleared and which operator cleared it. The clear task itself will get back a list of all the tasks it cleared.
The help
command allows users to get lists of commands that are currently loaded into the agent. Just help
gives basic descriptions, but help [command]
gives users more detailed command information. These commands look at the loaded commands for a callback and looks at the backing Python files for the command to give information about usage, command parameters, and elevation requirements.
For any active callback, select the dropdown next to it and select "Expand Callback". This will open a new tab for that callback where you can actually view the tasking full screen with metadata on the side.
Every command is different – some take no parameters, some take arrays, strings, integers, or a number of other things. To help accommodate this, you can add parameters to commands so that operators know what they need to be providing. You must give each parameter a name and they must be unique within that command. You can also indicate if the parameter is required or not.
Parameters can be in conditional parameter "groups" - this allows you to say things like parameter X and parameter Y are mutually exclusive, but you should always supply parameter W. As an operator, if there are any parameter groups for a command and you don't provide enough parameters to determine which group to use, Mythic will throw a warning and ask you to use shift + enter
to force the modal popup. From here, there's a dropdown at the top to change the group you're looking at to see which parameters to enter.
If a command takes named parameters, but none are supplied on the command line, a GUI modal will pop up to assist the operator.
There is no absolute requirement that the input parameters be in JSON format, it's just recommended.
In order to modify the command or any of its components, you need to modify the corresponding python class in the Payload Type container.
Payload types are the different kinds of agents that can be created and used with Mythic.
Payload type information is located in the C2 Profiles and Payload Types page by clicking the headphone icon in the top of the page.
From this initial high-level view, a few important pieces of information are shown:
Container status indicates if the backing container is online or offline based on certain RabbitMQ Queues existing or not. This status is checked every 5 seconds or so.
The name of the payload type which must be unique
Which operating systems the agent supports
To modify the Payload Type itself, you need to modify the corresponding class in the Payload Type's docker container. This class will extend the PayloadType class.
The documentation container contains detailed information about the commands, OPSEC considerations, supported C2 profiles, and more for each payload type when you install it. From the Payload Types page, you can click the blue document icon to automatically open up the local documentation website to that agent.
All installed docker containers are located at Mythic/InstalledServices/
each with their own folder. The currently running ones can be checked with the sudo ./mythic-cli status
. Check A note about containers for more information about them.
Containers allow Mythic to have each Payload Type establish its own operating environment for payload creation without causing conflicting or unnecessary requirements on the host system.
Payload Type containers only come into play for a few special scenarios:
Payload Creation
Tasking
Processing Responses
For more information on editing or creating new containers for payload types, see Payload Type Development.
Command and Control (C2) profiles are the way an agent actually communicates with Mythic to get tasking and post responses. There are two main pieces for every C2 profile:
Server code - code that runs in a docker container to convert the C2 profile communication specification (twitter, slack, dropbox, websocket, etc) into the corresponding RESTful endpoints that Mythic uses
Agent code - the code that runs in a callback to implement the C2 profile on the target machine.
C2 profiles can be found by going to Payload Types and C2 Profiles (headphone icon) from the top navigational bar.
Each C2 profile is in its own docker container, the status of which is indicated on the C2 Profiles page.
Each docker container has a python or golang service running in it that connects to a RabbitMQ message broker to receive tasking. This allows Mythic to modify files, execute programs, and more within other docker containers.
The documentation container contains detailed information about the OPSEC considerations, traffic flow, and more for each container when you install the c2 profile. From the C2 Profiles page, you can click the blue document icon to automatically open up the local documentation website to that profile.
There are two kinds of C2 profiles - egress profiles that talk directly out of the target network or peer-to-peer (p2p) profiles that talk to neighboring agents.
The default HTTP and the dynamicHTTP profiles are both examples of egress profiles. They talk directly out of the target network. Egress profiles have associated Docker containers that allow you to do the translation between your special sauce c2 profile and the normal RESTful web requests to the main Mythic server. More information on how this works and how to create your own can be found here: C2 Related Development.
Peer-to-peer profiles in general are a bit different. They don't talk directly out to the internet; instead, they allow agents to talk to each other.
This distinction between P2P and Egress for Mythic is made by a simple boolean indicating the purpose of the c2 container.
P2P profiles announce their connections to Mythic via P2P Connections. When Mythic gets these messages, it can start mapping out what the internal mesh looks like. To help view this from an operator perspective, there is an additional views on the main Callbacks page.
This view uses a directed graph to illustrate the connections between the agents. There's a central "Mythic Server" node that all egress agents connect to. When a route is announced, the view is updated to move one of the callbacks to be a child of another callback.
MITRE ATT&CK is a great way to track what both offense and defense are doing in the information security realm. To help Mythic operators keep track, each command can be tagged with its corresponding MITRE ATT&CK information:
There can be as many or as few mappings as desired for each command. This information is used in two different ways, but both located in the MITRE ATT&CK button at the top.
The "Fetch All Commands Mapped to MITRE" button takes this information to populate out what is the realm of possible
with all of the payload types and commands registered within Mythic. This gives a coverage map of what could be done. Clicking each matrix cell gives a breakdown of which commands from which payload types achieve that objective:
The "Fetch All Issued Tasks Mapped to MITRE" only shows this information for commands that have already been executed in the current operation. This shows what's been done, rather than what's possible. Clicking on a cell with this information loaded gives the exact task and command arguments that occurred with that task:
The "HTTP" C2 profile speaks the exact same protocol as the Mythic server itself. All other C2 profiles will translate between their own special sauce back to this format. This profile has a docker container as well that you can start that uses a simple JSON configuration to redirect traffic on another port (with potentially different SSL configurations) to the main Mythic server.
This container code starts a small Golang gin web server that accepts messages on the specified port and proxies all connections to the /agent_message
endpoint within Mythic. This allows you to host the Mythic instance on port 7443 for example and expose the default HTTP profile on port 443 or 80.
Clicking the "Configure" button gives a few options for how to edit and interact with the profile.
If you want to use SSL with this profile, edit the configuration to use_ssl
to true
and the C2 profile will automatically generate some self-signed certificates. If you want to use your own certificates though, you can upload them through the UI by clicking the "Manage Files" button next to the http
profile and uploading your files. Then simply update the configuration with the names of the files you uploaded.
This sections allows you to see some information about the C2 profile, including sample configurations.
The name of a C2 profile cannot be changed once it's created, but everything else can change. The Supported Payloads
shows which payload types can speak the language of this C2 profile.
This dialog displays the current parameters associated with the C2 profile. These are the values you must supply when using the C2 profile to create an agent.
There are a few things to note here:
randomize
- This specifies if you want to randomize the value that's auto-populated for the user.
format_string
- This is where you can specify how to generate the string in the hint when creating a payload. For example, setting randomize
to true
and a format_string
of \d{10}
will generate a random 10 digit integer.
This can be seen with the same test
parameter in the above screenshot.
Every time you view the parameters, select to save an instance of the parameters, or go to create a new payload, another random instance from this format_string will be auto-populated into that c2 profile parameter's hint field.
C2 Profiles can optionally provide some operational security checks before allowing a payload to be created. For example, you might want to prevent operators from using a known-bad named pipe name, or you might want to prevent them from using infrastructure that you know is burned.
These checks all happen within a single function per C2 profile with a function called opsec
:
From the code snippet above, you can see that this function gets in a request with all of the parameter values for that C2 Profile that the user provided. You can then either return success or error with a message as to why it passed or why it failed. If you return the error case, then the payload won't be built.
C2 servers know the most about their configuration. You can pass in the configuration for an agent and check it against the server's configuration to make sure everything matches up or get additional insight into how to configure potential redirectors.
C2 servers know the most about how their configurations work. You can pass in an agent's configuration and get information about how to generate potential redirector rules so that only your agent's traffic makes it through.
API tokens are special JSON web tokens (JWTs) that Mythic can create per-user that don't expire automatically. This allows you to do long-term scripting capabilities without having to periodically check if your current access-token is expired, going through the refresh process, and then continuing along with whatever you were doing.
They're located in your settings page (click your name in the top right and click settings).
When making a request with an API token, set the Header
of apitoken
with a value of your API token. This is in contrast to normal JWT usage where the header is Authorization
and the value is Bearer: <token here>
.