A brief overview of Mythic 3.3’s new features

Mythic 3.3 Updates

Mythic 3.3 has too many updates to mention them all here, so if you want a deeper dive into the change log, please check it out on GitHub. Instead, we’re going to focus on the biggest changes and why you should care.

Because this Mythic update has so many bug fixes and new features, it is going into a public Beta phase for a few weeks first. To use this Mythic and any updated agents/profiles, be sure to use the Mythic3.3 branches. When installing a C2 Profile or Payload Type with the Mythic3.3 beta, you can use the following: sudo ./mythic-cli install github [url] -b Mythic3.3 -f

The following projects are updated with a Mythic3.3 branch for experimentation: Mythic, Poseidon, Apollo, http, websocket, smb, httpx, basic_webhook, basic_logger, and example_containers. You can also check out the Mythic Overview page to see which installable services are updating.

tldr; what breaking changes are there and how do I update my existing components to work with Mythic 3.3? Check here.

Eventing

Have you ever been on an assessment and thought any of the following:

• I wish I could run a series of tasks every time I get a new callback
• I wish I could automatically increase the sleep time of all my callbacks at the end of the workday and lower the sleep time at the beginning of my work
• I wish I could automatically create a bunch of payloads and feed them through various wrappers
• I wish I could send an alert from my agent to Mythic and trigger a series of actions (like dumping credentials when a new logon happens)
• I wish I could provide my own custom operation security checks across all tasks for all callbacks
• I wish I could intercept a task’s output and augment it before showing it to the user

Well, all of that and more is possible with Mythic’s new eventing system. The eventing system is configured via JSON/YAML/TOML files in a similar way to GitHub’s Actions. Clicking the play icon at the top of Mythic will open a new page where you can manage the eventing options for your operation. Mythic has a default set of action types you can take, but you can also implement your own eventing containers and call arbitrary functions within them. This, combined with access to per-event APITokens and Mythic’s Scripting means that you can do almost anything as an action.

Be sure to check out the Mythic documentation for more details on configurations.

Command Augmentation

One of the more unique aspects of Mythic that everybody can create their own agents that all hook into the same one interface. However, this sometimes means that efforts are duplicated. For example, a few different agents have the capability to run Beacon Object Files (BOFs) in a generic way, but this still means that you need to know ahead of time which arguments each BOF takes, their order, and their types.

If you wanted to leverage Mythic’s unique command parameter functionalities (tab completion, parameter groups, named parameters, etc) for a BOF, then you’d need to create command files and load them up into each payload type and load them into each callback. That can be tedious, especially if some agents use Python and some use Go for their containers. Instead, what if we could build it once in a generic way and automatically “inject” these commands into new callbacks? That’s the idea for command augmentation.

Command Augmentation containers allow you to define everything about a Payload Type like normal, except there’s no build, wrapper, or C2 Profile aspects to worry about. Instead, you’re just defining your commands and general information about your Payload Type so that it can be easily identified in the UI (such as the screenshot above). Just like with normal Payload Types, you can control which callbacks your commands can be associated with. You can scope down your callbacks via Operating System type and even limit via specific agents!

Be sure to check out more details in the documentation!

Auto Triage Tracking

Do you ever get into the swing of things in an assessment, triaging a bunch of file shares and downloading files, but then forget which files you’ve looked at after you’ve downloaded them? Mythic now automatically uses its tagging system to mark which files you downloaded or previewed and when.

Custom Authentication and Invites

Randomly generating passwords each time you stand up a Mythic instance or trying to remember your Mythic credentials in addition to so many other credentials can be tedious. If you already have Single Sign On (SSO) set up for your company, then it can be handy to simply use that for your operators instead. Mythic now offers “Auth” containers that allow you to extend Mythic’s authentication process into whatever best suits your environment. For example, you can hook into SAML and ADFS or prompt the user for additional information (like a MFA key) when authenticating. When your container is online and supports one of these methods, the login page will allow a new dropdown for you to select from.

The example_containers repository has an example of adding ADFS SSO support in Go via SAML that can be ported over to Python.

It’s also easier to collaborate with additional operators by creating invite links to Mythic. It’s disabled by default and only possible from administrators, but you can create one-time use invite links where users can create their own accounts as they log in.

If an invite hasn’t been used, you can always delete it and it’ll no longer be valid for use.

Dead Callback Estimation

A long requested feature is the ability to somehow identify callbacks in the Mythic UI as dead. This is a notoriously difficult problem to do in a generic way from Mythic’s point of view. Because each Payload Type can provide its own parameters, you really can implement “sleep” and “jitter” however you want. Some use sleep in seconds and jitter in percentages, some have additional parameters like skew, and some others have additional concepts like working hours or working days. That’s why there’s a new function available to Payload Type developers — CheckIfCallbacksAlive.

The person that best knows if their Payload Type should be considered dead or not is the developer of that Payload Type. Callbacks already have a parameter to track sleep_info, so now there’s something that can use that outside of just the Mythic UI. The screenshot below shows an example where some callbacks are estimated to be dead.

Notice how this isn’t a super intrusive element. This is just an estimation based on available information, but is no guarantee that the callback is dead. There could be a large number of factors that might temporarily interrupt an callback from checking in for longer than normal. Once a minute Mythic looks at all of the active callbacks, sorts them by Payload Type, and sends their information to that Payload Type’s container to determine if they’re likely dead or not.

Consuming Container Tracking and SSO

Many of these new features don’t quite make sense in the Payload Types / C2 Profiles page. To track these new kinds of containers in a meaningful way, the “Consuming Containers” page got an overhaul:

This information is available via the hamburger icon in the top left, selecting services, and finally consuming services. If you choose to create an Auth container for your Mythic instance (such as to add SSO support), this is where that container will appear.

You’ll also notice that each container has a new “file” icon next to it. There is now the option to list/edit/upload/download/delete files within any of the containers (not just C2 Profiles anymore). This makes it much easier to edit and configure custom containers.

Conclusion

This was just an example of some of the updates for Mythic 3.3, so please be sure to check out the changelog and documentation for more details! As always, if you have requests, comments, issues, or feedback of any kind please submit on GitHub or reach out on Twitter/Slack!

If you’re curious about some of these new features, how Mythic works in general, or how to get started doing some local agent development, be sure to check out a recent live stream I was on:

Mythic Development Workflow with @its_a_feature_

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

*** This is a Security Bloggers Network syndicated blog from Posts By SpecterOps Team Members - Medium authored by Cody Thomas. Read the original post at: https://posts.specterops.io/mythic-3-3-beta-rise-of-the-events-6aeb84aa6fed?source=rss----f05f8696e3cc---4