Mythic 3.3 — Out of Beta

Mythic 3.3 — Out of Beta

Mythic 3.3 was released in a Beta six weeks ago, and since then there has been a bunch of feedback, not just about new Mythic 3.3 features but about the framework overall. Now that Mythic is exiting Beta and going to a full release, I wanted to take a moment and highlight some of these newer features that aren’t in the original announcement post for Mythic 3.3.

File Rendering

When downloading files in Mythic 3.2, Mythic offered a series of buttons you could click to try to render the downloaded file in your browser or to preview the first 512KB of the file as strings or hex. Now, in Mythic 3.3, this view is updated to condense all that functionality into one solution. This also provides some contextual metadata about the file at the top. If the file is text, then Mythic will automatically try to determine the file syntax based on the file extension and automatically select the right syntax highlighter. The following screenshot shows the download of a Golang file with the new in-line media renderer:

This functionality is available for browser scripts with the media field as well as in the file search page and file browser.

File Browser

During assessments, operators might spend a large amount of time in Mythic’s file browser triaging multiple hosts and file shares to find that one special file that gives them the keys to the kingdom. Because of this, it’s important to have a workflow that minimizes operator friction. The new file browser in Mythic 3.3 has a lot of improvements to help with this:

The new file browser has a few more buttons in the top navigation pane to help movement feel more natural. There’s forward and backward icons to go through your traversal history as well as an up icon to go up a folder. If you get file browser data for a folder, Mythic will automatically infer that the parent folders must exist on the system, even though you haven’t explicitly listed them. To make this scenario clearer, Mythic now displays a message indicating that you don’t have data for this path explicitly and gives a helpful button to task an agent to list it.

On the right-hand side there’s a new button next to the file upload cloud. This is disabled by default, but when enabled, if you browse to a folder that has not yet been listed (such as in the screenshot above), then Mythic will automatically issue the list tasking for you. This allows you to quickly click through folders and have tasks kick off to fetch data without you explicitly clicking “list” each time.

If you try to list out the contents of a folder and get denied, Mythic will show a red exclamation point, but in Mythic 3.2 you wouldn’t get any additional context from the file browser itself. In Mythic 3.3, the file browser will change to show you the exact task that failed so you can see why (such as the access denied in the following screenshot):

Situational Tracking

As you’re operating and you get many callbacks from your targets, it can be difficult to correlate which tab you’re interacting with and which callback that corresponds to. Similarly, when you’re browsing in the file browser, it can be easy to lose track of where you are in the tree view if you’re clicking through folders on the table view. To help with this, both the file browser and active callbacks table will auto scroll and highlight what you’re interacting with.

This means as you click between your active tabs, the corresponding callback is highlighted and scrolled into view if needed. In the screenshot below we have a file browser tab for callback 1757 selected and we can see the corresponding callback also highlighted at the top.

Interactive Task Searching

One of the newer features of Mythic3.2 is the ability to perform “interactive” actions through your normal async communications channels. This can manifest in a variety of different ways in agents, but a common implementation is to allow an operator to drop into a pseudo terminal on the target and run commands. When doing this through Poseidon's pty command, you drop into your specified terminal and get a full logon session, complete with the user’s environment, *rc files, and history. This also means you can save environment variables and even run sudo normally (including providing a password).

While this is extremely helpful, it breaks one of Mythic’s normal flows — task and output tracking. You’re issuing new tasks to your agent (which are tracked), but all of the output is smashed together through the interactive tasking command. While you’re interacting with the task, this isn’t a huge issue, but when it comes time to search, there’s no more correlation. In Mythic 3.2, this meant you’d have to specifically search for the overarching interactive task and just browse through all the output to find what you’re looking for. In Mythic 3.3 though, we can approximate the responses from around the time that the task was issued and guess what the output might be. In the screenshot below we can see that we issued whoami to a pty task. We fetch the first five results from the agent after that task was issued and return that to the user with an indication of which pty task this belonged to.

There’s still plenty of room for improvement in this area, but this gets closer to bringing this sort of tasking inline with the normal Mythic tasking flows.

Preferred Tasking Views

Since Mythic tracks tasks and their output, there’s many ways we can display this data. The normal view is an accordion style where you expand the task to see the output, but can collapse it away to see more tasks at once. This can result in double scroll bars as you scroll through tasks and through large task output. To help with this, there’s also a “split tasking” view where all the tasks are on one side and all of output is on another. You can only see one task’s output at a time, but at least there’s no double scroll bars. The last view that’s currently in Mythic is an attempt at somewhere between the previous two — it’s a “console”-like view where there are accordions, but they’re all expanded by default and don’t collapse.

Naturally, everybody has their own preference as to the view they prefer, so Mythic 3.3 is allowing you to set that preference. The screenshot below shows a snippet of a user’s settings page where you can choose your preferred default.

To make this preference even easier for users, you can double click any callback row and open a tab based on your interactive preferences (or you can click the icon next to your callback number in the table):

You can also now right-click anywhere in the active callbacks table and get a handy dropdown menu to interact with the callback (instead of having to click the small dropdown arrow). As you can see in the above screenshot, all of the tasking views are always available to choose from, but your preferred default will also change the icons next to the callback identifiers.

Host Networking

Mythic uses Docker and Docker Compose to organize the various main Mythic services as well as any third-party service you install (agents, c2 profiles, etc). Because of this, the main Mythic binary runs within a Docker container with certain ports exposed for various things like SOCKS. This is of course a configurable field in Mythic/.env with the MYTHIC_SERVER_DYNAMIC_PORTS variable and the defaults set to ports 7000–7010.

However, when it comes to things like reverse port forwards, I’ve noticed this starts to cause an issue for people. A common scenario is to do a local port forward from the Mythic server to an operator’s attacker workstation, and then a reverse port forward from the target computer to that specified port on the Mythic server. Many people want to access this “local” port via 127.0.0.1 or localhost, but since the connection initiates from within a Docker container, those resolve to within the Docker container, not the host. This means people have to reference that “local” port on the Mythic server via the server’s IP address, but that can cause issues because additional firewall rules might come into play since you’re not accessing it via the loopback.

To combat all of this, there’s now an option in Mythic 3.3 in Mythic/.env for MYTHIC_DOCKER_NETWORKING. This is set to bridge by default and everything works as normal. If you set this to host and restart Mythic, then all of the Mythic services (mythic, jupyter, postgres, rabbitmq, nginx, react, graphql, etc) will change to host networking. The mythic-cli is smart enough to detect this change and adjust everything in the docker-compose properly to reflect this, as well as updating configs for the various services so that they are still bound to 127.0.0.1 by default (instead of 0.0.0.0). In our previous scenario though, it means that Mythic will be able to connect to that “local” port via the loopback interface properly.

Everything is still using Docker and Docker compose, but the ability to switch to host networking provides a greater level of flexibility. There is a caveat though — Docker Desktopdoes not support host networking. So, if you’re just using docker on a Linux computer, you’re fine, or if you’re using something like orbstack on a macOS computer, you’re fine. If you’re using Docker Desktop on macOS or Windows though, then it’ll appear as though this feature will work, but none of your ports will actually be exposed to your host system. This is just due to how Docker Desktop works under the hood. Mythic uses host networking already for all installed third-party services (agents, c2 profiles, etc), so those won’t work with Docker Desktop anyway.

Acknowledgements

I wanted to give a special shoutout to Lee Chagolla-Christensen. Lee provides a lot of valuable feedback and was the guiding force behind all of these awesome quality of life updates for operators.

Feedback

If you have any feedback, feature requests, bug reports, or just general comments about Mythic, any of its agents, or any of its C2 Profiles, please feel free to reach out on Twitter or in the BloodHound Slack!

Mythic 3.3 — Out of Beta was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.