What is it?

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.

Where is it?

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.

How does this Task mapping happen?

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 files for each command:

/Mythic/Payload_Types/[agent name]/mythic/agent_functions[cmd_name].py

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:

class DownloadCommand(CommandBase):
    cmd = "download"
    needs_admin = False
    help_cmd = "download {path to remote file}"
    description = "Download a file from the victim machine to the Mythic server in chunks (no need for quotes in the path)."
    version = 1
    author = "@its_a_feature_"
    parameters = []
    attackmapping = ["T1020", "T1030", "T1041"]
    argument_class = DownloadArguments
    browser_script = BrowserScript(script_name="download", author="@its_a_feature_")

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.

How do I update this to add/remove mappings?

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 payload start [agent name]. That'll restart the agent's container and trigger a re-sync of information.

MITRE Added Sub-Techniques, where are they?

Good point. The current Mythic instance doesn't support the new sub technique view or mapping scheme. It's on the roadmap to incorporate now that MITRE finalized the structure.

Setup

1. Install Mythic following the normal installation

2. With Mythic running, install any other agents or profiles you might need/want.

sudo ./mythic-cli install github https://github.com/MythicAgents/Apollo

3. Export your docker containers. Make sure you also save the tags.

docker save $(docker images -q) -o mythic_images.tar
docker images | sed '1d' | awk '{print $1 " " $2 " " $3}' > mythic_tags

4. Download donut from pypi. (this is apollo specific, so there might be others depending on your agent)

mkdir Payload_Types/apollo/depends
pip3 download donut -d Payload_Types/apollo/depends

Download Apollo dependencies (apollo specifically installs these dynamically within the Docker container at build-time, so pre-fetch these)

 wget https://www.nuget.org/api/v2/package/Fody/2.0.0 -O Payload_Types/apollo/depends/fody.2.0.0.nupkg
 wget https://www.nuget.org/api/v2/package/Costura.Fody/1.6.2 -O Payload_Types/apollo/depends/costura.fody.1.6.2.nupkg

5. Tar Mythic directoy.

tar cfz mythic.tar.gz /Mythic

6. Push mythic_images.tar, mythic_tags, and mythic.tar.gz to your offline box.

7. Import docker images and restore tags.

docker load -i mythic_images.tar
while read REPOSITORY TAG IMAGE_ID; do echo "== Tagging $REPOSITORY $TAG $IMAGE_ID =="; docker tag "$IMAGE_ID" "$REPOSITORY:$TAG"; done < mythic_tags

8. Extract Mythic directory.

tar xfz mythic.tar.gz
cd mythic

9. Update Apollo's Dockerfile (at the time of use, it might not be 0.1.1 anymore, check #current-payloadtype-versions the latest). This is apollo specific, so you might need to copy in pieces for other agents/c2 profiles depending on what components they dynamically try to install.

from itsafeaturemythic/csharp_payload:0.1.1

COPY ["depends/donut-0.2.2.tar.gz", "donut-0.2.2.tar.gz"]
COPY ["depends/costura.fody.1.6.2.nupkg", "costura.fody.1.6.2.nupkg"]
COPY ["depends/fody.2.0.0.nupkg", "fody.2.0.0.nupkg"]

RUN /usr/local/bin/python3.8 -m pip install /donut-0.2.2.tar.gz
RUN mkdir /mythic_nuget
RUN nuget sources add -name mythic_nuget -source /mythic_nuget
RUN nuget sources disable -name nuget.org
RUN nuget add /fody.2.0.0.nupkg -source /mythic_nuget
RUN nuget add /costura.fody.1.6.2.nupkg -source /mythic_nuget

10. Start Mythic

sudo ./mythic-cli start

Granular Documentation

Mythic provides an additional docker container that serves static information about the agents and c2 profiles. In the main Mythic/.env file you'll see which port you wan to run this on via the "DOCUMENTATION_PORT" key. You don't need to worry about this port too much since Mythic uses an Nginx reverse proxy to transparently proxy connections back to this container based on the web requests you make.

Accessing the Documentation

The documentation stands up a Golang HTTP server based on Hugo (it's HTTP, not HTTPS). It reads all of the markdown files in the /Mythic/documentation-docker/ folder and creates a static website from it. For development purposes, if you make changes to the markdown files here, the website will automatically update in real time. From the Mythic UI if you hit /docs/ then you'll be directed automatically to the main documentation home page.

Get the code

Pull the code from the official GitHub repository:

$ git clone https://github.com/its-a-feature/Mythic

Make the mythic-cli

All configuration is done via the mythic-cli binary. However, to help with GitHub sizes, the mythic-cli binary is no longer distributed with the main Mythic repository. Instead, you will need to make the binary via sudo make from the main Mythic folder. This will create the build container for the mythic-cli, build the binary, and copy it into your main Mythic folder automatically. From there on, you can use the mythic-cli binary like normal.

Configure your installation

Mythic configuration is all done via Mythic/.env, which means for your configuration you can either add/edit values there or add them to your environment.

If you need to run mythic-cli as root for Docker and you set your environment variables as a user, be sure to run sudo -E ./mythic-cli so that your environment variables are carried over into your sudo call. The following are the default values that Mythic will generate on first execution of sudo ./mythic-cli mythic start unless overridden:

ALLOWED_IP_BLOCKS="0.0.0.0/0"
COMPOSE_PROJECT_NAME="mythic"
DEBUG_LEVEL="warning"
DEFAULT_OPERATION_NAME="Operation Chimera"
DOCUMENTATION_BIND_LOCALHOST_ONLY="true"
DOCUMENTATION_HOST="mythic_documentation"
DOCUMENTATION_PORT="8090"
HASURA_BIND_LOCALHOST_ONLY="true"
HASURA_CPUS="2"
HASURA_EXPERIMENTAL_FEATURES="streaming_subscriptions"
HASURA_HOST="mythic_graphql"
HASURA_PORT="8080"
HASURA_SECRET="random password"
INSTALLED_SERVICE_CPUS="1"
JUPYTER_BIND_LOCALHOST_ONLY="true"
JUPYTER_HOST="mythic_jupyter"
JUPYTER_PORT="8888"
JUPYTER_TOKEN="mythic"
JWT_SECRET="random password"
MYTHIC_ADMIN_PASSWORD="random password"
MYTHIC_ADMIN_USER="mythic_admin"
MYTHIC_DEBUG_AGENT_MESSAGE="false"
MYTHIC_REACT_BIND_LOCALHOST_ONLY="true"
MYTHIC_REACT_HOST="mythic_react"
MYTHIC_REACT_PORT="3000"
MYTHIC_SERVER_BIND_LOCALHOST_ONLY="true"
MYTHIC_SERVER_COMMAND=
MYTHIC_SERVER_DYNAMIC_PORTS="7000-7010"
MYTHIC_SERVER_GRPC_PORT="17444"
MYTHIC_SERVER_HOST="mythic_server"
MYTHIC_SERVER_PORT="17443"
NGINX_BIND_LOCALHOST_ONLY="false"
NGINX_HOST="mythic_nginx"
NGINX_PORT="7443"
NGINX_USE_SSL="true"
POSTGRES_BIND_LOCALHOST_ONLY="true"
POSTGRES_CPUS="2"
POSTGRES_DB="mythic_db"
POSTGRES_DEBUG="false"
POSTGRES_HOST="mythic_postgres"
POSTGRES_PASSWORD="random password"
POSTGRES_PORT="5432"
POSTGRES_USER="mythic_user"
RABBITMQ_BIND_LOCALHOST_ONLY="true"
RABBITMQ_CPUS="2"
RABBITMQ_HOST="mythic_rabbitmq"
RABBITMQ_PASSWORD="random password"
RABBITMQ_PORT="5672"
RABBITMQ_USER="mythic_user"
RABBITMQ_VHOST="mythic_vhost"
REBUILD_ON_START="true"

A few important notes here:

• MYTHIC_SERVER_PORT will be the port opened on the server where you're running Mythic. The NGINX_PORT is the one that's opened by Nginx and acts as a reverse proxy to all other services. The NGINX_PORT is the one you'll connect to for your web user interface and should be the only port you need to expose externally (unless you prefer to SSH port forward your web UI port).

• The allowed_ip_blocks allow you to restrict access to the login page of Mythic. This should be set as a series of netblocks with NO host bits set - i.e. 127.0.0.0/16,192.168.10.0/24,10.0.0.0/8

• *_BIND_LOCALHOST_ONLY - these settings determine if the associated container binds the port to 127.0.0.1:port or 0.0.0.0:port. These are all set to true (except for the nginx container) by default so that you're not exposing these services externally.

When the mythic_server container starts for the first time, it goes through an initialization step where it uses the password and username from Mythic/.env to create the mythic_admin_user user. Once the database exists, the mythic_server container no longer uses that value.

mythic-cli

The mythic-cli binary is used to start/stop/configure/install components of Mythic. You can see the help menu at any time with mythic-cli -h, mythic-cli --help or mythic-cli help.

Mythic CLI is a command line interface for managing the Mythic
application and associated containers and services. Commands are grouped by their use.

Usage:
  mythic-cli [command]

Available Commands:
  add         Add local service folder to docker compose
  build       Build/rebuild a specific container
  config      Display or adjust the configuration
  database    interact with the database
  help        Help about any command
  install     install services from GitHub or local folders
  logs        Get docker logs from a running service
  mythic_sync work to mythic_sync install/uninstall
  rabbitmq    interact with the rabbitmq
  remove      Remove local service folder from docker compose
  restart     Start all of Mythic
  start       Start Mythic containers
  status      Get current Mythic container status
  stop        Stop all of Mythic
  test        test mythic service connections
  uninstall   uninstall services locally and remove them from disk

Flags:
  -h, --help   help for mythic-cli

Use "mythic-cli [command] --help" for more information about a command.

Installing Agents / C2 Profiles

By default, Mythic does not come with any Payload Types (agents) or C2 Profiles. This is for a variety of reasons, but one of the big ones being time/space requirements - all Payload Types and C2 Profiles have their own Docker containers, and as such, collectively they could eat up a lot of space on disk. Additionally, having them split out into separate repositories makes it much easier to keep them updated.

Available Mythic Agents can be found on GitHub at https://github.com/MythicAgents

Available Mythic C2 Profiles can be found on GitHub at https://github.com/MythicC2Profiles

To install a Payload Type or C2 Profile, use the mythic-cli binary with:

sudo ./mythic-cli install github <url>

If you have an agent already installed, but want to update it, you can do the same command again. If you supply a -f at the end, then Mythic will automatically overwrite the current version that's installed, otherwise you'll be prompted for each piece.

Logging

If you're wanting to enable SIEM-based logging, install the basic_logger via the mythic cli sudo ./mythic-cli install github https://github.com/MythicC2Profiles/basic_logger. This profile listens to the emit_log RabbitMQ queue and allows you to configure how you want to save/modify the logs. By default they just go to stdout, but you can configure it to write out to files or even submit the events to your own SIEM.

file_upload (file staged on mythic as part of tasking with the intent to get sent to the agent)
file_manual_upload (file staged on mythic as part of a user manually hosting it)
file_screenshot (file is a screenshot from the agent)
file_download (file is downloaded from agent to mythic)
artifact_new (new artifact created - think IOC)
eventlog_new (new eventlog message)
eventlog_modified (eventlog was modified, like resolving an issue or changing their message)
payload_new (new payload created)
task_mitre_attack (a task was associated with a new mitre attack technique)
task_new (a new task was created)
task_completed (a task completed)
task_comment (somebody added/removed/edited a comment on a task)
credential_new (a new credential was added to the store)
credential_modified (a credential was modified)
response_new (a new response for the user to see)
keylog_new (a new keylog entry)
callback_new (new callback registered)

Start Mythic

If you came here right from the previous section, your Mythic instance should already be up and running. Check out the next section to confirm that's the case. If at any time you wish to stop Mythic, simply run sudo ./mythic-cli stop and if you want to start it again run sudo ./mythic-cli start. If Mythic is currently running and you need to make a change, you can run sudo ./mythic-cli restart again without any issue, that command will automatically stop things and then restart them.

The default username is mythic_admin, but that user's password is randomly generated when Mythic is started for the first time. You can find this random value in the Mythic/.env file. Once Mythic has started at least once, this value is no longer needed, so you can edit or remove this entry from the Mythic/.env file.

Troubleshooting installation and connection

If something seems off, here's a few places to check:

• Run sudo ./mythic-cli status to give a status update on all of the docker containers. They should all be up and running. If one is exited or has only been up for less than 30 seconds, that container might be your issue. All of the Mythic services will also report back a health check which can be useful to determine if a certain container is having issues. The status command gives a lot of information about what services are running, on which ports, and if they're externally accessible or not.

MYTHIC SERVICE		WEB ADDRESS		BOUND LOCALLY
Nginx (Mythic Web UI)	https://127.0.0.1:7443	 false
Mythic Backend Server	http://127.0.0.1:17443	 false
Hasura GraphQL Console	http://127.0.0.1:8080	 true
Jupyter Console		http://127.0.0.1:8888	 true
Internal Documentation	http://127.0.0.1:8090	 true
								
ADDITIONAL SERVICES	IP			PORT	BOUND LOCALLY
Postgres Database	127.0.0.1		5432	 false
React Server		192.168.53.152		3000	 true
RabbitMQ		127.0.0.1		5672	 false
								
				
Mythic Main Services
CONTAINER NAME		STATE		STATUS					PORTS
mythic_documentation	running		Up 38 seconds (healthy)			8090/tcp -> 127.0.0.1:8090
mythic_graphql		running		Up 36 seconds (healthy)			8080/tcp -> 127.0.0.1:8080
mythic_jupyter		running		Up 41 seconds (healthy)			8888/tcp -> 127.0.0.1:8888
mythic_nginx		running		Up 35 seconds (healthy)			7443/tcp -> :::7443, 7443
mythic_postgres		running		Up 39 seconds (healthy)			5432/tcp -> :::5432, 5432
mythic_rabbitmq		running		Up 40 seconds (health: starting)	5672/tcp -> :::5672, 5672
mythic_server		running		Up 37 seconds (health: starting)	7000/tcp -> :::7000, 7001/tcp -> :::7001, 7002/tcp -> :::7002, 7003/tcp -> :::7003, 7004/tcp -> :::7004, 7005/tcp -> :::7005, 7006/tcp -> :::7006, 7007/tcp -> :::7007, 7008/tcp -> :::7008, 7009/tcp -> :::7009, 7010/tcp -> :::7010, 17443/tcp -> :::17443, 17444/tcp -> :::17444, 7000, 7001, 7002, 7003, 7004, 7005, 7006, 7007, 7008, 7009, 7010, 17443, 17444
											
Installed Services
CONTAINER NAME		STATE		STATUS		PORTS
no_translator		running		Up 43 seconds	
service_wrapper		running		Up 42 seconds	

• To check the logs of any container, run sudo ./mythic-cli logs [container_name]. For example, to see the output of mythic_server, run sudo ./mythic-cli logs mythic_server. This will help track down if the last thing that happened was an error of some kind.

• If all of that looks ok, but something still seems off, it's time to check the browser.

  • First open up the developer tools for your browser and see if there are any errors that might indicate what's wrong. If there's no error though, check the network tab to see if there are any 404 errors.

  • If that's not the case, make sure you've selected a current operation (more on this in the Quick Usage section). Mythic uses websockets that pull information about your current operation to provide data. If you're not currently in an active operation (indicated at the top of your screen in big letters), then Mythic cannot provide you any data.

Container Sizes

Mythic starts every service (web server, database, each payload type, each C2 profile, rabbitmq, documentation) in its own Docker container. As much as possible, these containers leverage common image bases to reduce size, but due to the nature of so many components, there's going to be a decent footprint. For consideration, here's the Docker footprint for a fresh install of Mythic:

its-a-feature@ubuntu:$ sudo docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          9         9         9.62GB    6.263GB (65%)
Containers      9         9         399.6kB   0B (0%)
Local Volumes   17        0         2.964MB   2.964MB (100%)
Build Cache     0         0         0B        0B

its-a-feature@ubuntu:$ sudo docker system df -v
Images space usage:

REPOSITORY             TAG       IMAGE ID       CREATED         SIZE      SHARED SIZE   UNIQUE SIZE   CONTAINERS
mythic_server          latest    b11659fb912a   4 minutes ago   6.889GB   6.256GB       632.5MB       1
no_translator          latest    b9e63f1a0097   14 hours ago    6.58GB    6.256GB       323.5MB       1
service_wrapper        latest    7c508916bc3e   14 hours ago    6.581GB   6.256GB       324.5MB       1
mythic_jupyter         latest    96255e6737c4   18 hours ago    996.6MB   0B            996.6MB       1
mythic_postgres        latest    9a351f9bc9ef   18 hours ago    243.1MB   7.05MB        236.1MB       1
mythic_documentation   latest    ed947afb8c27   18 hours ago    54.36MB   0B            54.36MB       1
mythic_graphql         latest    820890c9b0ad   2 weeks ago     621.8MB   0B            621.8MB       1
mythic_nginx           latest    da7a4011c460   3 weeks ago     40.72MB   7.05MB        33.67MB       1
mythic_rabbitmq        latest    07d9eda5cc97   19 months ago   133.3MB   0B            133.3MB       1

Containers space usage:

CONTAINER ID   IMAGE                  COMMAND                  LOCAL VOLUMES   SIZE      CREATED         STATUS                   NAMES
08e5869c4b8a   mythic_postgres        "docker-entrypoint.s…"   0               63B       4 minutes ago   Up 3 minutes (healthy)   mythic_postgres
1bc0306aa920   mythic_graphql         "docker-entrypoint.s…"   0               378kB     4 minutes ago   Up 3 minutes (healthy)   mythic_graphql
41e982d38a14   mythic_nginx           "/docker-entrypoint.…"   0               2B        4 minutes ago   Up 3 minutes (healthy)   mythic_nginx
a0f1df25e66b   mythic_documentation   "hugo server -p 8090"    0               0B        4 minutes ago   Up 3 minutes (healthy)   mythic_documentation
a98ba7b3aa64   mythic_jupyter         "tini -g -- start.sh…"   0               21.2kB    4 minutes ago   Up 4 minutes (healthy)   mythic_jupyter
9d92d8397a87   mythic_rabbitmq        "docker-entrypoint.s…"   0               756B      4 minutes ago   Up 3 minutes (healthy)   mythic_rabbitmq
871405214da0   service_wrapper        "/bin/sh -c 'make ru…"   0               0B        4 minutes ago   Up 4 minutes             service_wrapper
3f7a4f72a82d   no_translator          "/bin/sh -c 'make ru…"   0               0B        4 minutes ago   Up 4 minutes             no_translator
79295b4bc031   mythic_server          "/bin/bash -c 'cp /m…"   0               0B        4 minutes ago   Up 3 minutes (healthy)   mythic_server

Local Volumes space usage:

VOLUME NAME                                                        LINKS     SIZE
1bdf5e715217e03b9e10e33b7c7e55e1ddb8898c9da53da5fc42b72c77e05ea3   0         0B
473660a24b907ce4194806b0584c236964d2b0fe0e8690057d470eaee8fcbe97   0         0B
jupyter                                                            0         2.911MB
12f257df33085912785808aa5b1e4c29910ae4ddcad498b933763668263f770d   0         93B
780ee9b1d726ac35d5ef0d2ff19f155d0e2bff437f522d6fbe984499a27c6202   0         0B
9de90d6f8308c2cc9c19043373b4f9f45d000b7ecea8b3682df224e8f9a79ada   0         0B
d0776a4a8e535a9d35f444413be020d51f0cdfd473c773c5127b5d31d95bdb61   0         0B
dbcfcf81791e768acb83c811de9d3e57172c727f83f92f8b4d7f6de4a39e84d1   0         52.77kB
documentation-docker                                               0         166B
0cd941f7e6b4b25ab1e13f1d575f2f1caaacb4664eaa9d6c404ad2347554a7fb   0         0B
cefb153314333ecb272945798c1225a5545159ae41aa92aeaa912fe017882ba8   0         93B
9c870d0f01bcbc303eb6fbf4a5a1e1bdd2c70854c02c737bb0542c5f56c0c040   0         0B
cfaacc90b7b34bdce1ed35481cab48540e6f58fd948b4bc59c5a18ecd87e00c9   0         0B
fd69883c79fe52f5108558f84b8989943b47406ac96de68c555ac7cbebb1a66b   0         0B
fe82f2f0c818cbe678db9015aebaae811fcb88e55c5039d3b8d8e82034c1b18a   0         93B
mythic                                                             0         88B
1c181b8dbadf04787e4e3faeab9b7a863d3c78a462068e9165ce4da258c31564   0         0B

Build cache usage: 0B

If you want to save space or if you know you're not going to be using a specific container, you can remove that container from docker-compose with sudo ./mythic-cli remove [container name]

Mythic and containers

Mythic uses docker containers to logically separate different components and functions. There are three main categories:

1. Mythic's main core. This consists of docker containers stood up with docker-compose:

   1. mythic_server - An GoLang gin webserver instance

   2. mythic_postgres - An instance of a postgresql database

   3. mythic_rabbitmq - An instance of a rabbitmq container for message passing between containers

   4. mythic_nginx - A instance of a reverse Nginx proxy

   5. mythic_graphql - An instance of a Hasura GraphQL server

   6. mythic_jupyter - An instance of a Jupyter notebook

   7. mythic_documentation - An instance of a Hugo webserver for localized documentation

2. Installed Services

   1. Any folder in Mythic/InstalledServices will be treated like a docker container (payload types, c2 profiles, webhooks, loggers, translation containers, etc)

To stop a specific container, run sudo ./mythic-cli stop {c2_profile_name} .

If you want to reset all of the data in the database, use sudo ./mythic-cli database reset.

If you want to start/restart any specific payload type container, you can do sudo ./mythic-cli start {payload_type_name} and just that container will start/restart. If you want to start multiple, just do spaces between them: sudo ./mythic-cli start {container 1} {container 2}.

Docker-compose

All of Mythic's containers share a single docker-compose file. When you install an agent or C2 Profile this docker-compose file will automatically be updated. However, you can always add/remove from this file via mythic-cli and list out what's registered in the docker-compose file vs what you have available on your system:

This makes it easy to track what's available to you and what you're currently using.

Architecture

Mythic's architecture is broken out in the following diagram:

Operators connect via a browser to the main Mythic server, a GoLang gin web server. This main Mythic server connects to a PostgreSQL database where information about the operations lives. Each of these are in their own docker containers. When Mythic needs to talk to any payload type container or c2 profile container, it does so via RabbitMQ, which is in its own docker container as well.

When an agent calls back, it connects through these c2 profile containers which have the job of transforming whatever the c2 profile specific language/style is back into the normal RESTful API calls that the Mythic server needs.

Mythic Container Locations

There is currently a base container that contains Python 3.11, Mono, .Net Core 7.0, Golang 1.20, and the macOS 12.1 SDK. More containers will be added in the future, but having the base containers pre-configured on DockerHub speeds up install time for operators.

How to update Mythic to a new version

In the Mythic UI, you can click the hamburger icon (three horizontal lines) in the top left to see the current Server version and UI version.

There are two scenarios to updating Mythic: updates within the minor version (1.4.1 to 1.4.2) and updates to the minor (1.4.1 to 1.5) or major version (1.4 to 2.0).

Updating within the minor version

This is when you're on version 1.2 for example and want to pull in new updates (but not a new minor version like 1.3 or 1.4). In this case, the database schema should not have changed.

1. Pull in the latest code for your version (if you're still on the current version, this should be as easy as a git pull)

2. Make a new mythic-cli binary with sudo make

3. Restart Mythic to pull in the latest code changes into the docker containers with sudo ./mythic-cli mythic start

Updating minor or major versions

This is when you're on version 1.2 for example and want to upgrade to version 1.3 or 2.1 for example. In this case, the database schema has changed.

1. Reset the database with sudo ./mythic-cli database reset

2. Make sure Mythic is stopped, sudo ./mythic-cli stop

3. Purge all of your containers, sudo docker system prune -a

4. Pull in the version you want to upgrade to (if you're wanting to upgrade to the latest, it's as easy as git pull)

5. Delete your Mythic/.env file - this file contains all of the per-install generated environment variables. There might be new environment variables leveraged by the updated Mythic, so be sure to delete this file and a new one will be automatically generated for you.

6. Restart Mythic to pull in the latest code changes into the docker containers with sudo ./mythic-cli start

Updating Agent or C2 Profile services

Agents and C2 Profiles are hosted in their own repositories, and as such, might have a different update schedule than the main Mythic repo itself. So, you might run into a scenario where you update Mythic, but now the current Agent/C2Profiles services are no longer supported.

You'll know if they're no longer supported because when the services check in, they'll report their current version number. Mythic has a range of supported version numbers for Agents, C2 Profiles, Translation services, and even scripting. If something checks in that isn't in the supported range, you'll get a warning notification in the UI about it.

To update these (assuming that the owner/maintainer of that Agent/C2 profile has already done the updates), simply stop the services (sudo ./mythic-cli stop agentname or sudo ./mythic-cli stop profileName) and run the install command again. The install command should automatically determine that a previous version exists, remove it, and copy in the new components. Then you just need to either start those individual services, or restart mythic overall.

By default, the server will bind to 0.0.0.0 on port 7443 with a self-signed certificate(unless otherwise configured). This IP is an alias meaning that it will be listening on all IPv4 addresses on the machine. Browse to either https://127.0.0.1:7443 if you’re on the same machine that’s running the server, or you can browse to any of the IPv4 addresses on the machine that’s running the server.

• Browse to the server with any modern web browser. You will be automatically redirected to the /login url. This url is protected by allowed_ip_blocks .

• The default username is mythic_admin and the default password is randomized. The password is stored in Mythic/.env after first launch, but you can also view it with sudo ./mythic-cli config get MYTHIC_ADMIN_PASSWORD. You can opt to set this before you initially start if you want (or you can change this later through the UI) by setting that environment variable before staring Mythic for the first time.

Mythic uses JSON Web Tokens (JWT) for authentication. When you use the browser (vs the API on the command line), Mythic stores your access and refresh tokens in a cookie as well as in the local session storage. This should be seamless as long as you leave the server running; however, the history of the refresh tokens is saved in memory. So, if you authenticate in the browser, then restart the server, you’ll have to sign in again.

Your connection is not private Warning

If you're using Chrome and a self-signed certificate that's default generated by Mythic, you will probably see a warning like this when you try to connect:

This is fine and expected since we're not using a LetsEncrypt or a proper domain certificate. To get around this, simply click somewhere within the window and type thisisunsafe. Your browser will now Temporarily accept the cert and allow you through.

At some point in the future, your browser will decide to remind you that you're using a self-signed certificate. Mythic cannot actually read this error message due to Chrome's security policies. When this happens, simply refresh your page. You'll be brought back to the same big warning page as the image above and you can type thisisunsafe again to continue your operations.

What is Mythic?

Mythic is a multiplayer, command and control platform for red teaming operations. It is designed to facilitate a plug-n-play architecture where new agents, communication channels, and modifications can happen on the fly. Some of the Mythic project's main goals are to provide quality of life improvements to operators, improve maintainability of agents, enable customizations, and provide more robust data analytic capabilities to operations.

Fundamentally, Mythic uses a web-based front end (React) and Docker containers for the back-end. A GoLang server handles the bulk of the web requests via GraphQL APIs and WebSockets. This server then handles connections to the PostgreSQL database and communicates to the other Docker containers via RabbitMQ. This enables the individual components to be on separate physical computers or in different virtual machines if desired.

A helpful view of the current state of the C2 Profiles and Agents for Mythic can be found here:

A reverse Nginx proxy provides a single port to connect through to reach back-end services. Through this reverse proxy, operators can connect to:

• React UI

• Hugo documentation container (documentation on a per-agent and per-c2 profile basis)

• Hasura GraphQL console (test GraphQL queries, explore/modify the database)

• Jupyter Notebook (with Mythic Scripting pre-installed and pre-created examples)

Why use Mythic?

Data modeling, tracking, and analysis are core aspects of Mythic's ability to provide quality of life improvements to operators. From the very beginning of creating a payload, Mythic tracks the specific command and control profile parameters used, the commands loaded into the payload and their versions, who created it, when, and why. All of this is used to provide a more coherent operational view when a new callback checks in. Simple questions such as “which payload triggered this callback”, "who issued this task", and even “why is there a new callback” now all have contextual data to give answers. From here, operators can start automatically tracking their footprints in the network for operational security (OpSec) concerns and to help with deconflictions. All agents and commands can track process creates, file writes, API calls, network connections, and more. These artifacts can be automatically recorded when the task is issued or even reported back by agents as they happen.

Mythic also incorporates MITRE ATT&CK mappings into the standard workflow. All commands can be tagged with ATT&CK techniques, which will propagate to the corresponding tasks issued as well. In a MITRE ATT&CK Matrix view (and ATT&CK Navigator view), operators can view coverage of possible commands as well as coverage of commands issued in an operation. Operators can also provide comments on each task as they operate to help make notes about why a task was important. Additionally, to make deconfliction and reporting easier, all commands, output, and comments can be globally searched through the main web interface.

Resources and Contributing

• Check out the code on GitHub: https://github.com/its-a-feature/Mythic

• Join the #Mythic channel in the BloodHound public slack https://bloodhoundgang.herokuapp.com/

• Reach out on Twitter: @its_a_feature_

Mythic is meant to be used by multiple operators working together to accomplish operations. That typically means there's a lead operator, multiple other operators, and potentially people that are just spectating. Let's see how operators come into play throughout Mythic.

Passwords & Authentication

Every user has their own password for authenticating to Mythic. On initial startup, one account is created with a password specified via the MYTHIC_ADMIN_PASSWORD environment variable or by creating a Mythic/.env file with MYTHIC_ADMIN_PASSWORD=passwordhere entry. This account can then be used to provision other accounts (or they can be created via the ability). If the admin password isn't specified via the environment variable or via the Mythic/.env file, then a random password is used. This password is only used on initial setup to create the first user, after that this value is no longer used.

Every user's password must be at least 12 characters long. If somebody tries to log in with an unknown account, all operations will get a notification about it. Similarly, if a user fails to log into their account 10 times in a row, the account will lock. The only account that will not lock out is that initial account that's created. Instead, that account will throttle authentication attempts to 1 a minute.

Operator Permissions

There are a few different kinds of operator permissions throughout Mythic.

• Admin - This is a global setting that grants users the ability to see all operations, unlock all callbacks, and interact with everything in Mythic. The only account that has this initially is the first account created and only Admin accounts can grant other admin accounts this level of permission. Similarly, only admin accounts can remove admin permissions from other admin accounts.

• Operation Admin - This is the lead of a specific operation. The operation admin can unlock anybody else's callback, can bypass any opsec check, and has full rights over that operation.

• Operator - This is the normal permissions for a user. They can be added to operations by Admins or by the Operation Admin, and within an operation, they can bypass opsec checks for operators and only unlock the callbacks they locked.

• Spectator - This account permission has no permissions to make any modifications within Mythic for their operation. They can still query and see all tasks/responses/artifacts/etc within an operation, but they cannot issue tasks, lock callbacks, create payloads, etc.

Where is it?

The operational search feature can be found by clicking the top "search" icon. From here you can search across callbacks, tasks, files, screenshots, keylogs, tokens, artifacts, and more.

How is it used?

The search bar checks for what you type as a case insensitive grep.

What are they?

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.

Where are they?

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.

How are they applied?

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".

If you are an overall admin or the lead of this operation, then you can optionally Apply the script to the operation. This forces your script to apply to the output of everybody's command in the operation and will override anybody else's script that would otherwise be applied. If you are curious as to whether your script will be in effect or not, the In Effect column indicates this.

The bottom table shows all of the scripts that are in effect for the current operation and will allow you to view the contents of the scripts even if you don't have permission to modify them.

How are they created?

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.

Toggling

Even if a browser script is pushed out for a command, its output can be toggled on and off individually.

This section will quickly go from first connection to running a basic agent. This walkthrough assumes you have the apfell agent and the http c2 profile installed.

Operations

When you log in with the admin account, you'll automatically have your current operation set to the default operation. Your current operation is indicated in the top bar in big letters. When other operators sign in for the first time, they won't have an operation set to their current operation. You can always click on the operation name to get back to the operations management page (or click the hamburger icon on the left and select operations on the side).

Creating a Payload

You need a payload to use. Click the hazard icon at the top and then select "New Payload" on the top right of the new screen. You can also get here by selecting the hamburger icon on the top left and selecting "Create" -> "Create Payload".

You'll be prompted to select which operating system. This is used to filter down possible payloads to generate. Next select the payload type you're wanting to build and fill out any necessary build parameters for the agent. Select any commands you want stamped into the payload initially. This will show commands not yet selected on the left and commands already selected on the right. There are some that can be pre-selected for you based on the agent developer (some are built in and can't be removed, some suggested, etc). If you hover over any of the commands you can see descriptive information about them. You can potentially load commands in later, but for this walkthrough select all of them. Click Next.

For c2 profiles, toggle the HTTP profile. Change the Callback host parameter to be where you want the agent to connect to (if you're using redirectors, you specify that here), similarly specify the Callback port for where you want the agent to connect to.

Provide a name for the agent (a default one is auto populated) and provide a description that will auto populate the description field for any callbacks created based on this payload. Click Next.

Once you click submit, you'll get a series of popups in the top giving feedback about the creation process. The blue notification popups will go away after a few seconds, but the green success or red error messages must be manually dismissed. This provides information about your newly created agent.

Using the Payload

Click the hazard icon on the top again to go to the created payloads page.. This is where you'll be able to see all of the payloads created for the current operation. You can delete the payload, view the configuration, or download the payload. For this walkthrough, download the payload (green download icon).

Now move the payload over to your target system and execute it. The apfell.js payload can be run with osascript and the file name on macOS. Once you've done that, head to the Active Callbacks page from the top navigation bar via the phone icon.

Callback Interaction

This is where you'll be able to interact with any callback in the operation. Click the button for the row with your new agent to bring up information in the bottom pane where you can type out commands and issue them to the agent.

What is an operation?

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.

Where are operations?

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. Only a global Mythic admin can create new operations.

How do you use operations?

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.

Current Operations

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". This process will require you to log out and log back in for the effect to take place and the new data to be fetched.

This section will highlight a few of the pieces of Mythic that operators are most likely to use on a daily basis.

• - use JavaScript to transform your command output into tables, buttons, links, and more

• - the main operational page for interacting with callbacks, also allows you to see graph/tree views of your callbacks

• - view the uploads and downloads for the operation

• - search commands, command parameters, and command output across the operation

• - view/comment/edit/add credentials for your operation

• Expanded - this allows you to view callbacks as the full screen so that you have more operational screen space

• - all of the screencaptures throughout the operation can be viewed and downloaded here

• - 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

What are comments?

Comments are a single text description that can be added to any task 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.

Where are they?

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 "".

Searching Comments

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.

What is it?

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).

Where is it?

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).

How does it work?

1. 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.

2. Mythic opens port 3333 in a go routine.

3. An operator configures proxychains to point to the Mythic server on port 3333.

4. An operator runs a tool through proxychains (ex: proxychains curl https://www.google.com)

5. Proxychains connects to Mythic on port 3333 and starts the Socks protocol negotiations.

6. The tool sends data through proxychains, and Mythic stores it in memory. In this temporary data, Mythic assigns each connection its own ID number.

7. 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.

8. 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.

9. 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.

Where is it?

Credentials can be found from the search page on the top navigation bar or by clicking the key icon at the top.

How is it integrated?

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.

Integration into issuing commands

Command parameters can hook into this for auto populating by selecting which data they're interested in and then further manipulating it if they want.

Autopopulation

Tasks can register credentials with the server in their responses by following Credentials format.

What is it?

The file browser is a visual, file browser representation of the directory listings that agents perform. Not all agents support this feature however.

Where is it?

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.

How do you use it?

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 is_file_browse set to true. 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 is_upload field for the payload type associated with the identified Callback 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.

Actions

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.

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.

Where is it?

All uploads and downloads for an operation can be tracked via the clip icon or the search icon at the top.

How does it work?

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.

Additional Info

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.

What are tags?

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.

Why should I bother with this?

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.

Where are tags?

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.

Where can I see tags?

Tags are available throughout the various Mythic pages - anywhere you see the tag icon you can view/edit/add tags.

Where is it?

The main page to see and interactive with active callbacks can be found from the phone icon at the top of the screen.

Top table

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.

Bottom Area

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.

Auto Complete

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.

Tasking

Submitting a command goes through a few phases that are also color coded to help visually see the state of your task:

1. 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.

2. Submitted- The task has finished pre-processing and is ready for the agent to request it.

3. Processing - The agent has pulled down the task, but has not returned anything.

4. Processed - The agent has returned at least one response for the task, but hasn't explicitly marked the task as completed

5. Completed - The agent has reported the task done successfully

6. 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

Task filtering

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).

Where is it?

Screenshots for an entire operation can be accessed via the camera icon in the top bar or the search page.

How to use it?

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.

What is it?

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

Where is it?

The event feed is located at the alarm bell icon in the top right.

What does it do?

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:

Here we can see that the operator selects the different payload options they desire in the web user interface and clicks submit. That information goes to Mythic which looks up all the database objects corresponding to the user's selection. Mythic then registers a payload in a building state. Mythic sends all this information to the corresponding Payload Type container to build an agent to meet the desired specifications. The corresponding build command parses these parameters, stamps in any required user parameters (such as callback host, port, jitter, etc) and uses any user supplied build parameters (such as exe/dll/raw) to build the agent.

In the build process, there's a lot of room for customizing. Since it's all async through rabbitMQ, you are free to stamp code together, spin off subprocesses (like mono or go) to build your agent, or even make web requests to CI/CD pipelines to build the agent for you. Eventually, this process either returns an agent or some sort of error. That final result gets send back to Mythic via rabbitMQ which then updates the database and user interface to allow an operator to download their payload.

What are they?

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.

Where are they?

They're located in your settings page (click your name in the top right and click settings).

How are they used?

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>.

The following subpages have Mermaid sequence diagrams explaining how messages flow amongst the various microservices for Mythic when doing things like creating payloads, issuing tasks, and trasnferring files.

Here we can see an agent sends a message to Mythic. The C2 Profile container is simply a fancy redirector that know show to pull the message off the wire, it doesn't do anything else than that. From there, Mythic starts processing the message. It pulls out the UUID so it can determine which agent/callback we're talking about. This is where a decision point happens:

• If the Payload Type associated with the payload/callback for the UUID of the message has a translation container associated with it, then Mythic will send the message there. It's here that the rest of the message is converted from the agent's special sauce C2 format into the standard JSON that Mythic expects. Additionally, if the Payload Type handles encryption for itself, then this is where that happens.

• If there is not translation container associated with the payload/callback for the UUID in the message, then Mythic moves on to the next step and starts processing the message.

Mythic then processes the message according to the "action" listed.

Mythic then potentially goes back to the translation container to convert the response message back to the agent's custom C2 spec before finally returning everything back through the C2 Profile docker container.

What happens when you want to transfer a file from Mythic -> Agent? There's two different options: tracking a file via a UUID and pulling down chunks or just sending the file as part of your tasking.

This is an example of an operator uploading a file, it getting processed at the Payload Type's create_tasking function where it tracks and registers the file within Mythic. Now the tasking has a UUID for the file rather than the file contents itself. This allows Mythic and the Agent to uniquely reference a file. The agent gets tasking, sees the file id, and submits more requests to fetch the file. Upon finally getting the full file, it resolves the relative upload path into an absolute path and sends an update back to Mythic to let it know that the file the operator said to upload to ./test is actually at /abs/pah/to/test on the target host.

Conversely, you can opt to not track the file (or track the file within Mythic, but not send the UUID down to the agent). In this case, you can't easily reference the same instance of the file between the Agent and Mythic:

You're able to upload and transfer the file just fine, but when it comes to reporting back information on it, Mythic and the Agent can't agree on the same file, so it doesn't get updated. You might be thinking that this is silly, of course the two know what the file is, it was just uploaded. Consider the case of files being deleted or multiple instances of a file being uploaded.

When you're downloading a file from the Agent to Mythic (such as a file on disk, a screenshot, or some large piece of memory that you want to track as a file), you have to indicate in some way that this data is specific to a file and not destined to be part of the information displayed to the user. The way this works is pretty much the inverse of what happens for uploads. Specifically, an agent has a file it wants to transfer, so it tells Mythic "i have data, i'm gonna send it as X chunks of size Y, can you give me a UUID so we can track this". Mythic tracks the data and gives back a UUID. Now the agent sends each chunk individually and Mythic can track it. This allows a single task to be able to send back multiple files concurrently or sequentially and still track it all.

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.

Built-in Commands

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.

Clear

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.

help

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.

More information on P2P message communication can be found here.

1. P2P agents do their "C2 Comms" (which in this case is reaching out to agent1 over the decided TCP port) and start their Checkin/Encrypted Key Exchange/etc.

2. When Agent1 gets a connection from Agent2, there's a lot of unknowns. Agent2 could be a new payload that isn't registered as a callback in Mythic yet. It could be an already existing callback that you're re-linking to or linking to for the first time from this callback. Either way, Agent1 doesn't know anything about Agent2 other than it connected to the right port, so it generates a temporary UUID to refer to that connection and waits for a message from Agent 2 (the first message sent through should always be from Agent2->Agent1 with a checkin message). Agent1 sends this information out with its next message as a "Delegate" Message of the form:

{
    "action": "some action here",
    "delegates": [
        {
            "message": agentMessage,
            "uuid": UUID,
            "c2_profile": "ProfileName"
        }
    ]
}

This "delegates" key sits at the same level as the "action" key and can go with any message (upload, checkin, post_response, etc). The "message" field is the checkin message from Agent2, the "uuid" field is the tempUUID that agent1 generated, and the "c2_profile" is the name of the C2 profile that the two agents are using to connect.

3. When Mythic parses this delegate message, it can automatically assume that there's a connection between Agent1 and Agent2 because Agent1's message has a Deleggate from Agent 2.

4. When Mythic is done processing Agent2's checkin message, it takes that result and adds it as a "delegate" message back for Agent1's message.

5. When Agent1 gets its message back, it sees that there is a delegate message. That message is of the format:

{
    "action": "some action here",
    "delegates": [
        {
            "message": agentMessage,
            "uuid": "same UUID as the message agent -> mythic",
            "mythic_uuid": UUID that mythic uses
        }
    ]
}

6. You can see that the response format is a little different. We don't need to echo back the C2 Profile because the agent already knows that information. The "message" field is the Mythic response that goes back to Agent 2. The "uuid" field is the same tempUUID that the agent sent in the message to Mythic. The "mythic_uuid" field though is Mythic indicating back to Agent1 that it doesn't know what tempUUID is, but the agent that sent that message actually has this UUID. That allows the agent to update its records. The main reason this is important is in the case where the connection between Agent1 and Agent2 goes away. Agent1 has to have some way of indicating to Mythic that Agent2 is no longer talking to it. Mythic only knows Agent2 by its UUID, so if Agent1 tried to report that it could no longer talk to tempUUID, Mythic would have no idea who that is.

There's a lot of moving pieces within Mythic and its agents, so it's helpful to take a step back and see how messages are flowing between the different components.

Here we can see an operator issue tasking to the Mythic server. The Mythic server registers the task as "preprocessing" and informs the operator that it got the task. Mythic then sends the task off to the corresponding Payload Type container for processing. The container looks up the corresponding command python file, parses the arguments, validates the arguments, and passes the resulting parameters to the create_tasking function. This function can leverage a bunch of RPC functionality going back to Mythic to register files, send output, etc. When it's done, it sends the final parameters back to Mythic which updates the Task to either Submitted or Error. Now that the task is out of the preprocessing state, when an agent checks in, it can receive the task.

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:

What is it?

The database schema describes the current state of Mythic within the mythic_postgres Docker container. Mythic tracks everything in the Postgres database so that if an operator needs to close their browser or the server where Mythic runs reboots, nothing is lost. The benefit of having all data tracked within the database and simply streamed to the operator's interface means that all operators stay in sync about the state of the operation - each operator doesn't have to browse all of the file shares themselves to see what's going on and you don't have to grep through a plethora of log files to find that one task you ran that one time.

Where is it?

The database lives in the postgres-docker folder and is mapped into the mythic_postgres container as a volume. This means that if you need to move Mythic to a new server, simply stop mythic with ./mythic-cli stop, copy the Mythic folder to its new home, and start everything back up again with ./mythic-cli start.

On the first start of Mythic, the database schema is loaded from a schema file located in mythic-docker: .

How is it used?

Since the database schema is the source of truth for all of Mythic, mythic scripting, and all of the operator's interfaces, it needs to be easily accessible in a wide range of cases.

The mythic_server container connects directly to the mythic_postgres container to sync the containers and quickly react to agent messages. The mythic_graphql container (Hasura) also directly connects to the database and provides a GraphQL interface to the underlying data. This GraphQL interface is what both the React UI and mythic scripting use to provide a role-based access control (RBAC) layer on top of the database.

How do I use it?

How do you, as an operator or developer, find out more about the database schema? The easiest way is to click the hamburger icon in the top left of Mythic, select "Services", and then select the "GraphQL Console". This drops you into the Hasura Login screen; the password for Hasura can be found randomly generated in your Mythic/.env file.

From here, the API tab, shown below, provides an easy way to dynamically explore the various queries, subscriptions, and modifications you can make to the database right here or via scripting.

Since the Mythic Scripting simply uses this GraphQL interface as well, anything you put in that center body pane you can submit as a POST request to Mythic's grapqhl endpoint (shown above) to achieve the same result. The majority of the functions within Mythic Scripting are simply ease-of-use wrappers around these same queries.

If you want to have even more fun exploring how the GraphQL interface manipulates the database schema, you can check out the built-in Jupyter Notebook and test out your modifications there as well. As shown in the two screenshots below, you can create scripts to interact with the GraphQL endpoints to return only the data you want.

This scripting, combined with the Hasura GraphQL console allows operators to very easily get direct access and real-time updates to the database without having to know any specific SQL syntax or worry about accidentally making a schema change.

What is it?

Payload types are the different kinds of agents that can be created and used with Mythic.

Where are they located?

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

Where can I find more documentation about them?

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.

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.

You can then specify what type of parameter it is from the following:

• String

• CredentialJson

• Number

• Array

• Boolean

• Choose One

• Choose Many

• File

• PayloadList

• ConnectionInfo

• LinkInfo

If you select "PayloadList", the user is given a dropdown list of already created (but not deleted) payloads to choose from as a template. The associated tasking can then take this to fetch the payload contents, send down the payload's UUID, or use it to generate a new payload based on the one selected.

If you select "ConnectionInfo", the user is able to select and associate payloads/callbacks with hosts. This also allows the user to select the payload's p2p information for linking agents. The main example here is if you've generated a payload as part of lateral movement, priv esc, or persistence tasking and now want to connect to the payload via p2p (or if you lost connection and are reconnecting to the callback).

If you select "LinkInfo", the user gets a list of already established p2p "links" and allows you to select ones to re-establish or to remove.

Lastly, if you choose File, then the user will be allowed to upload a file via the GUI when you type out the command. By default, the file UUID is sent as the parameter so that you're ready to do file transfers via chunking.

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.

View Configuration

All of a payload type's parameters are configurable from within the Payload Type's docker container. Edit the corresponding information in the class that extends the PayloadType class.

class Apfell(PayloadType):

    name = "apfell"
    file_extension = "js"
    author = "@its_a_feature_"
    supported_os = [
        SupportedOS.MacOS
    ]
    wrapper = False
    wrapped_payloads = []
    note = """This payload uses JavaScript for Automation (JXA) for execution on macOS boxes. 
There have been issues with macOS < 10.13 and encryption, so be sure to blank out the AESPSK and set key exchange to "F" when creating those payloads.
    """
    supports_dynamic_loading = True
    build_parameters = {
    }
    c2_profiles = ["http", "dynamichttp"]

There are a few interesting pieces to call out here:

• "Is this payload a wrapper for another payload"

  • A "Payload Wrapper" is a special form of payload type that simply acts a a wrapper for another payload type. An easy example of this is msbuild or macros from the Windows environment. These are payloads you might drop onto a system, but they aren't the real payload you're trying to execute. They're just wrappers for the actual end payload. That's the same goal here.

• Does this payload support dynamic loading - This is where you can specify if your payload allows you to load new modules in it or not. If this is false, then when creating a payload, you will not be able to choose which commands you want stamped into it - they'll ALL always be stamped in. If this is set to true, it does allow dynamic loading, then you can freely choose which commands you want stamped in at creation time and load in new commands later.

What is it?

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:

1. 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

2. Agent code - the code that runs in a callback to implement the C2 profile on the target machine.

Where is it?

C2 profiles can be found by going to Payload Types and C2 Profiles (headphone icon) from the top navigational bar.

How do they work?

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.

Where can I find more documentation about them?

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.

Where are they?

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.

Why use containers?

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.

When do containers come into play?

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.

C2 OPSEC Checks

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.

Where is it?

These checks all happen within a single function per C2 profile with a function called opsec:

# The opsec function is called when a payload is created as a check to see if the parameters supplied are good
# The input for "request" is a dictionary of:
# {
#   "action": "opsec",
#   "parameters": {
#       "param_name": "param_value",
#       "param_name2: "param_value2",
#   }
# }
# This function should return one of two things:
#   For success: {"status": "success", "message": "your success message here" }
#   For error: {"status": "error", "error": "your error message here" }
async def opsec(self, inputMsg: C2OPSECMessage) -> C2OPSECMessageResponse:
        response = C2OPSECMessageResponse(Success=True)
        response.Message = "Not Implemented, passing by default"
        response.Message += f"\nInput: {json.dumps(inputMsg.to_json(), indent=4)}"
        return response

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 Server Configuration Checks

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.

async def config_check(self, inputMsg: C2ConfigCheckMessage) -> C2ConfigCheckMessageResponse:
        response = C2ConfigCheckMessageResponse(Success=True)
        response.Message = "Not Implemented"
        response.Message += f"\nInput: {json.dumps(inputMsg.to_json(), indent=4)}"
        return response

C2 Server Redirect Rules

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.

async def redirect_rules(self, inputMsg: C2GetRedirectorRulesMessage) -> C2GetRedirectorRulesMessageResponse:
        response = C2GetRedirectorRulesMessageResponse(Success=True)
        response.Message = "Not Implemented"
        response.Message += f"\nInput: {json.dumps(inputMsg.to_json(), indent=4)}"
        return response

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.

Egress Profiles

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.

P2P Profiles

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 Visualizations

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 D3 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.

What is it?

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.

How does it work?

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.

Using SSL

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.

Supported Payloads and Info

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.

Profile Parameters

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.

What is it?

An operator can provide non-default, but specific values for all of fields of a C2 profile and save it off as an instance. These instances can then be used to auto-populate all of the C2 profile's values when creating a payload so that you don't have to manually type them each time.

Why have it?

This is a nice time saver when creating multiple payloads throughout an operation. It's likely that in an operation you will have multiple different domains, domain fronts, and other external infrastructure. It's more convenient and less error prone to provide the specifics for that information once and save it off than requiring operators to type in that information each time when creating payloads.

Where is it?

The Save Parameters button is located next to each C2 profile by clicking the "headphones" icon at the top of the screen.

How to create an instance

To create a new named instance, select the Save Instance button to the right of a c2 profile and fill out any parameters you want to change. The name must be unique at the top though.

Overview

This profile uses HTTP Get and Post messages to communicate with the main Mythic server. Unlike the default HTTP though, this profile allows a lot of customization from both the client and server. There are two pieces to this as with most C2 profiles - Server side code and Agent side code. In general, the flow looks like:

Agent Configuration

From the UI perspective, there are only two parameters - a JSON configuration and the auto-populated operation specific AES key. For the JSON configuration, there is a generic structure:

{
  "GET": {
    "ServerBody": [
    ],
    "ServerHeaders": {
      "Server": "NetDNA-cache/2.2",
    },
    "ServerCookies": {},
    "AgentMessage": []
  },
  "POST": {
    "ServerBody": [],
    "ServerCookies": {},
    "ServerHeaders": {
      "Server": "NetDNA-cache/2.2",
    },
    "AgentMessage": []
  },
  "jitter": 50,
  "interval": 10,
  "chunk_size": 5120000,
  "key_exchange": true,
  "kill_date": "2019-12-31"
}

There are some important pieces to notice here:

• GET - this block defines what "GET" messages look like. This section is used for requesting tasking.

  • ServerBody - this block defines what the body of the server's response will look like

  • ServerHeaders - this block defines what the server's headers will look like

  • ServerCookies - this block defines what the server's cookies will look like

  • AgentMessage - This block defines the different forms of agent messages for doing GET requests. This defines what query parameters are used, what cookies, headers, URLs, etc.The format here is generally the same as the "POST" messages and will be described in the next section.

• POST - this block defines what "POST" messages look like

  • ServerBody - this block defines what the body of the server's response will look like

  • ServerHeaders - this block defines what the server's headers will look like

  • ServerCookies - this block defines what the server's cookies will look like

  • AgentMessage - This block defines the different forms of agent messages for doing POST requests. This defines what query parameters are used, what cookies, headers, URLs, etc.

• jitter - this is the jitter percentage for callbacks

• interval - this is the interval in seconds between callbacks

• chunk_size - this is the chunk size used for uploading/downloading files

• key_exchange - this specifies if Apfell does an encrypted key exchange or just uses a static encryption key

• kill_date - this defines the date agents should stop checking in. This date is checked when the agent first starts and before each tasking request, if it is the specified date or later, the agent will automatically exit. This is in the YYYY-MM-DD format.

Now let's talk about the AgentMessage parameter. This is where you define all of the key components about how your GET and POST messages from agent to Mythic look, as well as indicating where in those requests you want to put the actual message the agent is trying to send. The format in general looks like this:

{
  "urls": ["http://192.168.0.11:9001"],
  "uri": "/<test:string>",
  "urlFunctions": [
    {
      "name": "<test:string>",
      "value": "",
      "transforms": [
        {
          "function": "choose_random",
          "parameters": ["jquery-3.3.1.min.js","jquery-3.3.1.map"]
        }
      ]
    }
  ],
  "AgentHeaders": {
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Host": "code.jquery.com",
    "Referer": "http://code.jquery.com/",
    "Accept-Encoding": "gzip, deflate",
    "User-Agent": "Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko"
  },
  "QueryParameters": [
      {
        "name": "q",
        "value": "message",
        "transforms": [
        ]
      }
  ],
  "Cookies": [
     {
      "name": "__cfduid",
      "value": "",
      "transforms": [
        {
          "function": "random_alpha",
          "parameters": [30]
        },
        {
          "function": "base64",
          "parameters": []
        }
      ]
    }
  ],
  "Body": []
}

In the AgentMessage section for the "GET"s and "POST"s, you can have 1 or more instances of the above AgentMessage format (the above is an example of one instance). When the agent goes to make a GET or POST request, it randomly picks one of the formats listed and uses it. Let's look into what's actually being described in this AgentMessage:

• urls - this is a list of URLs. One of these is randomly selected each time this overall AgentMessage is selected. This allows you to supply fallback mechanisms in case one IP or domain gets blocked.

• uri - This is the URI to be used at the end of each of the URLs specified. This can be a static value, like /downloads.php, or can be one that's changed for each request. For example, in the above scenario we supply /<test:string>. The meaning behind that format is explained in the HTTP for the server side configuration, but the point here to look at is the next piece - urlFunctions

• urlFunctions - This describes transforms for modifying the URI of the request. In the above example, we replace the <test:string> with a random selection from ["jquery-3.3.1.min.js", "jquery-3.3.1.map"].

• AgentHeaders - This defines the different headers that the agent will set when making requests

  • Note: if you're doing domain fronting, this is where you'd set that value

• QueryParameters - This defines the query parameters (if any) that will be sent with the request. When doing transforms and dynamic modifications, there is a standard format that's described in the next section.

• Cookies - This defines any cookies that are sent with the agent messages

• Body - This defines any modifications to the body of the request that should be made

Transforms

The defining feature of the HTTP profile is being able to do transforms on the various elements of HTTP requests. What does this look like though?

"Cookies": [
     {
      "name": "__cfduid",
      "value": "",
      "transforms": [
        {
          "function": "random_alpha",
          "parameters": [30]
        },
        {
          "function": "base64",
          "parameters": []
        }
      ]
    }
  ]

These transforms have a few specific parts:

• name - this is the parameter name supplied in the request. For query parameters, this is the name in front of the = sign (ex:/test.php?q=abc123). For cookie parameters, this is the name of the cookie (ex: q=abc123;id=abc1).

• value - this is the starting value before the transforms take place. You can set this to whatever you want, but if you set it to message, then the starting value for the transforms will be the message that the agent is trying to send to Apfell.

• transforms - this is a list of transforms that are executed. The value starts off as indicated in the value field, then each resulting value is passed on to the next parameter. In this case, the value starts as "", then gets 30 random alphabet letters, then those letters are base64 encoded.

  • Transforms have 2 parameters: the name of the function to execute and an array of parameters to pass in to it.

  • The initial set of supported functions are:

    • base64

      • takes no parameters

    • prepend

      • takes a single parameter of the thing to prepend to the input value

    • append

      • takes a single parameter of the thing to append to the input value

    • random_mixed

      • takes a single parameter of the number of elements to append to the input value. The elements are chosen from upper case, lower case, and numbers.

    • random_number

      • takes a single parameter of the number of elements to append to the input value. The elements are chosen from numbers 0-9.

    • random_alpha

      • takes a single parameter of the number of elements to append to the input value. The elements are chosen from upper case and lower case letters.

    • choose_random

      • takes an array of elements to choose from

  • To add new transforms, a few things need to happen:

    • In the HTTP profile's server code, the function and a reverse of the function need to be added. The options need to be added to the create_value and get_value functions.

      • This allows the server to understand the new transforms

      • If you look in the server code, you'll see functions like prepend (which prepends the value) and r_prepend which does the reverse.

    • In the agent's HTTP profile code, the options for the functions need to also be added so that the agent understands the functions. Ideally, when you do this you add the new functions to all agents, otherwise you start to lose parity.

A final example of an agent configuration can be seen below:

{
  "GET": {
    "ServerBody": [
      {
        "function": "base64",
        "parameters": []
      },
      {
        "function": "prepend",
        "parameters": ["!function(e,t){\"use strict\";\"object\"==typeof module&&\"object\"==typeof module.exports?module.exports=e.document?t(e,!0):function(e){if(!e.document)throw new Error(\"jQuery requires a window with a document\");return t(e)}:t(e)}(\"undefined\"!=typeof window?window:this,function(e,t){\"use strict\";var n=[],r=e.document,i=Object.getPrototypeOf,o=n.slice,a=n.concat,s=n.push,u=n.indexOf,l={},c=l.toString,f=l.hasOwnProperty,p=f.toString,d=p.call(Object),h={},g=function e(t){return\"function\"==typeof t&&\"number\"!=typeof t.nodeType},y=function e(t){return null!=t&&t===t.window},v={type:!0,src:!0,noModule:!0};function m(e,t,n){var i,o=(t=t||r).createElement(\"script\");if(o.text=e,n)for(i in v)n[i]&&(o[i]=n[i]);t.head.appendChild(o).parentNode.removeChild(o)}function x(e){return null==e?e+\"\":\"object\"==typeof e||\"function\"==typeof e?l[c.call(e)]||\"object\":typeof e}var b=\"3.3.1\",w=function(e,t){return new w.fn.init(e,t)},T=/^[\\s\\uFEFF\\xA0]+|[\\s\\uFEFF\\xA0]+$/g;w.fn=w.prototype={jquery:\"3.3.1\",constructor:w,length:0,toArray:function(){return o.call(this)},get:function(e){return null==e?o.call(this):e<0?this[e+this.length]:this[e]},pushStack:function(e){var t=w.merge(this.constructor(),e);return t.prevObject=this,t},each:function(e){return w.each(this,e)},map:function(e){return this.pushStack(w.map(this,function(t,n){return e.call(t,n,t)}))},slice:function(){return this.pushStack(o.apply(this,arguments))},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},eq:function(e){var t=this.length,n=+e+(e<0?t:0);return this.pushStack(n>=0&&n<t?[this[n]]:[])},end:function(){return this.prevObject||this.constructor()},push:s,sort:n.sort,splice:n.splice},w.extend=w.fn.extend=function(){var e,t,n,r,i,o,a=arguments[0]||{},s=1,u=arguments.length,l=!1;for(\"boolean\"==typeof a&&(l=a,a=arguments[s]||{},s++),\"object\"==typeof a||g(a)||(a={}),s===u&&(a=this,s--);s<u;s++)if(null!=(e=arguments[s]))for(t in e)n=a[t],a!==(r=e[t])&&(l&&r&&(w.isPlainObject(r)||(i=Array.isArray(r)))?(i?(i=!1,o=n&&Array.isArray(n)?n:[]):o=n&&w.isPlainObject(n)?n:{},a[t]=w.extend(l,o,r)):void 0!==r&&(a[t]=r));return a},w.extend({expando:\"jQuery\"+(\"3.3.1\"+Math.random()).replace(/\\D/g,\"\"),isReady:!0,error:function(e){throw new Error(e)},noop:function(){},isPlainObject:function(e){var t,n;return!(!e||\"[object Object]\"!==c.call(e))&&(!(t=i(e))||\"function\"==typeof(n=f.call(t,\"constructor\")&&t.constructor)&&p.call(n)===d)},isEmptyObject:function(e){var t;for(t in e)return!1;return!0},globalEval:function(e){m(e)},each:function(e,t){var n,r=0;if(C(e)){for(n=e.length;r<n;r++)if(!1===t.call(e[r],r,e[r]))break}else for(r in e)if(!1===t.call(e[r],r,e[r]))break;return e},trim:function(e){return null==e?\"\":(e+\"\").replace(T,\"\")},makeArray:function(e,t){var n=t||[];return null!=e&&(C(Object(e))?w.merge(n,\"string\"==typeof e?[e]:e):s.call(n,e)),n},inArray:function(e,t,n){return null==t?-1:u.call(t,e,n)},merge:function(e,t){for(var n=+t.length,r=0,i=e.length;r<n;r++)e[i++]=t[r];return e.length=i,e},grep:function(e,t,n){for(var r,i=[],o=0,a=e.length,s=!n;o<a;o++)(r=!t(e[o],o))!==s&&i.push(e[o]);return i},map:function(e,t,n){var r,i,o=0,s=[];if(C(e))for(r=e.length;o<r;o++)null!=(i=t(e[o],o,n))&&s.push(i);else for(o in e)null!=(i=t(e[o],o,n))&&s.push(i);return a.apply([],s)},guid:1,support:h}),\"function\"==typeof Symbol&&(w.fn[Symbol.iterator]=n[Symbol.iterator]),w.each(\"Boolean Number String Function Array Date RegExp Object Error Symbol\".split(\" \"),function(e,t){l[\"[object \"+t+\"]\"]=t.toLowerCase()});function C(e){var t=!!e&&\"length\"in e&&e.length,n=x(e);return!g(e)&&!y(e)&&(\"array\"===n||0===t||\"number\"==typeof t&&t>0&&t-1 in e)}var E=function(e){var t,n,r,i,o,a,s,u,l,c,f,p,d,h,g,y,v,m,x,b=\"sizzle\"+1*new Date,w=e.document,T=0,C=0,E=ae(),k=ae(),S=ae(),D=function(e,t){return e===t&&(f=!0),0},N={}.hasOwnProperty,A=[],j=A.pop,q=A.push,L=A.push,H=A.slice,O=function(e,t){for(var n=0,r=e.length;n<r;n++)if(e[n]===t)return n;return-1},P=\"\r"]
      },
      {
        "function": "prepend",
        "parameters": ["/*! jQuery v3.3.1 | (c) JS Foundation and other contributors | jquery.org/license */"]
      },
      {
        "function": "append",
        "parameters": ["\".(o=t.documentElement,Math.max(t.body[\"scroll\"+e],o[\"scroll\"+e],t.body[\"offset\"+e],o[\"offset\"+e],o[\"client\"+e])):void 0===i?w.css(t,n,s):w.style(t,n,i,s)},t,a?i:void 0,a)}})}),w.each(\"blur focus focusin focusout resize scroll click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup contextmenu\".split(\" \"),function(e,t){w.fn[t]=function(e,n){return arguments.length>0?this.on(t,null,e,n):this.trigger(t)}}),w.fn.extend({hover:function(e,t){return this.mouseenter(e).mouseleave(t||e)}}),w.fn.extend({bind:function(e,t,n){return this.on(e,null,t,n)},unbind:function(e,t){return this.off(e,null,t)},delegate:function(e,t,n,r){return this.on(t,e,n,r)},undelegate:function(e,t,n){return 1===arguments.length?this.off(e,\"**\"):this.off(t,e||\"**\",n)}}),w.proxy=function(e,t){var n,r,i;if(\"string\"==typeof t&&(n=e[t],t=e,e=n),g(e))return r=o.call(arguments,2),i=function(){return e.apply(t||this,r.concat(o.call(arguments)))},i.guid=e.guid=e.guid||w.guid++,i},w.holdReady=function(e){e?w.readyWait++:w.ready(!0)},w.isArray=Array.isArray,w.parseJSON=JSON.parse,w.nodeName=N,w.isFunction=g,w.isWindow=y,w.camelCase=G,w.type=x,w.now=Date.now,w.isNumeric=function(e){var t=w.type(e);return(\"number\"===t||\"string\"===t)&&!isNaN(e-parseFloat(e))},\"function\"==typeof define&&define.amd&&define(\"jquery\",[],function(){return w});var Jt=e.jQuery,Kt=e.$;return w.noConflict=function(t){return e.$===w&&(e.$=Kt),t&&e.jQuery===w&&(e.jQuery=Jt),w},t||(e.jQuery=e.$=w),w});"]
      }
    ],
    "ServerHeaders": {
        "Server": "NetDNA-cache/2.2",
        "Cache-Control": "max-age=0, no-cache",
        "Pragma": "no-cache",
        "Connection": "keep-alive",
        "Content-Type": "application/javascript; charset=utf-8"
      },
    "ServerCookies": {},
    "AgentMessage": [{
      "urls": ["http://192.168.0.11:9001"],
      "uri": "/<test:string>",
      "urlFunctions": [
        {
          "name": "<test:string>",
          "value": "",
          "transforms": [
            {
              "function": "choose_random",
              "parameters": ["jquery-3.3.1.min.js","jquery-3.3.1.map"]
            }
          ]
        }
      ],
      "AgentHeaders": {
        "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
        "Host": "code.jquery.com",
        "Referer": "http://code.jquery.com/",
        "Accept-Encoding": "gzip, deflate",
        "User-Agent": "Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko"
      },
      "QueryParameters": [
          {
            "name": "q",
            "value": "message",
            "transforms": [
            ]
          }
      ],
      "Cookies": [
         {
          "name": "__cfduid",
          "value": "",
          "transforms": [
            {
              "function": "random_alpha",
              "parameters": [30]
            },
            {
              "function": "base64",
              "parameters": []
            }
          ]
        }
      ],
      "Body": []
    }]
  },
  "POST": {
    "ServerBody": [],
    "ServerCookies": {},
    "ServerHeaders": {
          "Server": "NetDNA-cache/2.2",
          "Cache-Control": "max-age=0, no-cache",
          "Pragma": "no-cache",
          "Connection": "keep-alive",
          "Content-Type": "application/javascript; charset=utf-8"
        },
    "AgentMessage": [{
      "urls": ["http://192.168.0.11:9001"],
      "uri": "/download.php",
      "urlFunctions": [],
      "QueryParameters": [
        {
          "name": "bob2",
          "value": "justforvalidation",
          "transforms": []
        }
      ],
      "AgentHeaders": {
        "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
        "Host": "code.jquery.com",
        "Referer": "http://code.jquery.com/",
        "Accept-Encoding": "gzip, deflate",
        "User-Agent": "Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko"
      },
      "Cookies": [
        {
          "name": "BobCookie",
          "value": "splat",
          "transforms": [
            {
              "function": "prepend",
              "parameters": [
                "splatity_"
              ]
            }
          ]
        }
      ],
      "Body": [
        {
          "function": "base64",
          "parameters": []
        },
        {
          "function": "prepend",
          "parameters": ["<html>"]
        },
          {
          "function": "append",
          "parameters": ["</html>"]
        }
      ]
    }]
  },
  "jitter": 50,
  "interval": 10,
  "chunk_size": 5120000,
  "key_exchange": true,
  "kill_date": "2020-01-20"
}

Server Configuration

Like with all C2 profiles, the HTTP profile has its own docker container that handles connections. The purpose of this container is to accept connections from HTTP agents, undo all of the special configurations you specified for your agent to get the real message back out, then forward that message to the actual Mythic server. Upon getting a response from Mythic, the container performs more transforms on the message and sends it back to the Agent.

The docker container just abstracts all of the C2 features out from the actual Mythic server so that you're free to customize and configure the C2 as much as you want without having to actually adjust anything in the main server.

There is only ONE HTTP docker container per Mythic instance though, not one per operation. Because of this, the HTTP profile's server-side configuration will have to do that multiplexing for you. Below is an example of the setup:

Let's look into what this sort of configuration entails. We already discussed the agent side configuration above, so now let's look into what's going on in the HTTP C2 Docker container. The Server configuration has the following general format:

{
  "instances": [
    {
      "GET": {
    },
      "POST": {
    },
    "no_match": {
      "action": "return_file",
      "redirect": "http://example.com",
      "proxy_get": {
        "url": "https://www.google.com",
        "status": 200
      },
      "proxy_post": {
        "url": "https://www.example.com",
        "status": 200
      },
      "return_file": {
        "name": "fake.html",
        "status": 404
      }
    },
    "port": 9001,
    "key_path": "",
    "cert_path": "",
    "debug": true
    }
  ],
}

There are a couple key things to notice here:

• instances - You generally have one instance per operation, but there's no strict limit there. This is an array of configurations, so when the Docker server starts up, it loops through these instances and starts each one

• no_match - this allows you to specify what happens if there's an issue reaching the main apfell server or if you get a request to the docker container that doesn't match one of your specified endpoints. This is also what happens if you get a message to the right endpoint, but it's not properly encoded with the proper agent message (ex: fails to decrypt the agent message or fails to get the agent message from the url)

  • action - this allows you to specify which of the options you want to leverage

  • redirect - this simply returns a 302 redirect to the specified url

  • proxy_get - this proxies the request to the following url and returns that url's contents with the status code specified

  • proxy_post - this proxies the request to the following url and returns that url's contents with the specified status code

  • return_file - this allows you to return the contents of a specified file. This is useful to have a generic 404 page or saved static page for a sight you might be faking.

• port - which port this instance should listen on

• key_path - the path locally to where the key file is located for an SSL connection. If you upload the file through the web UI then the path here should simply be the name of the file.

• cert_path - the path locally to where the cert file is located for an SSL connection.If you upload the file through the web UI, then the path here should simply be the name of the file. Both this and the key_path must be specified and have valid files for the connection to the container to be SSL.

• debug - set this to true to allow debug messages to be printed. There can be a lot though, so once you have everything working, be sure to set this to false to speed things up a bit.

• GET and POST - simply take the GET and POST sections from your agent configuration mentioned above and paste those here. No changes necessary.

URI formatting

When it comes to the URIs you choose to use for this, there's an additional feature you can leverage. You can choose to keep them static (like /download.php) and specify/configure the query parameters/cookies/body, but you can also choose to register more dynamic URIs. There's an example of this above:

"uri": "/<test:string>"

What this does for the server side is register a pattern via Sanic's Request Parameters. This allows you to register URIs that can change every time, but still be valid. For example:

"uri": "/downloads/category/<c:string>/page/<i:int>"

this would require you to have the URI of something like /downloads/category/abcdefh/page/5 or the docker container will hit a not_found case and follow that action path. Combine this with the urlFunctions and you can have something to always generate unique URIs as follows:

"uri": "/downloads/category/<c:string>/page/<i:int>",
"urlFunctions": [
  {
    "name": "<c:string>",
    "value": "",
    "transforms": [
      {
        "function": "random_alpha",
        "parameters": [15]
      }
    ]
  },
  {
    "name": "<i:int>",
    "value": "",
    "transforms": [
    {
      "function": "random_number",
      "parameters": [3]
    }
    ]
  }
]

Special kinds of configuration

What if you want all of your messages to be "POST" requests or "GET" requests? Well, Apfell by default tries to do GET requests when getting tasking and POST requests for everything else; however, if there are no GET agent_message instances in that array (i.e. {"GET":{"AgentMessage":[]}}) then the agent should use POST messages instead and vise versa. This allows you to have yet another layer of customization in your profiles.

Linting

Because this is a profile that offers a LARGE amount of flexibility, it can get quite confusing. So, included with the dynamicHTTP is a linter (a program to check your configurations for errors). In C2_Profiles/dynamicHTTP/c2_code/ is a config_linter.py file. Run this program with ./config_linter.py [path_to_agent_config.json] where [path_to_agent_config.json] is a saved version of the configuration you'd supply your agent. The program will then check that file for errors, will check your server's config.json for errors, and then verify that there's a match between the agent config and server config (if there was no match, then your server wouldn't be able to understand your agent's messages). Here's an example:

its-a-feature@ubuntu:~/Desktop/Mythic/C2_Profiles/dynamicHTTP/c2_code$ ./config_linter.py agent_config.json 
[*] Checking server config for layout structure
[+] Server config layout structure is good
[*] Checking agent config for layout structure
[+] Agent config layout structure is good
[*] Looking into GET AgentMessages
[*] Current URLs: ['http://192.168.205.151:9000']
	Current URI: /<test:string>
[*] Found 'message' keyword in QueryParameter q
[*] Now checking server config for matching section
[*] Found matching URLs and URI, checking rest of AgentMessage
[+] FOUND MATCH
[*] Looking into POST AgentMessages
[*] Current URLs: ['http://192.168.205.151:9000']
	Current URI: /download.php
[*] Didn't find message keyword anywhere, assuming it to be the Body of the message
[*] Now checking server config for matching section
[*] Found matching URLs and URI, checking rest of AgentMessage
[*] Checking for matching Body messages
[+] FOUND MATCH

What is it?

Mythic can generate JSON or XML style reports. If you need a PDF version, simply generate the XML, open it up locally, and then in your browser save it off to PDF.

Where is it?

Report generation is located from the checker flag icon from the top navigation bar.

How to use it?

You can select your output format, if you want to include MITRE ATT&CK mappings inline with each tasking and if you want a MITRE ATT&CK Summary at the end. You can also optionally exclude certain callbacks, usernames, and hostnames from being included in the generated report.

The final generated report can be downloaded from this screen when it's ready via a toast notification. If you navigate away before it's done though, the report is also always available from the "files" section of the search page (click the paper clip icon at the top and select "Uploads" instead of "Downloads").

What is it?

Artifacts track potential indicators of compromise and other notable events occurring throughout an operation.

Where is it?

A list of all current artifacts can be found by clicking the fingerprint icon at the top of Mythic.

How to use it?

This page tracks all of the artifacts automatically created by executing tasks. This should provide a good idea for both defenders and red teamers about the artifacts left behind during an operation and should help with deconfliction requests.

When is it updated?

Artifacts are created in a few different ways:

1. A command's tasking automatically creates an artifact.

2. An agent reports back a new artifact in an ad-hoc fashion

What is Mythic scripting?

Mythic utilizes a combination of a GoLang Gin webserver and a Hasura GraphQL interface. Most actions that happen with Mythic go through the GraphQL interface (except for file transfers). We can hit the same GraphQL endpoints and listen to the same WebSocket endpoints that the main user interface uses as part of scripting, which means scripting can technically be done in any language.

Where is it?

Install the PyPi package via pip pip3 install mythic . The current mythic package is version 0.1.0rc2. The code for it is public -

How do I know what I can do?

The easiest way to play around with the scripting is to do it graphically - select the hamburger icon (three horizontal lines) in the top left of Mythic, select "Services", then "GraphQL Console". This will open up /console in a new tab.

From here, you need to authenticate to Hasura - run sudo ./mythic-cli config get hasura_secret on the Mythic server and you'll get the randomized Hasura secret to log in. At this point you can browser around the scripting capabilities (API at the top) and even look at all the raw Database data via the "Data" tab.

Examples

The Jupyter container has a lot of examples of using the Mythic Scripting to do a variety of things. You can access the Jupyter container by clicking on the hamurber icon (three horizontal lines) in the top left of Mythic, select "Services", then "Jupyter Notebooks". This will open up a /jupyter in a new tab.

From here, you need to authenticate to Jupyter - run sudo ./mythic-cli config get jupyter_token on the Mythic server to get the authentication token. By default, this is mythic, but can be changed at any time.

All information is tracked in the MythicMeta organization on GitHub available here:

Webinars

• Feb 23, 2022 -

  • Recording:

  • Slides:

All of the following features describe information that can be included in responses. These sections describe some additional JSON formats and data that can be used to have your responses be tracked within Mythic or cause the creation of additional elements within Mythic (such as files, credentials, artifacts, etc).

You can hook multiple features in a single response because they're all unique. For example, to display something to the user, it should be in the user_outputfield, such as:

Reserved Keywords

When we talk about Hooking Features in the message of an agent, we're really talking about a specific set of Dictionary key value pairs that have special meaning. All responses from the agent to the Mythic server already have to be in a structured format. Each of the following sections goes into what their reserved keywords mean, but some simpler ones are:

• task_id - string - UUID associated with tasks

• user_output - string - used with any command to display information back to the user

• completed - boolean - used with any command to indicate that the task is done (switches to the green completed icon)

• status - string - used to indicate that a command is not only done, but has encountered an error or some other status to return to the user

• process_response - this is passed to your command's python file for processing in the process_response function.

PayloadType Development Reference

What are actions?

Actions are special messages that don't adhere to the normal message types that you see for the rest of the features in this section. There are only a handful of these messages:

• - Initial checkin messages and key exchanges

• - Getting tasking

• - Sending tasking responses

  • Inside of this is where the features listed throughout this section appear

What is it?

MITRE ATT&CK is a knowledge base of adversary tactics and techniques mapped out to various threat groups. It provides a common language between red teams and blue teams when discussing operations, TTPs, and threat hunting. For Mythic, this provides a great way to track all of the capabilities the agents provide and to track all of the capabilities so far exercised in an operation.

For more information on MITRE ATT&CK, check out the following:

• https://attack.mitre.org

• https://twitter.com/mitreattack

• https://attackevals.mitre.org/

Where is it?

MITRE ATT&CK integrations can be found by clicking the chart icon from the top navigation bar.

How to use it?

There are a few different ways to leverage this information.

Commands by ATT&CK

Clicking the "Fetch All Commands Mapped to MITRE" action will highlight all of the matrix cells that have a command registered to that ATT&CK technique. Clicking on a specific cell will bring up more specific information on which payload type and which command is mapped to that technique. All of this information comes from the MITRE ATT&CK portion of commands.

Tasks by ATT&CK

This is a slightly different view. This button will highlight and show the cells that have been exercised in the current operation. A cell will only be highlighted if a command was executed in the current operation with that ATT&CK technique mapped to it.

The cell view will show the exact command that caused the cell to be highlighted with a link (via task number) back to the full display of the task:

If there is an issue with the mapping, clicking the red X button will remove the mapping.

Example (user tasking):

Any command is able to reply with its own artifacts that are created along the way. The following response can be returned as a separate C2 message or as part of the command's normal output.

Example (agent response):

Walkthrough:

Agents can report back their own artifacts they create at any time. They just include an artifacts keyword with an array of the artifacts. There are two components to this:

1. base_artifact is the type of base artifact being reported. If this base_artifact type isn't already captured in the "Global Configurations" -> "Artifact Types" page, then this base_artifact value will be created.

2. artifact is the actual artifact being created. This is a free-form field.

Artifacts created this way will be tracked in Artifacts page (click the fingerprint icon at the top)

What does it mean to link agents

This refers to the act of connecting two agents together with a peer-to-peer protocol. The details here are agnostic of the actual implementation of the protocol (could be SSH, TCP, Named Pipes, etc), but the goal is to provide a way to give one agent the context it needs to link or establish some peer-to-peer connectivity to a running agent.

Getting the Linking information

When creating a command, give a parameter of type ParameterType.ConnectionInfo. Now, when you type your command without parameters, you'll get a popup like normal. However, for this type, there will be three dropdown menus for you to fill out:

Host:

This field is auto populated based on two properties:

• The list of all hosts where you have registered callbacks

• The list of all hosts where Mythic is aware you've moved moved a payload to

Payload:

Once you've selected a host, the Payload dropdown will populate with the associated payloads that Mythic knows are on that host. These payloads are in two main groups:

• The payloads that spawned the current callbacks on that host

• The payloads that were moved over via a command that created a new payload and registered it to the new host

This payload simply acts as a template of information so that you can select the final piece.

What if your host/payload isn't listed?

Select the green + next to host, manually specify which host your payload lives on, then select from the dropdown the associated payload that was used. Then click add. Now Mythic is also tracking that the selected payload lives on the indicated host. You can continue with the host/payload/c2_profile dropdowns like normal.

C2 Profile:

When trying to connect to a new agent, you have to specify which specific profile you're wanting to connect to. This is because on any given host and for any given payload, there might be multiple c2 profiles within it (think HTTP, SMB, TCP, etc). This field will auto populate based on the C2 profiles that are in the payload selected in the drop down above it.

Submitting the task:

Once you've selected all of the above pieces, the task will insert all of that selected profile's specific instantiations as part of the task for the agent to use when connecting. This can include things like specific ports to connect to, specific pipe names to use, or any other information that might be needed to make the connection.

Shorthand:

All of the above is to help an operator identify exactly which payload/callback they're trying to connect to and via which p2p protocol. As a developer, you have the freedom to instead allow operators to specify more generic information via the command-line such as: link-command-name hostname or link-command-name hostname other-identifier. The caveat is this now requires the operator to know more detailed information about the connection ahead of time.

Leveraging Current/Old Links

The ParameterType.ConnectionInfo parameter type is useful when you want to make a new connection between a callback to a payload you just executed or to another callback that your current callback hasn't connected to before. A common command that leverages this parameter type would be link. However, this isn't too helpful if you want to remove a certain connection or if you just want to re-establish a connection that died. To help with this, there's the ParameterType.LinkInfo which, as the name implies, gives information about the links associated with your callback.

When you use a parameter type of ParameterType.LinkInfo, you'll get a dropdown menu where the user can select from live or dead links to leverage. When you select a current/dead link, the data that's sent down to your create_tasking function is the exact same as when you use the ParameterType.ConnectionInfo - i.e. information about the host, payload uuid, callback uuid, and the p2p c2 profile parameter information.

What is it

This message type allows agents to report back new or removed connections between themselves or elsewhere within a p2p mesh. Mythic uses these messages to construct a graph of connectivity that's displayed to the user and for handling routing for messages through the mesh.

Agent message to Mythic

The agent message to Mythic has the following form:

Just like other messages, this message has the same UUID and encryption requirements found in . Some things to note about the fields:

• edges is an array of JSON objects describing the state of the connections that the agent is adding/removing. Each edge in this array has the following fields:

  • source this is one end of the p2p connection (more often than not, this is the agent that's reporting this information)

  • destination this is the other end of the p2p connection

  • metadata is additional information about the connection that the agent wants to report. For example, when dealing with SMB bind pipes, this could contain information about the specific pipe name instances that are being used if they're being programmatically generated.

  • action this indicates if the connection described above is to be added or removed from Mythic.

  • c2_profile this indicates which c2 profile is used for the connection

Response message from Mythic

After getting a message like this, Mythic responds with a message of the following form:

This is very similar to most other response messages from the Mythic server.

Automatic Connection Announcements

When an agent sends a message to Mythic with a delegate component, Mythic will automatically add a route between the delegate and the agent that sent the message.

For example: If agentA is an egress agent sending messages to a C2 Docker container and it links to agentB, a p2p agent. There are now a few options:

• If the p2p protocol involves sending messages back-and-forth between the two agents, then agentA can determine if agentB is a new payload, trying to stage, or a complete callback. When agentB is a complete callback, agentA can announce a new route to agentB.

• When agentA sends a message to Mythic with a delegate message from agentB, Mythic will automatically create a route between the two agents.

This distinction is important due to how the p2p protocol might work. It could be the case that agentB never sends a get_tasking request and simply waits for messages to it. In this case, agentA would have to do some sort of p2p comms with agentB to determine who it is so it can announce the route or start the staging process for agentB.

Command Component

The supported ui features flag on the command that does this tasking needs to have the following set:supported_ui_features = ["process_browser:list"] if you want to be able to issue a process listing from the UI process listing table. If you don't care about that, then you don't need that feature set for your command.

Why a Unified Process List per Host

There are many instances where you might have multiple agents running on a single host and you run common tasking like process lists over and over and over again. You often do this because the tasking has scrolled out of view, maybe it's just stale information, or maybe you couldn't quite remember which callback actually had that task. This is where the unified process listing comes into play.

With a special format for process listing, Mythic can track all the different process lists together for a single host. It doesn't matter which host you ran the task on, as long as you pull up the process_list view for that host, all of the tasks will be available and viewable.

Output Format

Naturally, this has a special format for us to make it the most useful. Like almost everything else in Mythic, this requires structured output for each process we want the following:

All that's needed is an array of all the processes with the above information in the processes field of your post_response action. That allows Mythic to create a process hierarchy (if you supply both process_id and parent_process_id) and a sortable/filterable table of processes. The above example shows a post_response with one response in it. That one response has a processes field with an array of processes it wants to report.

Any field that ends with _time expects the value to be an int64 of unix epoch time in milliseconds. You're welcome to supply any additional field you want about a process - it all gets aggregated together and provided as part of the "metadata" for the process that you can view in the UI in a nice table listing.

For example, a macOS agent might report back signing flags and entitlements and a windows agent might report back integrity level and user session id.

Payload container, X, of version Y is not supported

All Payload containers leverage the mythic_container PyPi package or the github.com/MythicMeta/MythicContainer golang package. These packages keeps track of a version that syncs up with Mythic when the container starts. As Mythic gains new functionality or changes how things are done, these containers might not be supported anymore. At any given time, Mythic could support only a single version or a range of versions. A list of all PyPi reported versions and their corresponding Mythic version/DockerImage versions can be found here.

How do I fix this?

The agent in question needs to have its container updated or downgraded to be within the range specified by your version of Mythic. If you're using a Dockerimage from itsafeaturemythic (i.e. in your Mythic/Payload_Types/[agent name]/Dockerfile it says FROM itsafeaturemythic/something) then you can look here to see which version you should change to.

C2 Profile's internal server stopped

This is a warning that a C2 Profile's internal service was started, but has since stopped. Typically this happens as a result of rebooting the Mythic server, but if for some reason a C2 Profile's Docker container restarts, you'll get this notification as well.

If a C2 Profile is manually stopped by an operator instead of it stopping automatically for some other reason, the warning message will reflect the variation:

How do I fix this?

Go to the C2 Profiles page and click to "Start Internal Server". If the container went down and is still down, then you won't be able to start it from the UI and you'll see a different button that you "Can't Start Server". If that's the case, you need to track down why that container stopped on the host.

Failed to correlate UUID, X, to something Mythic knows

The "Failed to correlate UUID" message means that data came in through some C2 Profile, made its way to Mythic, Mythic base64 decoded the data successfully and looked at the first characters for a UUID. In Mythic messages, the only piece that's normally not encrypted is this random UUID4 string in the front that means something to Mythic, but is generally meaningless to everybody else. Mythic uses that UUID to look up the callback/payload/stage crypto keys and other related information for processing. In this case though, the UUID that Mythic sees isn't registered within Mythic's database. Normally people see this because they have old agents still connecting in, but they've since reset their database.

Looking at the rest of the message, we can see additional data. All C2 Profile docker containers add an additional header when forwarding messages to the Mythic server with mythic: c2profile_name. So, in this case we see 'mythic': 'http' which means that the http profile is forwarding this message along to the Mythic server.

How do I fix this?

First check if you have any agents that you forgot about from other engagements, tests, or deployments. The error message should tell you where they're connecting from. If the UUID that Mythic shows isn't actually a UUID format, then that means that some other data made its way to Mythic through a C2 profile. In that case, check your Firewall rules to see if there's something getting through that shouldn't be getting through. This kind of error does not impact the ability for your other agents to work (if they're working successfully), but does naturally take resources away from the Mythic server (especially if you're getting a lot of these).

Exec user process caused: no such file or directory

If you are going back-and-forth between windows and linux doing edits on files, then you might accidentally end up with mixed line endings in your files. This typically manifests after an edit and when you restart the container, it goes into a reboot loop. The above error can be seen by using sudo ./mythic-cli logs [agent name].

How do I fix this?

Running dos2unix on your files will convert the line endings to the standard linux characters and you should then be able to restart your agent sudo ./mythic-cli start [agent name]. At that point everything should come back up.

Example (agent response):

Walkthrough:

The agent can report back multiple credentials in a single response. The credential_type field represents the kind of credential and must be one of the following:

• plaintext

• certificate

• hash

• key

• ticket

• cookie

The other fields are pretty straightforward, but they must all be provided for each credential. There is one optional field that can be specified here: comment. You can do this manually on the credentials page, but you can also add comments to every credential to provide a bit more context about it.

Mythic has a special page specifically for viewing screenshots by clicking the camera icon at the top of any of the pages.

When it comes to registering screenshots with Mythic, the process is almost identical to File Downloads (Agent -> Mythic); however, we set the is_screenshot flag to true in the download portion of the message:

{"action": "post_response", "responses": [
    {
        "task_id": "UUID here",
        "download": {
            "total_chunks": 4, 
            "full_path": "/test/test2/test3.file" // full path to the file downloaded
            "host": "hostname the file is downloaded from"
            "is_screenshot": true //indicate if this is a file or screenshot
        }
    }
]}

What does it mean to download a file?

This section is specifically for downloading a file from the agent to the Mythic server. Because these can be very large files that you task to download, a bit of processing needs to happen: the file needs to be chunked and routed through the agents.

In general, there's a few steps that happen for this process (visually this can be found on the Message Flow page):

1. The operator issues a task to download a file, such as download file.txt

2. This gets sent down to the agent in tasking, the agent locates the file, and determines it has the ability to read it. Now it needs to send the data back

3. The agent first gets the full path of the file so that it can return that data. That's a quality of life requirement so that operators don't need to supply the full path when specifying files, but so that Mythic can still properly track all files, especially ones that have the same name.

4. The agent then sends an initial message to the Mythic server indicating that it has a file to send. The agent specifies how many chunks it'll take, and which task this is for. If the agent specifies that there are -1 total chunks, then Mythic will expect at some point for the agent to return a total chunk count so that Mythic knows the transfer is over. This can be helpful when the agent isn't able to seek the file length ahead of time.

5. The Mythic server then registers that file in the database so it can be tracked. This results in a file UUID. The Mythic server sends back this UUID so that the agent and Mythic can make sure they're talking about the same file for the actual transfer.

6. The agent then starts chunking up the data and sending it chunk by chunk. Each message will have chunk_size amount of data base64 encoded, the file UUID from step 5, and which chunk number is being sent. Chunk numbers start at 1.

7. The Mythic server responds back with a successful acknowledgement that it received each chunk

It's not an extremely complex process, but it does require a bit more back-and-forth than a fire-and-forget style. This process allows Mythic to track how many chunks it'll take to download a file and how many have been downloaded so far. The rest of this page will walk through those steps with more concrete code examples.

Example (agent response pt. 1):

When an agent is ready to transfer a file from agent to Mythic, it first needs to get the full_path of the file and determine how many chunks it'll take to transfer the file. It then creates the following structure:

{"action": "post_response", "responses": [
    {
        "task_id": "UUID here",
        "download": {
            "total_chunks": 4, 
            "full_path": "/test/test2/test3.file" // full path to the file downloaded
            "host": "hostname the file is downloaded from" // optional
            "is_screenshot": false //indicate if this is a file or screenshot (default is false)
        }
    }
]}

The host field allows us to track if you're downloading files on the current host or remotely. If you leave this out or leave it blank (""), then it'll automatically be populated with the callback's hostname. Because you can use this same process for downloading files and downloading screenshots from the remote endpoint in a chunked fashion, the is_screenshot flag allows this distinction. This helps the UI track whether something should be shown in the screenshot pages or in the files pages. If this information is omitted, then the Mythic server assumes it's a file (i.e. is_screenshot is assumed to be false). This message is what's sent as an Action: post_response message.

Mythic will respond with a file_id:

{"action": "post_response", "responses": [{
        "status": "success",
        "file_id": "UUID Here"
        "task_id": "task uuid here",
    }
]}

Example (agent response pt. 2-n):

The agent sends back each chunk sequentially and calls out the file_id its referring to along with the actual chunked data.

Mythic tracks the size of chunks, but doesn't search via offsets to insert chunks out of order, so make sure you send the chunks in order.

{"action": "post_response", "responses": [{
    {
        "task_id": "task uuid",
        "download": {
            "chunk_num": 1, 
            "file_id": "UUID From previous response", 
            "chunk_data": "base64_blob==",
        }
    }
]}

For each chunk, Mythic will respond with a success message if all went well:

{"action": "post_response", "responses": [{
    {
        "status": "success"
        "task_id": "task uuid here"
    }
]}

Once all of the chunks have arrived, the file will be downloadable from the Mythic server.

What does it mean to upload a file?

This section is specifically for uploading a file from the Mythic server to an agent. Because these messages aren't just to an agent directly (they can be routed through a p2p mesh), they can't just be as simple as a GET request to download a file. The file needs to be chunked and routed through the agents. This isn't specific to the upload command, this is for any command that wants to leverage a file from Mythic.

In general, there's a few steps that happen for this process (this can be seen visually on the page):

1. The operator issues some sort of tasking that has a parameter type of "File". You'll notice this in the Mythic user interface because you'll always see a popup for you to supply a file from your file system.

2. Once you select a file and hit submit, Mythic loops through all of the files selected and registers them. This process sends each one down to Mythic, saves it off to disk, and assigns it a UUID. These UUIDs are what's stored in place of the raw bytes when you submit your task. So, if you had an upload command that takes a file and a path, your arguments would end up looking like {"file":"uuid", "path": "/some/path"} rather than {"file": raw bytes of file, "path": "/some/path"}.

3. In the Payload Type's corresponding command python file there is a function called 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.

4. To get the file with Mythic, there's an RPC call we can do:

Lines 2-5 is where we do an RPC call with Mythic to search for files, specifically, we want ones where the file_id matches the one that was passed down as part of our parameters. This should only return one result, but the result, for consistency, will always come back as an Array. So, 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.

4. The agent gets the tasking and sees that there's a file UUID it needs to pull. It sends an initial message to Mythic saying that it will be downloading the file in chunks of a certain size and requests the first chunk. If the agent is going to be writing the file to disk (versus just pulling down the file into memory), then the agent should also send 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 .

5. The Mythic server gets the request for the file, makes sure the file exists and belongs to this operation, then gets the first chunk of the file as specified by the agent's chunk_size and also reports to the agent how many chunks there are.

6. The Agent can now use this information to request the rest of the chunks of the file.

It's not an extremely complex process, but it does require a bit more back-and-forth than a fire-and-forget style. The rest of this page will walk through those steps with more concrete code examples.

There is no expectation when doing uploads or downloads that the operator must type the absolute path to a file, that's a bit of a strict requirement. Instead, Mythic allows operators to specify relative paths and has an option in the upload action to specify the actual full path (this option also exists for downloading files so that the absolute path can be returned for better tracking). This allows Mythic to properly track absolute file system paths that might have the same resulting file name without an extra burden on the operator.

Example (agent pull down):

Files can (optionally) be pulled down multiple times (if you set 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.

An agent pulling down a file to the target is similar to downloading a file from the target to Mythic. The agent makes the following request to Mythic:

The 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.

The agent gets back a message like:

This process repeats as many as times as is necessary to pull down all of the contents of the file.

Files in the Tasking JSON

There's a reason that files aren't base64 encoded and placed inside the initial tasking blobs. Keeping the files tracked by the main Mythic system and used in a separate call allows the initial messages to stay small and allows for the agent and C2 mechanism to potentially cache or limit the size of the transfers as desired.

Consider the case of using DNS as the C2 mechanism. If the file mentioned in this section was sent through this channel, then the traffic would potentially explode. However, having the option for the agent to pull the file via HTTP or some other mechanism gives greater flexibility and granular control over how the C2 communications flow.

Example Agent Response

{
    "task_id": "task uuid here",
    "user_output": "some user output here",
    "commands": [
        {
            "action": "add",
            "cmd": "shell"
        },
        {
            "action": "add",
            "cmd": "jsimport"
        }
    ]
}

Walkthrough

It's a common feature for agents to be able to load new functionality. Even within Mythic, you can create agents that only start off with a base set of commands and more are loaded in later. Using the commands keyword, agents can report back that commands are added ("action": "add") or removed ("action": "remove").

This is easily visible when interacting with an agent. When you start typing a command, you'll see an autocomplete list appear above the command prompt with a list of commands that include what you've typed so far. When you load a new command and register it back with mythic in this way, that new command will also appear in that autocomplete list.

Example (agent response):

{
    "task_id": "task uuid here",
    "keylogs": [
        {
            "user": "its-a-feature", 
            "window_title": "Notepad - Untitled", 
            "keystrokes": "my password is zer0c00l"
        }
    ]
}

Walkthrough:

Agents can report back keystrokes at any time. There are three components to a keystroke report:

• user - the user that is being keylogged

• window_title - the title of the window to which the keystrokes belong

• keystrokes - the actual recorded keystrokes

Having the information broken out into these separate pieces allows Mythic to do grouping based on the user and window_title for easier readability.

If the agent doesn't know the user or the window_title fields, they should still be included, but can be empty strings. If empty strings are reported for either of these two fields, they will be replaced with "UNKNOWN" in Mythic.

Multiple users/windows

What happens if you need to send keystrokes for multiple users/windows?

{
    "action": "post_response",
    "responses": [
        {
            "task_id": "task uuid here",
            "keylogs": [
                {
                    "user": "its-a-feature", 
                    "window_title": "Notepad - Untitled", 
                    "keystrokes": "my password is zer0c00l"
                },
                {
                    "user": "its-a-feature", 
                    "window_title": "Notepad - Untitled", 
                    "keystrokes": "my password is zer0c00l"
                }
                ,{
                    "user": "its-a-feature", 
                    "window_title": "Notepad - Untitled", 
                    "keystrokes": "my password is zer0c00l"
                }
            ]
        }
    ]
}

What is Task status

You probably noticed as you used Mythic that there's a status associated with your task. This status goes through a variety of words/colors depending on where things are in the pipeline and what the agent has done with the task. This provides a way for the operator to know what's happening behind the scenes.

What are the default statuses?

By default, a task goes through the following stages with the following statuses:

1. preprocessing - The task is being sent to the Payload Type container for processing (parsing arguments, confirming values, doing RPC functionality to register files, etc)

2. submitted - The task is now ready for an agent to pick it up

3. processing - The task has been picked up by an agent, but there hasn't been any response back yet

4. processed - The task has at least one response, but the agent hasn't marked it as done yet.

5. completed - The task is marked as completed by the agent and there wasn't an error in execution

6. error:* - The agent report back a status of "error"

Can I set my own status?

The agent can set the status of the task to anything it wants as part of its normal post_response information. Similarly, in a task's create_tasking function, you're free to set the task.status value. Anything of the error:* format will show up as red in the Mythic UI as an error for the user.

Mythic supports Windows tokens in two ways: tracking which tokens are viewable and tracking which tokens are usable by the callback. The difference here, besides how they show up in the Mythic interface, is what the agent can do with the tokens. The idea is that you can list out all tokens on a computer, but that doesn't mean that the agent has a handle to the token for use with tasking.

Tokens

As part of the normal responses sent back from the agent, there's an additional key you can supply, tokens that is a list of token objects that can be stored in the Mythic database. These will be viewable from the "Search" -> "Tokens" page, but are not leveraged as part of further tasking.

{ "action": "post_response",
    "responses": [
        {
            "task_id": "uuid here",
            "user_output": "got some tokens yo",
            "tokens": [
                {
                    "token_id": 18947, // required, agent generated
                    "host": "bob.com", // optional
                    "description": "", // optional
                    "user": "bob", // optional
                    "groups": "", //optional
                    "thread_id": 456, // optional
                    "process_id": 2345, // optional
                    "default_dacl": "", //optional p.TextField(null=True)
                    "session_id": 0, //optional p.IntegerField(null=True)
                    "restricted": false, //optional = p.BooleanField(null=True)
                    "capabilities": "", //optional = p.TextField(null=True)
                    "logon_sid": "", //optional = p.TextField(null=True)
                    "integrity_level_sid": 0, //optional = p.IntegerField(null=True)
                    "app_container_number": 0, //optional = p.IntegerField(null=True)
                    "app_container_sid": "", //optional = p.TextField(null=True)
                    "privileges": "", //optional = p.TextField(null=True)
                    "handle": 12345, //optional = p.IntegerField(null=True)
                }
            ]
        }
    ]
}

Callback Tokens

If you want to be able to leverage tokens as part of your tasking, you need to register those tokens with Mythic and the callback. This can be done as part of the normal post_response responses like everything else. The key here is to identify the right token - specifically via the unique combination of token_id and host.

{"action": "post_response",
    "responses": [
        {
            "task_id": "uuid here",
            "output": "now tracking token 12345",
            "callback_tokens": [
                {
                    "action": "add", // could also be "remove"
                    "host": "a.b.com", //optional - default to callback host if not specified
                    "token_id": 12345, // id 
                }
            ]
        }
    ]
}
                    

If the token 12345 hasn't been reported via the tokens key then it will be created and then associated with Mythic.

Once the token is created and associated with the callback, there will be a new dropdown menu next to the tasking bar at the bottom of the screen where you can select to use the default token or one of the new ones specified. When you select a token to use in this way when issuing tasking, the create_tasking function's task object will have a new attribute, task.token that contains a dictionary of all the token's associated attributes. This information can then be used to send additional data with the task down to the agent to indicate which tokens should be used for the task as part of your parameters.

Additionally, when getting tasks that have tokens associated with them, the TokenId value will be passed down to the agent as an additional field:\

{ "action": "get_tasking",
    "tasks": [
        {
            "command": "shell",
            "parameters": "whoami",
            "id": "uuid here",
            "timestamp": 1234567,
            "token": 12345
        }
    ]
}

Components

For the file browser, there are a few capabilities that need to be present and implemented correctly if you want to allow users to list, remove, download, or upload from the file browser. Specifically:

• File Listing - there needs to be a command marked as supported_ui_features = ["file_browser:list"] with your payload type that sends information in the proper format.

• File Removal - there needs to be a command marked as supported_ui_features = ["file_browser:remove"] with your payload type that reports back success properly

• File Download - there needs to be a command marked as supported_ui_features = ["file_browser:download"] with your payload type

• File Upload - there needs to be a command marked as supported_ui_features = ["file_browser:upload"] with your payload type

These components together allow an operator to browse the file system, request listings of new directories, track downloaded files, upload new files, and even remove files. Let's go into each of the components and see what they need to do specifically.

File Listing

There are two components to file listing that need to be handled - what the file browser sends as initial tasking to the command marked as supported_ui_features = ["file_browser:list"]and what data is sent back to Mythic for processing.

Tasking

When doing a file listing via the file browser, the command_line for tasking will always be the following as as JSON string (this is what gets sent as the self.command_line argument in your command's parse_arguments function):

{
  "host": "hostname of computer to list",
  "path": "path to the parent folder",
  "file": "name of the file or folder you're trying to list",
  "full_path": "absolute path to the file/folder"
}

This might be different than the normal parameters you take for the command marked as supported_ui_features = ["file_browser:list"]. Since the payload type's command handles the processing of arguments itself, we can handle this case and transform the parameters as needed. For example, the apfell payload takes a single parameter path as an argument for file listing, but that doesn't match up with what the file browser sends. So, we can modify it within the async def parse_arguments function:

async def parse_arguments(self):
    if len(self.command_line) > 0:
        if self.command_line[0] == '{':
            temp_json = json.loads(self.command_line)
            if 'host' in temp_json:
                # this means we have tasking from the file browser rather than the popup UI
                # the apfell agent doesn't currently have the ability to do _remote_ listings, so we ignore it
                self.add_arg("path", temp_json['path'] + "/" + temp_json['file'])
            else:
                self.add_arg("path", temp_json['path'])
            self.add_arg("file_browser", "true")
        else:
            self.add_arg("path", self.command_line)
            self.add_arg("file_browser", "true")

In the above example we check if we are given a JSON string or not by checking that the self.command_line length is greater than 0 and that the first character is a {. We can then parse it into a Python dictionary and check for the two cases. If we're given something with host in it, then it must come from the file browser instead of the operator normally, so we take the supplied parameters and add them to what the command normally needs. In this case, since we only have the one argument path, we take the path and file variables from the file browser dictionary and combine them for our path variable.

Agent File Browsing Responses

Now that we know how to translate file browsing file listing tasking to whatever our command needs, what kind of output do we need to send back?

We have another component to the post_response for agents.

{
    "action": "post_response",
    "responses": [
        {
            "task_id": "UUID of task",
            "user_output": "file browser issued listing", // optional
            "file_browser": {
                "host": "hostname of computer you're listing", // optional
                "is_file": True or False,
                "permissions": {json of permission values you want to present},
                "name": "name of the file or folder you're listing",
                "parent_path": "full path of the parent folder",
                "success": True or False,
                "access_time": unix epoc time in milliseconds,
                "modify_time": unix epoc time in milliseconds,
                "size": 1345, //size of the entity
                "update_deleted": True, //optional
                "files": [ // if this is a folder, include data on the files within
                    {
                        "is_file": True or False,
                        "permissions": {json of data here that you want to show},
                        "name": "name of the entity",
                        "access_time": unix epoc time in milliseconds,
                        "modify_time": unix epoc time in milliseconds,
                        "size": 13567 // size of the entity
                    }
                ]
            }
        }
    ]
}

Most of this is pretty self-explanatory, but there are some nuances. Only list out the inner files for the initial folder/file listed (i.e. don't recursively do this listing). For the files array, you don't need to include host or parent_path because those are both inferred based on the info outside the files array, and the success flag won't be included since you haven't tried to actually list out the contents of any sub-folders. The permissions JSON blob allows you to include any additional information you want to show the user in the file browser. For example, with the apfell agent, this blob includes information about extended attributes, posix file permissions, and user/group information. Because this is heavily OS specific, there's no requirement here other than it being a JSON blob (not a string).

By having this information in another component within the responses array, you can display any information to the user that you want without being forced to also display this listing each time to the user. You can if you want, but it's not required. If you wanted to do that, you could simply turn all of the file_browser data into a JSON string and put it in the user_output field. In the above example, the user output is a simple message stating why the tasking was issued, but it could be anything (even left blank).

update deleted

There's a special key in there that doesn't really match the rest of the normal "file" data in that file_browser response - update_deleted. If you include this key as True and your success flag is True, then Mythic will use the data presented here to update which files are deleted.

By default, if you list the contents of ~/Downloads twice, then the view you see in the UI is a merge of all the data from those two instance of listing that folder. However, that might not always be what you want. For instance, if a file was deleted between the first and second listing, that deletion won't be reflected in the UI because the data is simply merged together. If you want that delete to be automatically picked up and reported as a deleted file, use the update_deleted flag to say to Mythic "hey, this should be everything that's in the folder, if you have something else that used to be there but I'm not reporting back right now, assume it's deleted".

You might be wondering why this isn't just the default behavior for listing files. There are two main other scenarios that we want to support that are counter to this idea - paginated results (only return 20 files at a time) and filtered results (only return files in the folder that end in .txt). In these cases, we don't want the rest of the data to be automatically marked as deleted because we're clearly not returning the full picture of what's in a folder. That's why it's an optional flag to say to performing the automatic updates. If you want to be explicit with things though (for example, if you delete a file and want to report it back without having to re-list the entire contents of the directory), you can use the next section - FIle Removal.

File Removal

There are two components to file listing that need to be handled - what the file browser sends as initial tasking to the command marked as supported_ui_features = ["file_browser:remove"]and what data is sent back to Mythic for processing.

Tasking

This is the exact same as the supported_ui_features = ["file_browser:list"]and the File Browser section above.

Agent File Removal Responses

Ok, so we listed files and tasked one for removal. Now, how is that removed file tracked back to the file browsing to mark it as removed? Nothing too crazy, there's another field in the post_response:

{
    "action": "post_response",
    "responses": [
        {
            "task_id": "UUID of task",
            "user_output": "File successfully deleted",
            "removed_files": [
                {
                    "host": "hostname where file was removed",
                    "path": "full path to the file"
                }
            ]
        }
    ]
}

This removed_files section simply returns an array of dictionaries that spell out the host and paths of the files that were deleted. On the back-end, Mythic takes these two pieces of information and searches the file browsing data to see if there's a matching path for the specified host in the current operation that it knows about. If there is, it gets marked as deleted and in the UI you'll see a small trashcan next to it along with a strikethrough.

This response isn't ONLY for when a file is removed through the file browser though. You can return this from your normal removal commands as well and if there happens to be a matching file in the browser, it'll get marked as removed. This allows you to simply type things like rm /path/to/file on the command-line and still have this information tracked in the file browser without requiring you to remove it through the file browser specifically.

File Downloading

There are two components to file listing that need to be handled - what the file browser sends as initial tasking to the command marked as supported_ui_features = ["file_browser:download"]and what data is sent back to Mythic for processing.

Tasking

This is the exact same as the supported_ui_features = ["file_browser:list"] and the File Browser section above.