Mythic Wrappers and Building Your Own

Table of Contents

After building a payload in Mythic, there’s often still work to do before it’s ready for delivery—packaging it into an archive, wrapping it in a specific format, or applying a technique your team uses on every engagement. That usually means downloading the artifact and running additional tools locally, which slows things down and makes it harder to keep everyone on the same workflow.

Mythic wrappers solve this by handling those post-build steps inside the platform. A wrapper takes an already-compiled agent and repackages it into a new format without adding its own C2 or commands. Community wrappers like service_wrapper and scarecrow_wrapper cover common delivery formats, but you can also build your own for the steps specific to your team.

In this post, I’ll cover what Mythic wrappers are, how to structure a custom wrapper project, and walk through compressor_wrapper - a simple wrapper I built to package payloads into zip or tar archives at build time.

Mythic Wrapper

You can chain wrappers together, feeding one wrapper’s output into another. That lets you build multi-stage payloads entirely within the Mythic UI instead of downloading artifacts and repackaging them by hand.

For the full technical details, see Mythic’s wrapper documentation. A few community examples:

Building a Custom Wrapper

The community wrappers above cover common delivery formats, but you’ll eventually run into a post-build step your team handles manually every engagement. A custom wrapper moves that step into Mythic so the repackaging happens automatically when the payload is generated.

That has a few practical benefits:

  • Everything stays in one place. Testers don’t need extra tools installed locally just to finish preparing a payload.
  • Deployment is faster since there’s no download-then-repackage workflow between build and delivery.
  • Testing stays consistent across the team. Everyone follows the same wrapper and build parameters instead of relying on individual techniques or ad hoc scripts.

Project Structure

A wrapper repo follows the same external agent format as a normal Mythic payload type, with a few differences:

  • Documentation goes in documentation-wrapper/.
  • Under Payload_Type/wrapper-name/, you don’t need agent_functions/ or browser_scripts/ directories. Wrappers have no commands to implement.
  • The wrapper logic can live in a single file under Payload_Type/wrapper-name/, depending on complexity. A simple wrapper might be entirely contained in main.go or a single Python builder module.
  • In the build file, the agentstructs.PayloadType definition must set Wrapper: true so Mythic treats it as a wrapper payload type.

Shown below for a Go-based wrapper:

├── agent_capabilities.json
├── agent_icons
│   └── logo.svg
├── C2_Profiles
├── config.json
├── documentation-c2
├── documentation-payload
├── documentation-wrapper
│   └── wrapper-name
│       ├── _index.md
│       └── logo.svg
├── LICENSE
├── Payload_Type
│   └── wrapper-name
│       ├── logo.svg
│       ├── Dockerfile
│       ├── go.mod
│       ├── go.sum
│       └── main.go
└── README.md

Compressor Wrapper

To put the concepts above into practice, I built compressor_wrapper - a simple wrapper that takes a compiled payload and packages it into an archive for delivery. Instead of downloading the agent from Mythic and manually running zip or tar on your local machine, the wrapper handles it at build time. It supports standard archive formats including zip (with optional password protection), tar, tar.gz, tar.bz2, and tar.xz.

This is a good example of the kind of post-build step that doesn’t need to live outside Mythic. Previously, packaging for delivery meant an extra manual step every time you generated a payload. Moving that into a wrapper keeps the workflow in one place and gives every operator the same packaging options.

Installation

Install it the same way you would any other Mythic agent:

./mythic-cli install github https://github.com/lum8rjack/compressor_wrapper

Agent Setup

Before using compressor, the agent you’re wrapping needs to declare support for it. In the agent’s payload definition, add compressor to CanBeWrappedByTheFollowingPayloadTypes:

CanBeWrappedByTheFollowingPayloadTypes: []string{"compressor"},

Usage

Once installed, log into Mythic and build your agent as you normally would. Then:

  1. Click Create Wrapper in the left sidebar.
  2. Select the operating system, choose compressor as the payload type, and click Start Fresh.
  3. Complete the build form:
    • Name — the filename of the payload inside the archive
    • Method — the compression format (zip, tar, tar.gz, etc.)
    • Use password — toggle on when using zip, then enter a Password
  4. On the next page, select the payload you built earlier.
  5. Name the archive, add an optional description, and click Create Payload.

When the build finishes, go to Payloads to download the archive. That’s it—the compiled agent is already packaged and ready for delivery.

Wrappers are one of the simpler Mythic components to build, and they’re a good place to start if you want to automate the repetitive steps that happen after payload generation. If you have a post-build workflow your team runs every engagement, it’s worth turning into a wrapper.

References