RFC: Exploit utilities

[terrorbyte]

Problem

At the moment the logic for exploits is that most of interactive functionality with attacker components is defined in the c2 package. As of late with the exploration of the external C2 modules (#206) we've encountered that there is need to separate out some of what we have been using as a "C2" to be utilities that are able to be utilized by the actual more complex C2s.

For example, many of the non-trivial payload types are compiled Go or larger binaries that need "staged". Traditionally we have been using c2/httpservefile but that presents a problem: we can serve the generated payload but the catching C2 is not the same as the served file.

Solution

Add a utilities or utils package that contains a set of common exploit helper functions to help with staging payloads or interact with some other framework component that is not a C2. This would have a few benefits:

• Utilities will not trigger framework Success messages as they are not tied to the C2, which will be good for when HTTP retrieval is not inherently successful exploitation (SSRF for instance)
• Utilities can be more flexible, such as serving strings or specifically formatted content for OOB interactions
• If we set a singleton similarly to how we do C2s for utilities we can set them up via enabling them directly with the new C2 impl type (adding a []utils.EnabledUtilities to the Impl or channel type) so that they could be enabled at exploit C2 definition time.

Potential Issues

Primarily flag parsing is almost always a chicken and egg problem in the framework. Flags getting parsed by RunExploit means that we need to ensure that utilities command line arguments are parsed then in order to expose them to the client. Additionally, flags with C2 are pretty clear when they are necessary to be set and that can be a bit more nebulous in a utility function.

[terrorbyte]

Utilities is also a very overloaded term. Instead I might focus on specific servers and just call them that explicitly.