Payload wrappers registration

[paul-axe]

Hi. I was playing with writing custom payload wrappers and faced the behavior which I think can be improved.

Currently every payload type should specify the list of wrappers which can be used with it. This means that if I am implementing a wrapper which is applicable to any OS-specific payload (lets say to any Linux payload) I will need to go through every Linux-compatible payload source code and add my own wrapper to it. Considering that later I will want to receive updates from the upstream of this payload type, I will need to deal with patch management.

In my opinion, it will be better if we will be able to specify which kind of payloads can be wrapped by wrapper it the wrapper configuration. What do you think about it?

I checked the source code and it looks like it should be easy to implement this idea and it should not break anything (please let me know if I missing something). Of course, we can keep old behavior for compatibility, adding new field and logic only for payload wrappers.

If you think that my idea is good I will be happy to contribute :)

[its-a-feature]

This is actually something that I've gone back and forth on a bunch.

For the current implementation, I tried to keep things consistent and give ultimate control to the agent developers for both Wrappers and C2 Profiles. Right now, the agent developer identifies what it supports (which wrappers and which c2 profiles). That way Bob, as the developer of AgentB, can look at WrapperA and decide if they can support it or not. It becomes trickier, from a public sense, for WrapperA to say that AgentB supports it because if there's an issue, Bob might not have any knowledge of WrapperA. From an internal standpoint, I can see the benefits of being able to make per-agent customizations in your own private Wrapper and identify that the public agents are supported.

Consider the following scenario: WrapperA can take in any Windows agent as long as it is in shellcode format. Apollo currently supports this format. WrapperA identifies that it works with Apollo. Tomorrow, for whatever reason, Apollo removes this capability (unaware that WrapperA needs it to support Apollo) and now people run into issues with WrapperA and Apollo. Some users will open an issue on Apollo saying it's no longer working with WrapperA, but the Apollo dev has no idea what WrapperA is. The Apollo dev either now has the additional burden of trying to bring this support back (may or may not want to) or has to move the issues over to WrapperA.

That scenario of course only really applies when it's all public components, which I can see as being pretty burdensome when you're dealing with a private wrapper you want to use with public agents.

I'd need to add extra checks in Mythic when syncing PayloadType data over to determine if there's a link or not, but it's not impossible.

[paul-axe]

I understand your concerns, however I think that Mythic UI is pretty straightforward in that case - payload building step and agent building step are separated, and it is possible to perform compile time checks on the wrapper side (which most wrappers already have, e.g. https://github.com/MythicAgents/service_wrapper/blob/1a1f2d2bdc23f2a897a3a8efbfd475161a304388/Payload_Type/service_wrapper/service_wrapper/builder.py#L79). I mean if we've got an error on the wrapper compilation step, it is pretty straighforward (in my opinion) that the issue is on the wrapper side.

Here are my thoughts about the possible solutions:

1. Only agent developer can specify compatible wrappers - in that case it feels like every wrapper most likely will be maintained by the agent developers themselves. With an external developer it will result in extra communication and in responsibility spreading.
2. Only wrapper developer can specify compatible agents - logically I think it is the most correct way, however it has its downsides as you mentioned above. In that case wrapper developer is fully responsible to be compatible with the agent (or to remove agent from compatible list). It will also lead in breaking changes for agent developer, which is bad.
3. Allow both wrapper and agent specify the compatibility lists, merging them together. Sounds like the solution which takes good and bad sides of previous solution. However in that case the architecture feels more flexible, which is good
4. Add extra abstraction layer between agent and wrapper specifying the format, OS and other properties of the payload, which will determine compatibility between agent and wrapper. Honestly I dont believe in that way, because it seems to be very tricky to determine list of properties which will be enough to describe compatibility, and in most cases it wouldnt give any guarantees that the wrapper and agent will really work together.

I personally think think that p.3 is the best solution, however I would happy to hear other thoughts

[its-a-feature]

For sure, of those 4, only option 3 would provide the necessary support you're looking for.

Option 2 is the same as option 1, just in reverse. Instead of needing the agent dev to specify the wrappers, you'd have people making patches into wrappers they install to support their agents (or trying to get PRs merged in for their agent name).

Option 4, like you mentioned, will just cause all sorts of "support" issues when neither agent nor wrapper dev would actually list them as "supported" necessarily based on those things.