This repo defines the folder structure for an external Mythic agent that can be remotely "installed" into a Mythic instance. This process allows users to create their own Mythic agents and host them on their own GitHub repositories while also allowing an easy process to install agents.
This project is a template for what your git-based repository should look like. Simply copy/fork this project and update it with your agent's information. Then, you can use the corresponding install command from within the Mythic repo to install this agent. The Mythic install script for 3rd party agents should work for any git-based repository (GitHub, GitLab, Bitbucket, etc).
sudo ./mythic-cli install github <url to your agent> [optional branch name]
When it's time for you to test out your install or for another user to install your agent, it's pretty simple. Within Mythic is a mythic-cli binary you can use to install agents:
sudo ./mythic-cli install github https://github.com/user/repoto install the main branchsudo ./mythic-cli install github https://github.com/user/repo branchnameto install a specific branch of that repo
Now, you might be wondering when should you or a user do this to properly add your agent to their Mythic instance. There's no wrong answer here, just depends on your preference. The three options are:
- Mythic is already up and going, then you can run the install script and just direct that agent's containers to start (i.e.
sudo ./mythic-cli payload start agentNameand if that agent has its own special C2 containers, you'll need to start them too viasudo ./mythic-cli c2 start c2profileName). - Mythic is already up and going, but you want to minimize your steps, you can just install the agent and run
sudo ./mythic-cli mythic start. That script will first stop all of your containers, then start everything back up again. This will also bring in the new agent you just installed. - Mythic isn't running, you can install the script and just run
sudo ./mythic-cli mythic start.
This folder should contain exactly what you have in your Payload_Types folder for Mythic. Specifically, it should contain one folder with the same name as your agent.
Example: https://github.com/its-a-feature/Mythic/tree/master/Payload_Types
This folder should contain exactly what you have in your C2_Profiles folder if you added a new C2 Profile for your agent. Specifically, it should containe a folder with the name of the C2 Profile for every C2 Profile you added. If you have no additional C2 Profiles, leave this folder empty.
Example: https://github.com/its-a-feature/Mythic/tree/master/C2_Profiles
This folder contains all of the contents for the documentation-docker container that petains to your new C2 profiles (if any). If you have no extra documentation, then leave this folder empty.
Example: https://github.com/its-a-feature/Mythic/tree/master/documentation-docker/content/C2%20Profiles
This folder contains all of the contents for the documentation-docker container that pertains to your new payload type. If you have no documentation (you reall should though), then leave this folder empty.
Example: https://github.com/its-a-feature/Mythic/tree/master/documentation-docker/content/Agents
If you are creating any "wrapper" style payload types, the documentation for those go in a slightly different location with a slightly different format. Wrapper payload types don't have any C2 or commands associated with them; instead, they take in another agent and "wrap" it with a more generic mechanism (service executable, office macro, obfuscation, etc). While the wrapper payload type code goes into the same Payload_Type area, the documentation is broken out. Copy that documentation here similar to:
https://github.com/its-a-feature/Mythic/tree/master/documentation-docker/content/Wrappers
This folder contains the svg icons that should be used for the agent. This svg icon is used on the Payload Types page, on the active callbacks page, and when viewing the graph/tree modes of your callbacks.
This file configures which components to ignore on the install process.
Setting this value to true means that after cloning down the remote repository, the installer program will NOT copy the contents of the Payload_Type folder into the local Payload_Types folder. This is helpful for when an agent's Payload Type contents needs to be installed on a specific computer/VM and not used as part of a Docker deployment.
Setting this value to true means that after cloning down the remote repository, the installer program wil NOT copy the contents of the C2_Profiles folder into the local C2_Profiles folder. This is helpful for when an agent's C2 Profiles might need to run on a different Computer/VM and not used as part of a Docker deployment locally to Mythic.
Setting this value to true will prevent Mythic from copying the contents into the documentation-docker's agent folders.
Setting this value to true will prevent Mythic from copying the contents into the documentation-docker's c2 folders.
Setting this value to true will prevent Mythic from copying the contents into the mythic-docker/app/static folder with the other icons.